I am trying to achieve a result using Spring. In my case; I need to connect to a queue on n (~6) different hosts/ports. Say,
jms://hostA:portA/Queue
jms://hostB:portB/Queue
jms://hostC:portC/Queue
...
I am completely lost on where to start now. Reading tons of documents and it broke my whole motivation.
p.s; All the examples and documentations are mostly focused on ActiveMQ which in my case is not valid.
I do not need any code sample but a light on my way to start from. Like a some class names to check etc..
The JMS provider is irrelevant.
You need a connection factory bean for each host and configure each component (JMS template, listener container, etc) to use the appropriate connection factory.
Related
I have a Java Spring Boot application, and I need to send messages over IBM MQ and then listen for a response on a corresponding queue. I have a primary and (possibly multiple) fail-over MQ hosts. The queue names are different on each host (I have no control over this) so I need to have a different connection factory for each host.
I've looked at the mq-jms-spring code, and think I can adapt this to my needs. However, our current code, which works a comma separated list of hosts (and was written by someone else), creates both a connection factory and a transaction manager using that connection factory. It can use multiple hosts, but since the queue names are different for each host the fail-overs, well, fail. I'm assuming I need to create multiple transaction managers if I have multiple connection factories.
My questions are:
Do I need a transaction manager in this case?
If yes, then do I need a 1-1 relationship of connection factory to transaction manager?
If yes, how do I use the multiple transaction managers? I use the connection factory to write to the queue, but how do I notify spring which transaction factory to use? Does Spring automatically know this or is there some way I need to configure this?
I' m currently investigation the implementation of queue's or topic, based on activeMQ within our project. The setup is pretty straight forward in which we are using maven modules to seprate business logic according to the business domain. One common module allows us to assemble common logic.
simplified Example:
common module
products module
clients module
One of the requirements is that certain operations are asynchronous towards a backend (by means of a activeMQ) which in turn responds with a result message.
The second requirement is that it should be possible to horizontally scale the application by creating a new deployable artifact with only that module that needs more juice.
We are using spring 4 with of course jms and activeMQ.
On to my question. We would like to use just one queue or topic for backend connectivity. Which would mean our common module would handle jms configuration (jms factory, jms-configuration) and different types of messages will be send over that one queue/topic.
How would can I make sure that product related messages get handled by the "products" module and client related messages get handled by the "clients" module? How can I make sure only one of the "products" modules logic would handle a message if the module was deployed two times? What approach would you recommend or is this one queue/topic "nuts"?
I was myself thinking in the direction of using a topic because of the publ/subsc pattern... , or maybe queue listener acting as publisher in a observer pattern to which product- or client subscribers might subscribe to take over handling the message?
Thanks for your help.
Why using a Topic if you want just one of the "products" modules to handle one message? With Topic you'd have one message - multiple subscribers each getting the message. The Queue ensures only one consumer gets a message (point-to-point), with Topic you'd have one message dispatched to all subscribers.
Regarding the "filtering" of messages, this should be something provider specific. Looking at ActiveMQ docs I see this. So, basically each consumer should get the messages the broker, based on selector, will dispatch. I don't know the specifics, but this would be the first place I would start this investigation.
On the same idea, have a look at this discussion from the Spring forum. It is, indeed, related to Spring Integration, but it's on the same idea of message selection. On the other hand, you could consider adopting Spring Integration in your project: it's kind of an abstraction of integration patterns and fits well with everything message oriented.
Few interesting ideas from that forum post:
JmsTemplate from Spring contains a doReceive method that takes as a parameter a String as message selector
Message selectors are in the JMS spec (scroll down to "Message Properties" section)
Relevant section in the Spring Integration documentation is here
I've managed to get Spring Xd working for a scenario where I have data coming in from one JMS broker.
I potentially am facing a scenario where data ingestion could happen from different sources thereby needing me to connect to different brokers.
Based on my current understanding, I'm not quite sure how to do this as there exists a JMS config file which allows you to setup only one broker.
Is there a workaround to this?
At the moment, you would have to create a separate jms-[provider]-infrastructure-context.xml for each broker (in modules/common), say call the provider activemq2.
Then use --provider=activemq2 in the module definition.
(I recently used this technique to test sonicmq and hornetq providers).
I have a app server that runs multiple camel routes that are reading messages from a JMS Queue, each route runs with different selectors.
We have an app server for each group of clients. So at the end there are multiple connections created to the queue. And that seems to be affecting the read and write performance on the queue.
I tried to use a connection pool, (by the way i am using WMQ), the closest I got is to use spring's CachingConnectionFactory (as described in this post how to configure (spring) JMS connection Pool for WMQ).
I was hoping that the number of connections will reduce from each app server, but that did not happen. Even though i set the size to 5 on the CCFactory, i see 10 connections created to the queue. According to the documentation on CCFactory, explicit closing of the connections is required. Is it possible or does it even make sense to close the connection that is used by a camel route that is reading from a queue? Or is there a way to tell camel routes to share the connections? I thought the use of connection pool and factory will do that, but i don't see that from happening.
Can I achieve what I want to achieve?
Thanks in advance.
what you can do is have only one route reading from the queue instead of many, and then use some camel conditional logic to redirect the message to the correct processing route via direct endpoints, see also this example.
This way there would only one consumer for the queue, instead of multiple consumers each running it's own selector.
I am searching for a way to create and delete jms queues using jmx through a java client.
I know we do get AdminClient for jmx administration. But I am not able to get which mbean
we can use to create and delete jms queues.
The ConfigService mentioned by Marcin is a low level API that allows to manipulate configuration objects directly. That my be tricky. E.g. if you need to create a SIB destination, then you need to manipulate at least two different types of configuration objects, namely SIB destinations (children of the bus defined at the cell scope) and queue points (children of the messaging engine at the server or cluster scope), and you need to make sure that you link them properly.
Probably it will be easier for you to use the CommandMgr API as described in this post. That API is the direct equivalent of the AdminTask object in wsadmin.
You may work with WAS configuration (and create/delete JMS queues in particular) using ConfigService. This article explains how to obtain and use ConfigService:
http://www.ibm.com/developerworks/websphere/techjournal/0307_wang/wang.html
Although it's been written for WAS 5.1, it's still up to date.