[jira] [Commented] (AMQ-5575) Stuck message in ActiveMQ after WebLogic (incl. MDB) startup

2015-03-23 Thread Bernhard Trummer (JIRA) 

[ 
https://issues.apache.org/jira/browse/AMQ-5575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14375933#comment-14375933
 ] 

Bernhard Trummer commented on AMQ-5575:
---

Further update. The issue does not occur, when reducing the threads of the MDB 
from 16 to 1.
I used the following weblogic-ejb-jar.xml for testing:
{code}
weblogic-ejb-jar
weblogic-enterprise-bean
ejb-nameMyListenerEjbBean/ejb-name
dispatch-policyWorkManager-0/dispatch-policy
/weblogic-enterprise-bean
work-manager
nameWorkManager-0/name
max-threads-constraint
nameWorkManager-Constraint-0/name
count1/count
/max-threads-constraint
ignore-stuck-threadstrue/ignore-stuck-threads
/work-manager
/weblogic-ejb-jar
{code}

However, as soon as the thread count is bigger than 1, the bug is reproducable.


 Stuck message in ActiveMQ after WebLogic (incl. MDB) startup
 

 Key: AMQ-5575
 URL: https://issues.apache.org/jira/browse/AMQ-5575
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.8.0, 5.10.0, 5.11.0
 Environment: Linux (Debian squeeze)
 WebLogic Server 10.3.6.0 with a Foreign Server JMS module pointing to 
 ActiveMQ.
 WebLogic and ActiveMQ running locally.
Reporter: Bernhard Trummer

 The setup:
 - ActiveMQ with the default configuration providing one queue.
 - WebLogic server having
   - a Foreign Server JMS module configured pointing to the ActiveMQ's queue
   - a simple EJB3 MDB hooked up to this queue via XAConnectionFactory.
 The issue is always reproducable as follows:
 1. Shut down WebLogic
 2. Start up ActiveMQ
 3. Put a message (M1) into ActiveMQ's queue (e.g. via web frontend)
 4. Start up WebLogic (including the simple EJB3 MDB deployment)
 5. You'll see that the message M1 is consumed. The MDB logs it and the 
 message vanishes from the ActiveMQ web frontend = OK
 6. Put another message (M2) into ActiveMQ's queue.
 7. Put a third message (M3) into ActiveMQ's queue.
 Expected behavior:
 M2 and M3 are consumed by the MDB on WebLogic.
 Actual behavior:
 M2 is getting stuck.
 M3 is consumed correctly.
 The next 15 messages you add to the ActiveMQ queue are consumed correctly.
 The next message (MX) leads to a consumption of the previously stuck message 
 (M2) and the current message (MX).
 After that, the behavior repeats with scenario step 6 above.
 Some further notes:
 1. Why 15/16 messages until the stuck message is consumed? Because ActiveMQ 
 shows 16 listeners when WebLogic is started up.
 2. I can reproduce the issue every time.
 3. It occurs with version 5.8.0, 5.10.0 and 5.11.0 of activemq (of course 
 also using the matching activemq-client jar in WebLogic).
 4. If you leave out step 3 of the scenario (means: ensure that ActiveMQ's 
 queue is empty before WebLogic is started up), then everything is fine and no 
 message is getting stuck.
 5. Good news is, that no message is getting lost without being consumed. But 
 it's still quite annoying in my current integration project I'm working on. 
 :-)
 Currently I'm trying to add trace logging into the activemq-client to get a 
 better idea on what's going on. What I can tell so far is, that the message 
 M2 is indeed received by the client and enqueued into a 
 SimplePriorityMessageDispatchChannel instance correctly. But it looks like 
 that the dequeue() call is done on a different instance in this scenario.
 Further I see, that some kind of round robin happens in the usage of these 
 Channel instances and that might be the reason, why M2 is eventually consumed 
 together with the 16th next message.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-5575) Stuck message in ActiveMQ after WebLogic (incl. MDB) startup

2015-02-17 Thread Bernhard Trummer (JIRA) 

[ 
https://issues.apache.org/jira/browse/AMQ-5575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14324180#comment-14324180
 ] 

Bernhard Trummer commented on AMQ-5575:
---

Bug is reproducable when the MDB:
- has the @TransactionAttribute annotation set to 
TransactionAttributeType.REQUIRED.
- uses the mapped XAConnectionFactory as connectionFactoryJndiName 
@ActivationConfigProperty.

However, the bug does not occur when the MDB is non-XA:
- has the @TransactionAttribute annotation set to 
TransactionAttributeType.NOT_SUPPORTED.
- uses the mapped ConnectionFactory as connectionFactoryJndiName 
@ActivationConfigProperty.


 Stuck message in ActiveMQ after WebLogic (incl. MDB) startup
 

 Key: AMQ-5575
 URL: https://issues.apache.org/jira/browse/AMQ-5575
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.8.0, 5.10.0, 5.11.0
 Environment: Linux (Debian squeeze)
 WebLogic Server 10.3.6.0 with a Foreign Server JMS module pointing to 
 ActiveMQ.
 WebLogic and ActiveMQ running locally.
