Hot answers tagged

12

Tridion supports any MQ product that adheres to the JMS specification. Keep in mind that JMS has two modes: MDB (Message Drive Bean) Simple Messaging Tridion supports both, but your specific MQ product may not support both modes (last I saw, Websphere only supported MDB by default).


9

I've written a blog post addressing the configuration in a bit more detail. The big item that needs to be considered is that an EJB Module containing an EJB spec must be provided. The EJB spec points to a Tridion Message Driven Bean class. Here is the link to the post: http://www.tridiondeveloper.com/configuring-the-tridion-cache-channel-service-with-...


8

The basic principle is that for each deployer there is a cache invalidation process. For RMI , this is via the Cache Channel Service (CCS) and for JMS this is via a JMS queue. If you have two servers each with their own DB and deployer, then you will need two cache invalidation processes (CCS or JMSQ). All brokers (websites) that serve content deployed by ...


5

Web Sphere MQ default is non-persistent (so if an outage you loose all queue messages).. Persistent : file based (keeps in the log files on disk) --> requires to be on the "shared" FS for cluster setup or DB. When we did perf testing, MQ default(non-persistent) works out to be lot better.. Note this was WAS 6.1 and couple of years back.. So at the end we did ...


4

You are missing the client library jars for JMS. Since you are using Tibco as a JMS server, I would check their documentation for a list of client jars.


3

Apache ActiveMQ is blocking the JMS ObjectMessages for security reasons. This is the default configuration. Configure ActiveMQ to allow ObjectMessages to be deserialized. Either enable it for all ObjectMessages or just for com.tridion.cache.CacheEvent. Explanation and instructions are here: http://activemq.apache.org/objectmessage.html. If you're running ...


3

For few years, we are exactly in the same configuration : caching setup with one cache channel service (as Windows Service) configured on each webserver. Each webservers is synchronized with its dedicated Cache Channel. The only disavantage I see in this scenario is that Cache Channel becomes a SPOF. It cannot be scaled up. One Cache Channel for one ...


2

You are using AsyncJMS11MDB strategy. You may need to provide an EJB module with an EJB spec pointing to the MDB class (if your build is java). Also make sure that the strategy you specify is supported by Tibco. Have a look at the article here that explains how to accomplish this for WebSphere JMS. There may be similarities. http://www.tridiondeveloper....


2

You probably can use Spring's JMS listener combined with OSB. Configuration looks this this: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd"> <beans> <bean id="cacheMessageListener" class="org.dd4t.core.caching.jms.impl....


2

Problem was caused by the RMIChannel Listenerport which is by default enabled in the quickinstall configs (SDL Web 8.5\Content Delivery\resources\quickinstall\config\deployer-combined\deployer-conf.xml). After commenting out this Port problem was resolved. <!-- RMI Channel Port --> <RMIChannel ListenerPort="1050"/>


2

The error is a sign of you starting up the CacheChannel service twice on the same port. Did you maybe merge the CCS in your Deployer startup? If you use ActiveMQ JMS, you don't actually need to setup the CacheChannel service at all.


1

Answer to your question - No, only deployer and content service needs to be enabled Tridion object caching with ActiveMQ.


1

Configuration mentioned by Raimond above works and the spring webapp is now able to make connection to the JMS topic defined in OSB. Just couple of minor corrections thats why pasting the conf again here: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd"> ...


1

There's no generic Transport Listener specification in the JMS Api / specification, so hence it's not possible to keep this part generic. You should be able simply remove the transportListener and the references to it and then invalidation will still work.


1

I guess the conclusion maybe is that the name of the class JMSTransportListener should possibly have been ActiveMQTransportListener instead, and if you are not intenting to use ActiveMQ, you should implement your own jmsTransportListener. However I'm not completely sure because you fail to mention what changes you are making to support your other JMS server....


1

Simplest approach would be to add cache channel service (as java standalone app) to each of the webservers and use RMI to sync the cache on each server separately. Is there any disadvantage to this approach? Absolutely. I wouldn't call this a stable enterprise production-ready solution. The processes could go down, typically you would need to setup ...


Only top voted, non community-wiki answers of a minimum length are eligible