[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Bug in transactional delivery in an MDB
by clebert.suconic@jboss.com
I have executed the whole testsuite and I didn't see any failures related to transactional behaviors.
And regarding to ACKs, I believe we should treat ACK on XA the as nonTransacted/AutoAck.
For this, we would have to probably change SessionAspect::handlePreDeliver:
| if (ackMode == Session.CLIENT_ACKNOWLEDGE)
| {
| // We collect acknowledgments in the list
|
| if (trace) { log.trace(this + " added to CLIENT_ACKNOWLEDGE list delivery " + info); }
|
| // Sanity check
| if (info.getConnectionConsumerSession() != null)
| {
| throw new IllegalStateException(
| "CLIENT_ACKNOWLEDGE cannot be used with a connection consumer");
| }
|
| state.getClientAckList().add(info);
| }
| else if (ackMode == Session.AUTO_ACKNOWLEDGE ||
| (state.isXA() && (state.getCurrentTxId() instanceof LocalTx)))
| {
|
and postDeliver:
public Object handlePostDeliver(Invocation invocation) throws Throwable
| {
| MethodInvocation mi = (MethodInvocation)invocation;
| SessionState state = getState(invocation);
|
| int ackMode = state.getAcknowledgeMode();
|
| // if XA and there is no transaction enlisted on XA we will act as AutoAcknowledge
| if (ackMode == Session.AUTO_ACKNOWLEDGE ||
| (state.isXA() && state.getCurrentTxId() instanceof LocalTx))
| {
|
What is weird though is, I have written an integration testcase, where a message was received inside an EJB, and it looked like the message was ACKed even though I didn't have a transaction to commit it. I know Tim tried to explain me how this would work but now I got confused.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4040766#4040766
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4040766
18 years, 11 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Remoting is throwing unrecognized listener ID: blah blah
by ron.sigal@jboss.com
When Client.addListener() is called, bisocket stores some information in a static map, keyed on the listener ID, and when Client.removeListener() is called, that information is purged. The "unrecognized listener ID" message comes up when the purge method doesn't find the listener ID among the keys. So it represents an event I didn't expect.
However, I see one way the situation could arise. The client side runs a thread that monitors the health of the control connection, and if the control connection fails, the monitor thread will recreate the control connection. However, it could be that the failed control connection was to a server that died and was restarted (with new connections), in which case there's no point in restarting the old control connection. So the monitor thread keeps a count of the number of times the control connection has been restarted, and when the count maxes out, the thread gives up and purges the static map. If Client.addListener() is called after that, the message will come up.
So I'm thinking
1. I'd like to leave the warning message in, but
2. I could leave a dummy entry in the map (instead of a Thread), just so it's clear that all is well.
But, I'd like to know if this scenario corresponds to what you're seeing, or if there's something else going on that I need to fix.
-Ron
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4040752#4040752
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4040752
18 years, 11 months