yep. I've tinkered with it. The runnable that the TransportConnection calls is used to let the Subscription know when a message has been sent been transmitted by the transport. This is so it can do proper memory management and stuff like that.
I think the problem comes because that field is also used on the client side by Connection Consumers. They use the same field to associate a consumer with the message so that when a rollback occurs the message can be placed back on the the right queue for the consumer. When you are using a transports that marshals, you would not see this problem, but when you are using the vm transport, both the broker and the connection consumer are operating on the same copy of the message and the use of that field conflicts. Going to add another field to avoid the conflict. On 3/7/07, James Strachan <[EMAIL PROTECTED]> wrote:
I've just patched the code to avoid the exception noted here https://issues.apache.org/activemq/browse/AMQ-1189 I was just wondering what that code was meant to be doing - testing the consumer being Runnable. ActiveMQConnectionConsumer doesn't implement Runnable but it does implement ActiveMQDispatcher - I wondered if the code should check for that interface too? What consumers might implement Runnable? Anyone who tinkered with this bit of code in org.apache.activemq.broker.TransportConnection.processDispatch() know? -- James ------- http://radio.weblogs.com/0112098/
-- Regards, Hiram Blog: http://hiramchirino.com
