[mskonda]

"dv_lakshmi" wrote:
....Therefore an acknowledgement should have been sent thereby which the contents of the jms tables should have been deleted accordingly. But this has not happened.

Second, If the messages have not received an acknowledgement, then when are the messages retried ? As long as the server is running, I dont see these messages that exist in the table to be processed again by the listeners. However, when I restart my server, these messages are being picked up by the listener. I am puzzled as my application works absolutely fine till the server is restarted !!

The messages are retried (redelivered) immediately if the consumer couldn't process it initially for whatever reason.
To summarise - you still have rows in the tables suggest that the messages are not acknowledged.

I have run a simple test case with a MDB consuming messages from a queue. Unfortunately I wasn't able to reproduce your scenario inspite of simulating different test scenarios, . I am beginning to think that the culprit could be down to jdbc persistence with Oracle..

[timfox]

"dv_lakshmi" wrote:
Well, part of the problem can be replicated even without the spring code. i.e., the message sending problem as mentioned in the email.

Ok fine. :)

So send me a junit test case and I will be happy to look into it.

[timfox]

"mskonda" wrote:
I am beginning to think that the culprit could be down to jdbc persistence with Oracle..

Let's not jump to conclusions about what is happening here.

I'd like to see this replicated in a test case and then I will investigate.

[timfox]

I would just like to make clear that we have not tested JBossMessaging with Spring, and so we can make no guarantees on whether it will or won't work.

I.e. it's not supported.

That's not to say that it won't work, just that we don't have the resources to invest in the work required to do the testing right now.

Thanks.

[timfox]

Of course, if anyone is kind enough to contribute some time to do this piece of work then that would be much appreciated :)

The piece of work would involve someone writing a set of test cases that test JBossMessaging via the spring API, that we can include as part of our test suite.

[joellindheimer]

Tim/Ovidiu/Lakshmi
1) I created a JMS Async consumer which is created in a new thread within the init() method of a startup servlet.
2) The onMessage() wrapps a UserTransaction
3) I created a client that sends 9 messages

There were no residual messages in the Messages Table. I will contact Juergen Hoeller and see if he has any suggestions.

[joellindheimer]

Lakshmi, Tim, Ovidiu,
I have isolated the variable that caused the problem. When I configured my consumer with Spring the problem was duplicated. I noticed that there was a difference between my test and the Spring configuration and that was the user of our own configured QueueConnectionFactory. I then switched from using Click's configured WMXQueueConnectionFactory:
<connection-factories>
<tx-connection-factory>
<jndi-name>WMXQueueConnectionFactory</jndi-name>
<use-java-context>false</use-java-context>
<xa-transaction/>
<rar-name>jms-ra.rar</rar-name>
<connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
<config-property name="SessionDefaultType" type="java.lang.String">javax.jms.Queue</config-property>
<blocking-timeout-millis>60000</blocking-timeout-millis>
<min-pool-size>5</min-pool-size>
<max-pool-size>45</max-pool-size>
<idle-timeout-minutes>5</idle-timeout-minutes>
</tx-connection-factory>
</connection-factories>

To using the generic Jboss "/XAConnectionFactory" and the problem went away. This is very good news... however, I imagine that it would be important to Jboss to understand why the problem occurs with the WMXConnectionFactory configuration as to avoid others encountering the same problem.

[timfox]

Your "WMXQueueConnectionFactory" is a JCA managed connection factory, whereas XAConnectionFactory is a standard JMS connection factory.

You would use WMXQueueConnectionFactory is you wanted jms transactional operations to be enlisted in any global transactions in the app server, e.g. if you wanted to send a message in the same global transaction as calling an ejb for example, or if you wanted to use UserTransaction.

If you use the straightforward XAConnectionFactory you cannot use UserTransaction to demarcate JMS transaction boundaries, it will have no effect, so you will either have to use standard jms transactions (session.commit or rollback) or explicitly enlist in the global transaction by using the session's XAResource directlly.

[joellindheimer]

============================
Lessons Learned after a Plethora of Testing
============================

I have done a lot more testing as well as checked with Juergen Hoeller to sync up in findings within his community. Here is what I have found:

1) Using anything but the XA ConectionFactory bound specifically to ?java:/JmsXA? is problematic with JBoss 4.X server with Messaging 1.0.
a. Do NOT use ?/XAConnectionFactory? as we found problems in several scenarios.
b. Do NOT use any custom configured XA ConnectionFactory for the reasons Tim mentioned.

2) When using a JMS Consumer you MUST always get a new JMS Connection; do NOT pool the Connection. If you use an existing Connection the it will not get enlisted into the Global Transaction.

Conclusion:
If you follow these two rules you can safely use JBoss Messaging 1.0 within the context of a global transaction and get the expected behavior thereof.

[timfox]

Joel-

We are not aware of any problems with the use of the standard JMS connection factories or any JCA managed connection factories with JBoss Messaging, so what you say worries me quite a lot.

Our test process tests this so I would like to know how this has slipped through the net.

Can you please give me more specifics as to what you think is wrong so we can investigate further?

Thanks.

[timfox]

If you think the connection factories aren't working correctly, probably best to follow the standard practice here and provide me with a code example, so I've got something to go on, otherwise I'm just trying to second guess what you think might be wrong.

Thanks again.