Reporter: Bernhard Trummer

 The setup:
 - ActiveMQ with the default configuration providing one queue.
 - WebLogic server having
   - a Foreign Server JMS module configured pointing to the ActiveMQ's queue
   - a simple EJB3 MDB hooked up to this queue via XAConnectionFactory.
 The issue is always reproducable as follows:
 1. Shut down WebLogic
 2. Start up ActiveMQ
 3. Put a message (M1) into ActiveMQ's queue (e.g. via web frontend)
 4. Start up WebLogic (including the simple EJB3 MDB deployment)
 5. You'll see that the message M1 is consumed. The MDB logs it and the 
 message vanishes from the ActiveMQ web frontend = OK
 6. Put another message (M2) into ActiveMQ's queue.
 7. Put a third message (M3) into ActiveMQ's queue.
 Expected behavior:
 M2 and M3 are consumed by the MDB on WebLogic.
 Actual behavior:
 M2 is getting stuck.
 M3 is consumed correctly.
 The next 15 messages you add to the ActiveMQ queue are consumed correctly.
 The next message (MX) leads to a consumption of the previously stuck message 
 (M2) and the current message (MX).
 After that, the behavior repeats with scenario step 6 above.
 Some further notes:
 1. Why 15/16 messages until the stuck message is consumed? Because ActiveMQ 
 shows 16 listeners when WebLogic is started up.
 2. I can reproduce the issue every time.
 3. It occurs with version 5.8.0, 5.10.0 and 5.11.0 of activemq (of course 
 also using the matching activemq-client jar in WebLogic).
 4. If you leave out step 3 of the scenario (means: ensure that ActiveMQ's 
 queue is empty before WebLogic is started up), then everything is fine and no 
 message is getting stuck.
 5. Good news is, that no message is getting lost without being consumed. But 
 it's still quite annoying in my current integration project I'm working on. 
 :-)
 Currently I'm trying to add trace logging into the activemq-client to get a 
 better idea on what's going on. What I can tell so far is, that the message 
 M2 is indeed received by the client and enqueued into a 
 SimplePriorityMessageDispatchChannel instance correctly. But it looks like 
 that the dequeue() call is done on a different instance in this scenario.
 Further I see, that some kind of round robin happens in the usage of these 
 Channel instances and that might be the reason, why M2 is eventually consumed 
 together with the 16th next message.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-5575) Stuck message in ActiveMQ after WebLogic (incl. MDB) startup

2015-02-11 Thread Bernhard Trummer (JIRA) 

[ 
https://issues.apache.org/jira/browse/AMQ-5575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14315932#comment-14315932
 ] 

Bernhard Trummer commented on AMQ-5575:
---

Feel free to request any additional information from me.
If desired, I also can provide the WebLogic MDB artifact and configuration 
instructions on how to set up the Foreign Destination.
I even could provide a complete zip of my WebLogic installation via a separate 
channel, because I can't and won't attach it here. :-)


 Stuck message in ActiveMQ after WebLogic (incl. MDB) startup
 

 Key: AMQ-5575
 URL: https://issues.apache.org/jira/browse/AMQ-5575
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.8.0, 5.10.0, 5.11.0
 Environment: Linux (Debian squeeze)
 WebLogic Server 10.3.6.0 with a Foreign Server JMS module pointing to 
 ActiveMQ.
 WebLogic and ActiveMQ running locally.
Reporter: Bernhard Trummer

 The setup:
 - ActiveMQ with the default configuration providing one queue.
 - WebLogic server having
   - a Foreign Server JMS module configured pointing to the ActiveMQ's queue
   - a simple EJB3 MDB hooked up to this queue via XAConnectionFactory.
 The issue is always reproducable as follows:
 1. Shut down WebLogic
 2. Start up ActiveMQ
 3. Put a message (M1) into ActiveMQ's queue (e.g. via web frontend)
 4. Start up WebLogic (including the simple EJB3 MDB deployment)
 5. You'll see that the message M1 is consumed. The MDB logs it and the 
 message vanishes from the ActiveMQ web frontend = OK
 6. Put another message (M2) into ActiveMQ's queue.
 7. Put a third message (M3) into ActiveMQ's queue.
 Expected behavior:
 M2 and M3 are consumed by the MDB on WebLogic.
 Actual behavior:
 M2 is getting stuck.
 M3 is consumed correctly.
 The next 15 messages you add to the ActiveMQ queue are consumed correctly.
 The next message (MX) leads to a consumption of the previously stuck message 
 (M2) and the current message (MX).
 After that, the behavior repeats with scenario step 6 above.
 Some further notes:
 1. Why 15/16 messages until the stuck message is consumed? Because ActiveMQ 
 shows 16 listeners when WebLogic is started up.
 2. I can reproduce the issue every time.
 3. It occurs with version 5.8.0, 5.10.0 and 5.11.0 of activemq (of course 
 also using the matching activemq-client jar in WebLogic).
 4. If you leave out step 3 of the scenario (means: ensure that ActiveMQ's 
 queue is empty before WebLogic is started up), then everything is fine and no 
 message is getting stuck.
 5. Good news is, that no message is getting lost without being consumed. But 
 it's still quite annoying in my current integration project I'm working on. 
 :-)
 Currently I'm trying to add trace logging into the activemq-client to get a 
 better idea on what's going on. What I can tell so far is, that the message 
 M2 is indeed received by the client and enqueued into a 
 SimplePriorityMessageDispatchChannel instance correctly. But it looks like 
 that the dequeue() call is done on a different instance in this scenario.
 Further I see, that some kind of round robin happens in the usage of these 
 Channel instances and that might be the reason, why M2 is eventually consumed 
 together with the 16th next message.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)