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 <
james.strachan@...> 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
