Manage delivery of JMS messages to multiple servers

2
votes

Our app uses Spring Boot and JMS messages with Tibco. We have two production servers running and processing messages concurrently. Servers are listening to the same one queue. Each server has 10 concurrent listeners. I do not want the very same message gets processed by both servers at the same time. Nothing prevents our queue of having duplicate messages, like we can have two copies of the message A in the queue. If messages in the queue are: A, A, B, C, D, then if first A gets delivered to server1 and second A gets delivered to server2, and both servers process A at the same time, then they are chances of creating duplicate entities. I want to find a way to send all A messages to only one server. I can't use Message Selector b/c we have the same code base running on both servers. This is what I'm considering:

Based on the message, set properties in the headers. Once the message got delivered to the process() method, depending on which server is processing the message, either discard, simply return the message or process the message and acknowledge it. The problem with this solution is that since we need to dynamicacaly find out which server is processing the message, the server name needs to be hardcoded, meaning if the server moves, the code breaks!

Other solution - that might work - is the Destination field.

https://docs.spring.io/spring/docs/4.0.x/spring-framework-reference/html/jms.html

Destinations, like ConnectionFactories, are JMS administered objects that can be stored and retrieved in JNDI. When configuring a Spring application context you can use the JNDI factory class JndiObjectFactoryBean / to perform dependency injection on your object’s references to JMS destinations.

It's something I never done before. Is there anyway, to configure the Destination that it picks up the right server to route the message to? Meaning, if message1 is supposed to be delivered to server1, then it does not even gets delivered to server2 and remains in the queue until server1 consumes it?

What are other ways to implement this?

EDIT:

I still do not know what’s the best way to send certain messages to only one server for processing, however, accepted the response given to use database as validation, b/c this is what we consider to avoid creating duplicate entities when processing the data.

2
javaspringjmstibcotibco-ems
Sounds like a job for topics instead of point to point queues. – duffymo
I don't quite understand the use-case here. Are there 2 message brokers involved or simply 2 clients with multiple concurrent consumers all connected to the same queue? If the latter, I don't understand why there would ever be a problem with the same message being consumed by multiple clients concurrently. The whole point of a queue is that only a single consumer gets the message. Please clarify. – Justin Bertram
Can’t go by topic. Need to have the message acknowledgement once the receiver receives the message. Besides the sender and receiver are not necessarily active at the same time. Need two servers for load balancing. – blueSky
The latter: 2 clients with multiple concurrent consumers all connected to the same queue. Nothing prevents our queue of having duplicate messages, like we can have two copies of the message A in the queue. If messages in the queue are: A, A, B, C, D, then if first A gets delivered to server1 and second A gets delivered to server2, and both servers process A at the same time, then they are chances of creating duplicate entities. I want to find a way to send all A messages to only one server. – blueSky

2 Answers

1
votes

I think the idea of using the JMS Destination is a non-starter as there is nothing in the JMS specification which guarantees any kind of link between the destination and a broker. The destination is just an encapsulation for the provider-specific queue/topic name.

The bottom line here is that you either need to prevent the duplicate messages in the first place or have some way to coordinate the consumers to deal with the duplicates after they've been pulled off the queue. I think you could do either of these using an external system like a database, e.g.:

  • When producing the message check the database for an indication that the message was sent already. If no indication is found then write a record to the database (will need to use a primary key to prevent duplicates) and send the message. Otherwise don't send the message.
  • When consuming the message check the database for an indication that the message is being (or was) consumed already. If no indication is found then write a record to the database (will need to use a primary key to prevent duplicates) and process the message. Otherwise just acknowledge the message without processing it.
0
votes

I suggest an alternative to "post DB sync".

Keep the servers and listeners as-is, and broadcast all+ the the processed messages on a topic. For servers just starting, you can use "durable subscribers" to not miss any messages.

If you broadcast each start and end of processing for messages A, B, C, etc AND consider adding a little pause (in milli), you should avoid collisions. It's the main risk of course.

It's not clear to me if you should validate for duplicate processing at the beginning or end of a message processing... it depends on your needs.

If this whole idea is not acceptable, DB validation might be the only option, but as stated in comments above, I fear for scaling.