[ 
https://issues.apache.org/activemq/browse/AMQ-758?page=comments#action_36423 ] 

james strachan commented on AMQ-758:
------------------------------------

I don't really understand the problem. Message Groups are designed so that a 
single thread processes all messages of the same group. If you don't want that, 
don't use message groups.

If you want to allow concurrent processing (multiple threads processing the 
same message group) then you need to use something else.

A fix for your problem would be to just use a separate background thread to do 
the long operation so that the caller can cancel the operation.

e.g.

foo.startLongOperation();

// the above returns without blocking

foo.cancelLongOperation();

That way you can use message groups

> Message Groups disables server side JMS session pooling
> -------------------------------------------------------
>
>          Key: AMQ-758
>          URL: https://issues.apache.org/activemq/browse/AMQ-758
>      Project: ActiveMQ
>         Type: Bug

>   Components: Broker
>     Versions: 4.0
>  Environment: XP, ActiveMQ 4.0 release, Lingo 1.1, Spring 2.0
>     Reporter: Sanjiv Jivan
>  Attachments: lingocluster.zip
>
>
> Specifying Message Groups on the client causes serialized/ single threaded 
> processing of messages on the server side even when server side session 
> pooling is configured.
> Please find attached  sample code along with a JUnit test "MessageGroupTests" 
> that demonstrates the issue. My sample is based on Lingo. The client calls an 
> async method solve(scenarioName) and receives progress callbacks. When the 
> cleint calls cancel(scenarioName) during a solve, the cancel method on the 
> server side should be received and stop the running solve. Since a single JMS 
> session evexcutes message listeners serially, I've configured a JMS server 
> session pool of size 20 using Spring's DefaultMessageListenerContainer class.
> I've configured use of a message group via a Lingo marshaller class 
> org.sanjiv.lingo.client.MessageGroupMarshaller. This class basically sets the 
> JMS header  "JMSXGroupID" to the "scenarioName" in question so that when a 
> cluster of servers are running, the cancel(scenarioName) call is directed to 
> the server that had solve(scenarioName) called for a given "scenarioName".
> The issue is that when the message groups are enabled using the 
> MessageGroupMarshaller, the cancel(scenarioName) call blocks and waits for 
> the async solve(scenarioName) method to complete on the server (which is not 
> the right behaviour). Disabling message groups by commenting out the client 
> side MessageGroupMarshaller marshaller in 
> org/sanjiv/lingo/test/messageGroupContext.xml results in the call being 
> excuted correctly.
> I see that the docs for message groups say that message order is preserved, 
> however that should not require that the second message blocks till the first 
> message completes. Only the order in which the listeners are executes should 
> be guaranteed to be the order of message receipt.
> Let me know if you have any questions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Reply via email to