[ https://jira.jboss.org/jira/browse/JBAS-7950?page=com.atlassian.jira.plug... ] Clebert Suconic updated JBAS-7950: ---------------------------------- Assignee: Andy Taylor (was: Clebert Suconic) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-7950?page=com.atlassian.jira.plugin.sy... ] Tim Fox reassigned JBAS-7950: ----------------------------- Assignee: Tim Fox (was: Andy Taylor) I'm going to investigate this -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-7950?page=com.atlassian.jira.plugin.sy... ] Tim Fox commented on JBAS-7950: ------------------------------- I'm having to guess here since neither the HornetQ nor the MDB config has been attached to this JIRA. Therefore I can't tell whether the redelivery settings have been applied correctly on the server, also I can't tell how the MDB has been configured, e.g. is it AUTO_ACKNOWLEDGE, transactional (if so BMT or CMT?) or something else? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-7950?page=com.atlassian.jira.plugin.sy... ] jaikiran pai updated JBAS-7950: ------------------------------- Attachment: jbas7950.ear JBAS-7950-source.tar.gz Attached jbas7950.ear which reproduces this issue. Just place this .ear in the default/deploy folder of AS6 (M4 or even AS trunk is fine). On server start, access http://localhost:8080/jbas7950/test.jsp. That jsp just sends a message to queue/A which is being listened to by the MDB. The MDB just prints out the delivery count and also message.getJMSRedelivered() value (note that the call to that method always returns false which indicates it's broken too) and intentionally throws an RuntimeException @Override public void onMessage(Message msg) { try { System.out.println("Delivery count: " + (++count)); System.out.println("Message re-delivered expected to be true, got : " + msg.getJMSRedelivered()); } catch (JMSException jmse) { // just log System.out.println("Ignoring jmse: " + jmse.getMessage()); } // intentionally throw exception throw new RuntimeException("Intentional runtime exception"); } After you access that jsp, watch the server console, you will notice that the message is being redelivered continuously. You'll see the output similar to: 16:55:45,099 INFO [STDOUT] Delivery count: 3307 16:55:45,099 INFO [STDOUT] Message re-delivered expected to be true, got : false 16:55:45,099 ERROR [CMTTxInterceptor] javax.ejb.EJBTransactionRolledbackException: Intentional runtime exception 16:55:45,100 ERROR [HornetQMessageHandler] Failed to deliver message: javax.ejb.EJBTransactionRolledbackException: Intentional runtime exception at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:148) [:0.0.1] at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:227) [:0.0.1] at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.required(CMTTxInterceptor.java:353) [:0.0.1] at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:209) [:0.0.1] at org.jboss.ejb3.tx2.aop.CMTTxInterceptorWrapper.invoke(CMTTxInterceptorWrapper.java:52) [:0.0.1] ... I have also attached a JBAS-7950-source.tar.gz file containing the source of this example. Can be built through Ant. Just run "ant" from the "build" folder. It'll generate the .ear in the "dist" folder. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-7950?page=com.atlassian.jira.plugin.sy... ] Tim Fox commented on JBAS-7950: ------------------------------- I can see what is happening here. The delivery of the message seems to be occurring in the context of a JTA transaction (it's not AUTO_ACK). This doesn't seem right to me, since, IIRC default ack mode should be non transacted AUTO_ACK, I would have to check the JEE spec though. So *something* is starting a JTA tx for the delivery of the message, that something is either JBoss AS or the RA. I will investigate further. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-7950?page=com.atlassian.jira.plugin.sy... ] jaikiran pai commented on JBAS-7950: ------------------------------------ The EJB3 spec says this for MDBs with CMT: (Section 5.4.14) <quote> JMS message-driven beans should not attempt to use the JMS API for message acknowledgment. Message acknowledgment is automatically handled by the container. *If the message-driven bean uses container-managed transaction demarcation, message acknowledgment is handled automatically as a part of the transaction commit.* If bean-managed transaction demarcation is used, the message receipt cannot be part of the bean-managed transaction, and, in this case, the receipt is acknowledged by the container. If bean-managed transaction demarcation is used, the Bean Provider can indicate whether JMS AUTO_ACKNOWLEDGE semantics or DUPS_OK_ACKNOWLEDGE semantics should apply by using the activationConfig element of the MessageDriven annotation or by using the activation-config-property deployment descriptor element. The property name used to specify the acknowledgment mode is acknowledgeMode. If the acknowledgeMode property is not specified, JMS AUTO_ACKNOWLEDGE semantics are assumed. The value of the acknowledgeMode property must be either Auto-acknowledge or Dups-ok-acknowledge for a JMS message-driven bean. </quote> So in case of CMT, the tx commit on the MDB's onMessage() should trigger a message acknowledgement. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-7950?page=com.atlassian.jira.plugin.sy... ] jaikiran pai commented on JBAS-7950: ------------------------------------ Yes, the absence of any explicit transaction management type indicates the default CMT with default REQUIRED tx semantics. As for the message redelivery semantics, the EJB3 spec doesn't list down the rules and leaves it to the JMS providers to handle it in their own specific way. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-7950?page=com.atlassian.jira.plugin.sy... ] jaikiran pai commented on JBAS-7950: ------------------------------------ Just checked the JMS 1.1 spec. Section 4.5.2 says this: The result of a listener throwing a RuntimeException depends on the session's acknowledgment mode: - AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE - the message will be immediately redelivered. The number of times a JMS provider will redeliver the same message before giving up is provider-dependent. The JMSRedelivered message header field will be set for a message redelivered under these circumstances. I couldn't find anything more about the redelivery semantics, which is relevant to this issue, in this spec. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-7950?page=com.atlassian.jira.plugin.sy... ] Tim Fox commented on JBAS-7950: ------------------------------- "The result of a listener throwing a RuntimeException depends on the session's acknowledgment mode: - AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE - the message will be immediately redelivered. The number of times a JMS provider will redeliver the same message before giving up is provider-dependent. The JMSRedelivered message header field will be set for a message redelivered under these circumstances. " ^^^ this is not relevant in our case since it's using neither auto_ack or dups_ok, it's JTA. The JMS spec does specify what we should do on rollback of a local tx, but says nothing about JTA. I'll assume local semantics for JTA too since the spec is silent on this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-7950?page=com.atlassian.jira.plugin.sy... ] jaikiran pai commented on JBAS-7950: ------------------------------------ I see what you mean. Out of curiosity, how did JBoss Messaging handle such a scenario? Did it too (intentionally) apply the local tx semantics? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-7950?page=com.atlassian.jira.plugin.sy... ] Tim Fox commented on JBAS-7950: ------------------------------- This is now fixed in HornetQ TRUNK. Need to make sure fix doesn't break AS test suite before closing this one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-7950?page=com.atlassian.jira.plugin.sy... ] jaikiran pai commented on JBAS-7950: ------------------------------------ I created this forum thread http://community.jboss.org/thread/159048 to see if anyone from HornetQ community knows about the next HornetQ release. I'll check with Shelly to see if this fix can be included in AS6 Final. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBAS-7950?page=com.atlassian.jira.plugin.... ] jaikiran pai commented on JBAS-7950: ------------------------------------ Just tried upgrading AS6 trunk to 2.2.2.Final of HornetQ to see if this issue is fixed. The upgrade isn't straight forward since I run into compile errors in AS6-HornetQ integration module. This will have to wait for some more time, till someone has some free time to integrate this new version in AS6 trunk. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBAS-7950?page=com.atlassian.jira.plugin.... ] Elias Ross updated JBAS-7950: ----------------------------- Attachment: hornetq.diff Patch to fix compilation for HornetQ 2.2. The management interfaces still need some work, but compilation passes at least. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBAS-7950?page=com.atlassian.jira.plugin.... ] jaikiran pai reassigned JBAS-7950: ---------------------------------- Assignee: jaikiran pai (was: Clebert Suconic) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBAS-7950?page=com.atlassian.jira.plugin.... ] jaikiran pai commented on JBAS-7950: ------------------------------------ {quote} Patch to fix compilation for HornetQ 2.2. The management interfaces still need some work, but compilation passes at least. {quote} Elias, thanks for spending time to create a patch. But looks like Clebert already has a working code which we just need to move over to AS6 trunk. I'll do that some time during this week and let the community know once it's done. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBAS-7950?page=com.atlassian.jira.plugin.... ] jaikiran pai resolved JBAS-7950. -------------------------------- Resolution: Done -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBAS-7950?page=com.atlassian.jira.plugin.... ] Piotr Komisarski commented on JBAS-7950: ---------------------------------------- hi. I'm facing the same problem, but i think there is some kind of workaround: Instead of throwing RuntimeException you can inject MessageDrivenContext and call setRollbackOnly(). In this case messaging engine is properly redelivering message and when it comes to max redelivering count it's send to DLQ. But now I'm curious why JMSXDeliveryCount is not set to max in DLQ. (it's set to zero) I've found, that this property it's not updated by default, and i must set "persist-delivery-count-before-delivery" in configuration. But anyway - it's still not working. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira