[JBoss JIRA] (JBMESSAGING-1919) Publisher doesn't get JMSException even if database (JMS persistence) is down
9:18 p.m.
Toshiya Kobayashi created JBMESSAGING-1919:
----------------------------------------------
Summary: Publisher doesn't get JMSException even if database (JMS
persistence) is down
Key: JBMESSAGING-1919
URL: https://issues.jboss.org/browse/JBMESSAGING-1919
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.4.8.SP5
Reporter: Toshiya Kobayashi
In case of Topic (PERSISTENT mode, Durable Subscriber), Publisher doesn't get
JMSException even if database (JMS persistence) is down. Attached a reproducer.
How to reproduce:
JBoss 5.1.1
- configure MySQL as JMS persistence manager
- unzip jms-publisher-subscriber.zip
- edit build.properties for your local env
- copy test-destination-service.xml to deploy dir
- (terminal 1) ant subscriber
- (terminal 2) ant publisher
- stop MySQL
-- Subscriber fails. But Publisher keeps running though database is down
JBoss logs an error message in ChannelSupport.
{noformat}
21:37:47,292 ERROR [ChannelSupport] Failed to handle message
org.jboss.util.NestedSQLException: Unable to get managed connection for DefaultDS; -
nested throwable: (javax.resource.ResourceException: Unable to get managed connection for
DefaultDS)
{noformat}
But doesn't throw a JMSException. On the other hand, it throws a JMSException in case
of Queue.
See: ServerConnectionEndpoint
{code:java}
boolean sendMessage(JBossMessage msg, Transaction tx, boolean checkForDuplicates)
throws Exception
{
...
else if (dest.isQueue())
{
if (trace) { log.trace(this + " routing " + msg + " to
queue"); }
if (!postOffice.route(ref, new JMSCondition(true, dest.getName()), tx))
{
throw new JMSException("Failed to route " + ref + " to " +
dest.getName());
}
}
else
{
if (trace) { log.trace(this + " routing " + msg + " to
postoffice"); }
postOffice.route(ref, new JMSCondition(false, dest.getName()), tx);
}
if (trace) { log.trace("sent " + msg); }
return true;
}
{code}
This logic is written in revision 1237. But there is no reason to avoid throwing JMS
Exception for Topic?
https://source.jboss.org/browse/JBossMessaging/trunk/src/main/org/jboss/j...
{noformat}
------------------------------------------------------------------------
r1237 | timfox | 2006-08-31 03:36:36 +0900 (Thu, 31 Aug 2006) | 4 lines
Initial commit for clustering
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:17 p.m.
[
https://issues.jboss.org/browse/JBMESSAGING-1919?page=com.atlassian.jira....
]
Yong Hao Gao reassigned JBMESSAGING-1919:
-----------------------------------------
Assignee: Yong Hao Gao
Publisher doesn't get JMSException even if database (JMS
persistence) is down
-----------------------------------------------------------------------------
Key: JBMESSAGING-1919
URL: https://issues.jboss.org/browse/JBMESSAGING-1919
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.4.8.SP5
Reporter: Toshiya Kobayashi
Assignee: Yong Hao Gao
In case of Topic (PERSISTENT mode, Durable Subscriber), Publisher doesn't get
JMSException even if database (JMS persistence) is down. Attached a reproducer.
How to reproduce:
JBoss 5.1.1
- configure MySQL as JMS persistence manager
- unzip jms-publisher-subscriber.zip
- edit build.properties for your local env
- copy test-destination-service.xml to deploy dir
- (terminal 1) ant subscriber
- (terminal 2) ant publisher
- stop MySQL
-- Subscriber fails. But Publisher keeps running though database is down
JBoss logs an error message in ChannelSupport.
{noformat}
21:37:47,292 ERROR [ChannelSupport] Failed to handle message
org.jboss.util.NestedSQLException: Unable to get managed connection for DefaultDS; -
nested throwable: (javax.resource.ResourceException: Unable to get managed connection for
DefaultDS)
{noformat}
But doesn't throw a JMSException. On the other hand, it throws a JMSException in case
of Queue.
See: ServerConnectionEndpoint
{code:java}
boolean sendMessage(JBossMessage msg, Transaction tx, boolean checkForDuplicates)
throws Exception
{
...
else if (dest.isQueue())
{
if (trace) { log.trace(this + " routing " + msg + " to
queue"); }
if (!postOffice.route(ref, new JMSCondition(true, dest.getName()), tx))
{
throw new JMSException("Failed to route " + ref + " to "
+ dest.getName());
}
}
else
{
if (trace) { log.trace(this + " routing " + msg + " to
postoffice"); }
postOffice.route(ref, new JMSCondition(false, dest.getName()), tx);
}
if (trace) { log.trace("sent " + msg); }
return true;
}
{code}
This logic is written in revision 1237. But there is no reason to avoid throwing JMS
Exception for Topic?
https://source.jboss.org/browse/JBossMessaging/trunk/src/main/org/jboss/j...
{noformat}
------------------------------------------------------------------------
r1237 | timfox | 2006-08-31 03:36:36 +0900 (Thu, 31 Aug 2006) | 4 lines
Initial commit for clustering
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:19 p.m.
[
https://issues.jboss.org/browse/JBMESSAGING-1919?page=com.atlassian.jira....
]
Yong Hao Gao updated JBMESSAGING-1919:
--------------------------------------
Fix Version/s: 1.4.0.SP3.CP15
1.4.8.SP7
Affects Version/s: 1.4.8.SP6
Publisher doesn't get JMSException even if database (JMS
persistence) is down
-----------------------------------------------------------------------------
Key: JBMESSAGING-1919
URL: https://issues.jboss.org/browse/JBMESSAGING-1919
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.4.8.SP5, 1.4.8.SP6
Reporter: Toshiya Kobayashi
Assignee: Yong Hao Gao
Fix For: 1.4.0.SP3.CP15, 1.4.8.SP7
In case of Topic (PERSISTENT mode, Durable Subscriber), Publisher doesn't get
JMSException even if database (JMS persistence) is down. Attached a reproducer.
How to reproduce:
JBoss 5.1.1
- configure MySQL as JMS persistence manager
- unzip jms-publisher-subscriber.zip
- edit build.properties for your local env
- copy test-destination-service.xml to deploy dir
- (terminal 1) ant subscriber
- (terminal 2) ant publisher
- stop MySQL
-- Subscriber fails. But Publisher keeps running though database is down
JBoss logs an error message in ChannelSupport.
{noformat}
21:37:47,292 ERROR [ChannelSupport] Failed to handle message
org.jboss.util.NestedSQLException: Unable to get managed connection for DefaultDS; -
nested throwable: (javax.resource.ResourceException: Unable to get managed connection for
DefaultDS)
{noformat}
But doesn't throw a JMSException. On the other hand, it throws a JMSException in case
of Queue.
See: ServerConnectionEndpoint
{code:java}
boolean sendMessage(JBossMessage msg, Transaction tx, boolean checkForDuplicates)
throws Exception
{
...
else if (dest.isQueue())
{
if (trace) { log.trace(this + " routing " + msg + " to
queue"); }
if (!postOffice.route(ref, new JMSCondition(true, dest.getName()), tx))
{
throw new JMSException("Failed to route " + ref + " to "
+ dest.getName());
}
}
else
{
if (trace) { log.trace(this + " routing " + msg + " to
postoffice"); }
postOffice.route(ref, new JMSCondition(false, dest.getName()), tx);
}
if (trace) { log.trace("sent " + msg); }
return true;
}
{code}
This logic is written in revision 1237. But there is no reason to avoid throwing JMS
Exception for Topic?
https://source.jboss.org/browse/JBossMessaging/trunk/src/main/org/jboss/j...
{noformat}
------------------------------------------------------------------------
r1237 | timfox | 2006-08-31 03:36:36 +0900 (Thu, 31 Aug 2006) | 4 lines
Initial commit for clustering
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:21 a.m.
[
https://issues.jboss.org/browse/JBMESSAGING-1919?page=com.atlassian.jira....
]
Toshiya Kobayashi updated JBMESSAGING-1919:
-------------------------------------------
Attachment: jms-publisher-subscriber.zip
Publisher doesn't get JMSException even if database (JMS
persistence) is down
-----------------------------------------------------------------------------
Key: JBMESSAGING-1919
URL: https://issues.jboss.org/browse/JBMESSAGING-1919
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.4.8.SP5, 1.4.8.SP6
Reporter: Toshiya Kobayashi
Assignee: Yong Hao Gao
Fix For: 1.4.0.SP3.CP15, 1.4.8.SP7
Attachments: jms-publisher-subscriber.zip
In case of Topic (PERSISTENT mode, Durable Subscriber), Publisher doesn't get
JMSException even if database (JMS persistence) is down. Attached a reproducer.
How to reproduce:
JBoss 5.1.1
- configure MySQL as JMS persistence manager
- unzip jms-publisher-subscriber.zip
- edit build.properties for your local env
- copy test-destination-service.xml to deploy dir
- (terminal 1) ant subscriber
- (terminal 2) ant publisher
- stop MySQL
-- Subscriber fails. But Publisher keeps running though database is down
JBoss logs an error message in ChannelSupport.
{noformat}
21:37:47,292 ERROR [ChannelSupport] Failed to handle message
org.jboss.util.NestedSQLException: Unable to get managed connection for DefaultDS; -
nested throwable: (javax.resource.ResourceException: Unable to get managed connection for
DefaultDS)
{noformat}
But doesn't throw a JMSException. On the other hand, it throws a JMSException in case
of Queue.
See: ServerConnectionEndpoint
{code:java}
boolean sendMessage(JBossMessage msg, Transaction tx, boolean checkForDuplicates)
throws Exception
{
...
else if (dest.isQueue())
{
if (trace) { log.trace(this + " routing " + msg + " to
queue"); }
if (!postOffice.route(ref, new JMSCondition(true, dest.getName()), tx))
{
throw new JMSException("Failed to route " + ref + " to "
+ dest.getName());
}
}
else
{
if (trace) { log.trace(this + " routing " + msg + " to
postoffice"); }
postOffice.route(ref, new JMSCondition(false, dest.getName()), tx);
}
if (trace) { log.trace("sent " + msg); }
return true;
}
{code}
This logic is written in revision 1237. But there is no reason to avoid throwing JMS
Exception for Topic?
https://source.jboss.org/browse/JBossMessaging/trunk/src/main/org/jboss/j...
{noformat}
------------------------------------------------------------------------
r1237 | timfox | 2006-08-31 03:36:36 +0900 (Thu, 31 Aug 2006) | 4 lines
Initial commit for clustering
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:36 a.m.
[
https://issues.jboss.org/browse/JBMESSAGING-1919?page=com.atlassian.jira....
]
Yong Hao Gao commented on JBMESSAGING-1919:
-------------------------------------------
Hi Toshiya,
I tried your test and the subscriber seems normal after mysql has been brought down. I
think this is expected. Even though the test is still valid for this issue.
Regards
Howard
Publisher doesn't get JMSException even if database (JMS
persistence) is down
-----------------------------------------------------------------------------
Key: JBMESSAGING-1919
URL: https://issues.jboss.org/browse/JBMESSAGING-1919
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.4.8.SP5, 1.4.8.SP6
Reporter: Toshiya Kobayashi
Assignee: Yong Hao Gao
Fix For: 1.4.0.SP3.CP15, 1.4.8.SP7
Attachments: jms-publisher-subscriber.zip
In case of Topic (PERSISTENT mode, Durable Subscriber), Publisher doesn't get
JMSException even if database (JMS persistence) is down. Attached a reproducer.
How to reproduce:
JBoss 5.1.1
- configure MySQL as JMS persistence manager
- unzip jms-publisher-subscriber.zip
- edit build.properties for your local env
- copy test-destination-service.xml to deploy dir
- (terminal 1) ant subscriber
- (terminal 2) ant publisher
- stop MySQL
-- Subscriber fails. But Publisher keeps running though database is down
JBoss logs an error message in ChannelSupport.
{noformat}
21:37:47,292 ERROR [ChannelSupport] Failed to handle message
org.jboss.util.NestedSQLException: Unable to get managed connection for DefaultDS; -
nested throwable: (javax.resource.ResourceException: Unable to get managed connection for
DefaultDS)
{noformat}
But doesn't throw a JMSException. On the other hand, it throws a JMSException in case
of Queue.
See: ServerConnectionEndpoint
{code:java}
boolean sendMessage(JBossMessage msg, Transaction tx, boolean checkForDuplicates)
throws Exception
{
...
else if (dest.isQueue())
{
if (trace) { log.trace(this + " routing " + msg + " to
queue"); }
if (!postOffice.route(ref, new JMSCondition(true, dest.getName()), tx))
{
throw new JMSException("Failed to route " + ref + " to "
+ dest.getName());
}
}
else
{
if (trace) { log.trace(this + " routing " + msg + " to
postoffice"); }
postOffice.route(ref, new JMSCondition(false, dest.getName()), tx);
}
if (trace) { log.trace("sent " + msg); }
return true;
}
{code}
This logic is written in revision 1237. But there is no reason to avoid throwing JMS
Exception for Topic?
https://source.jboss.org/browse/JBossMessaging/trunk/src/main/org/jboss/j...
{noformat}
------------------------------------------------------------------------
r1237 | timfox | 2006-08-31 03:36:36 +0900 (Thu, 31 Aug 2006) | 4 lines
Initial commit for clustering
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:49 p.m.
[
https://issues.jboss.org/browse/JBMESSAGING-1919?page=com.atlassian.jira....
]
Toshiya Kobayashi commented on JBMESSAGING-1919:
------------------------------------------------
Hi Howard,
I observe the following Exception on subscriber side when I stop MySQL. (Regardsless of
<valid-connection-checker-class-name>)
{noformat}
[java] org.jboss.jms.exception.MessagingJMSException: A failure has occurred during
processing of the request. Please consult the server logs for more details.
SessionEndpoint[ab-kytctb0h-1-w3mbtb0h-6s21x2-100j3] acknowledgeDelivery
[9j-0t8dtb0h-1-w3mbtb0h-6s21x2-100j3]
[java] at
org.jboss.messaging.util.ExceptionUtil.handleJMSInvocation(ExceptionUtil.java:72)
[java] at
org.jboss.jms.server.endpoint.ServerSessionEndpoint.acknowledgeDelivery(ServerSessionEndpoint.java:464)
[java] at
org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$acknowledgeDelivery$aop(SessionAdvised.java:120)
[java] at
org.jboss.jms.server.endpoint.advised.SessionAdvised$acknowledgeDelivery_N5825751487881460811.invokeTarget(SessionAdvised$acknowledgeDelivery_N5825751487881460811.java)
[java] at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
[java] at
org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
[java] at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
[java] at
org.jboss.jms.server.endpoint.advised.SessionAdvised.acknowledgeDelivery(SessionAdvised.java)
[java] at
org.jboss.jms.wireformat.SessionAcknowledgeDeliveryRequest.serverInvoke(SessionAcknowledgeDeliveryRequest.java:78)
[java] at
org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:165)
[java] at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:967)
[java] at
org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:791)
[java] at
org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:744)
[java] at
org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:586)
[java] at
org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:234)
[java] at
org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:218)
[java] at org.jboss.remoting.Client.invoke(Client.java:2070)
[java] at org.jboss.remoting.Client.invoke(Client.java:879)
[java] at org.jboss.remoting.Client.invoke(Client.java:867)
[java] at
org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:189)
[java] at
org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:160)
[java] at
org.jboss.jms.client.delegate.ClientSessionDelegate.org$jboss$jms$client$delegate$ClientSessionDelegate$acknowledgeDelivery$aop(ClientSessionDelegate.java:186)
[java] at
org.jboss.jms.client.delegate.ClientSessionDelegate$acknowledgeDelivery_N5825751487881460811.invokeTarget(ClientSessionDelegate$acknowledgeDelivery_N5825751487881460811.java)
[java] at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
[java] at
org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:92)
[java] at
org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
[java] at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
[java] at
org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:172)
[java] at
org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
[java] at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
[java] at
org.jboss.jms.client.delegate.ClientSessionDelegate.acknowledgeDelivery(ClientSessionDelegate.java)
[java] at
org.jboss.jms.client.container.SessionAspect.ackDelivery(SessionAspect.java:921)
[java] at
org.jboss.jms.client.container.SessionAspect.handlePostDeliver(SessionAspect.java:368)
[java] at
org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect_z_handlePostDeliver_822054004.invoke(SessionAspect_z_handlePostDeliver_822054004.java)
[java] at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
[java] at
org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:172)
[java] at
org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
[java] at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
[java] at
org.jboss.jms.client.delegate.ClientSessionDelegate.postDeliver(ClientSessionDelegate.java)
[java] at
org.jboss.jms.client.container.ClientConsumer.receive(ClientConsumer.java:605)
[java] at
org.jboss.jms.client.container.ConsumerAspect.handleReceive(ConsumerAspect.java:199)
[java] at
org.jboss.aop.advice.org.jboss.jms.client.container.ConsumerAspect_z_handleReceive_822054004.invoke(ConsumerAspect_z_handleReceive_822054004.java)
[java] at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
[java] at
org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:172)
[java] at
org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
[java] at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
[java] at
org.jboss.jms.client.delegate.ClientConsumerDelegate.receive(ClientConsumerDelegate.java)
[java] at
org.jboss.jms.client.JBossMessageConsumer.receive(JBossMessageConsumer.java:81)
[java] at
com.redhat.jboss.support.jms.Subscriber$TestSubscriber.run(Subscriber.java:48)
[java] at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[java] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[java] at java.lang.Thread.run(Thread.java:619)
{noformat}
I think it's better to edit Subscriber.java to run longer.
{noformat}
diff -rN
jms-publisher-subscriber/src/main/java/com/redhat/jboss/support/jms/Subscriber.java
jms-publisher-subscriber_tmp/src/main/java/com/redhat/jboss/support/jms/Subscriber.java
18c18
< Thread.sleep(200000);
---
Thread.sleep(20000);
46c46
< for (int i=0; i<100000; i++) {
---
for (int i=0; i<10; i++) {
{noformat}
In addition, it's better to use a DataSource with
<valid-connection-checker-class-name> for this test because it is the common use
case. I'm going to edit reproduce steps accordingly.
Publisher doesn't get JMSException even if database (JMS
persistence) is down
-----------------------------------------------------------------------------
Key: JBMESSAGING-1919
URL: https://issues.jboss.org/browse/JBMESSAGING-1919
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.4.8.SP5, 1.4.8.SP6
Reporter: Toshiya Kobayashi
Assignee: Yong Hao Gao
Fix For: 1.4.0.SP3.CP15, 1.4.8.SP7
Attachments: jms-publisher-subscriber.zip
In case of Topic (PERSISTENT mode, Durable Subscriber), Publisher doesn't get
JMSException even if database (JMS persistence) is down. Attached a reproducer.
How to reproduce:
JBoss 5.1.1
- configure MySQL as JMS persistence manager
- unzip jms-publisher-subscriber.zip
- edit build.properties for your local env
- copy test-destination-service.xml to deploy dir
- (terminal 1) ant subscriber
- (terminal 2) ant publisher
- stop MySQL
-- Subscriber fails. But Publisher keeps running though database is down
JBoss logs an error message in ChannelSupport.
{noformat}
21:37:47,292 ERROR [ChannelSupport] Failed to handle message
org.jboss.util.NestedSQLException: Unable to get managed connection for DefaultDS; -
nested throwable: (javax.resource.ResourceException: Unable to get managed connection for
DefaultDS)
{noformat}
But doesn't throw a JMSException. On the other hand, it throws a JMSException in case
of Queue.
See: ServerConnectionEndpoint
{code:java}
boolean sendMessage(JBossMessage msg, Transaction tx, boolean checkForDuplicates)
throws Exception
{
...
else if (dest.isQueue())
{
if (trace) { log.trace(this + " routing " + msg + " to
queue"); }
if (!postOffice.route(ref, new JMSCondition(true, dest.getName()), tx))
{
throw new JMSException("Failed to route " + ref + " to "
+ dest.getName());
}
}
else
{
if (trace) { log.trace(this + " routing " + msg + " to
postoffice"); }
postOffice.route(ref, new JMSCondition(false, dest.getName()), tx);
}
if (trace) { log.trace("sent " + msg); }
return true;
}
{code}
This logic is written in revision 1237. But there is no reason to avoid throwing JMS
Exception for Topic?
https://source.jboss.org/browse/JBossMessaging/trunk/src/main/org/jboss/j...
{noformat}
------------------------------------------------------------------------
r1237 | timfox | 2006-08-31 03:36:36 +0900 (Thu, 31 Aug 2006) | 4 lines
Initial commit for clustering
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:51 p.m.
[
https://issues.jboss.org/browse/JBMESSAGING-1919?page=com.atlassian.jira....
]
Toshiya Kobayashi updated JBMESSAGING-1919:
-------------------------------------------
Description:
In case of Topic (PERSISTENT mode, Durable Subscriber), Publisher doesn't get
JMSException even if database (JMS persistence) is down. Attached a reproducer.
How to reproduce:
JBoss 5.1.2
- configure MySQL as JMS persistence manager (see attached
mysql-ds.xml/mysql-persistence-service.xml)
- unzip jms-publisher-subscriber.zip
- edit build.properties for your local env
- copy test-destination-service.xml to deploy dir
- (terminal 1) ant subscriber
- (terminal 2) ant publisher
- stop MySQL
-- Subscriber fails. But Publisher keeps running though database is down
JBoss logs an error message in ChannelSupport.
{noformat}
21:37:47,292 ERROR [ChannelSupport] Failed to handle message
org.jboss.util.NestedSQLException: Unable to get managed connection for DefaultDS; -
nested throwable: (javax.resource.ResourceException: Unable to get managed connection for
DefaultDS)
{noformat}
But doesn't throw a JMSException. On the other hand, it throws a JMSException in case
of Queue.
See: ServerConnectionEndpoint
{code:java}
boolean sendMessage(JBossMessage msg, Transaction tx, boolean checkForDuplicates)
throws Exception
{
...
else if (dest.isQueue())
{
if (trace) { log.trace(this + " routing " + msg + " to
queue"); }
if (!postOffice.route(ref, new JMSCondition(true, dest.getName()), tx))
{
throw new JMSException("Failed to route " + ref + " to " +
dest.getName());
}
}
else
{
if (trace) { log.trace(this + " routing " + msg + " to
postoffice"); }
postOffice.route(ref, new JMSCondition(false, dest.getName()), tx);
}
if (trace) { log.trace("sent " + msg); }
return true;
}
{code}
This logic is written in revision 1237. But there is no reason to avoid throwing JMS
Exception for Topic?
https://source.jboss.org/browse/JBossMessaging/trunk/src/main/org/jboss/j...
{noformat}
------------------------------------------------------------------------
r1237 | timfox | 2006-08-31 03:36:36 +0900 (Thu, 31 Aug 2006) | 4 lines
Initial commit for clustering
{noformat}
was:
In case of Topic (PERSISTENT mode, Durable Subscriber), Publisher doesn't get
JMSException even if database (JMS persistence) is down. Attached a reproducer.
How to reproduce:
JBoss 5.1.1
- configure MySQL as JMS persistence manager
- unzip jms-publisher-subscriber.zip
- edit build.properties for your local env
- copy test-destination-service.xml to deploy dir
- (terminal 1) ant subscriber
- (terminal 2) ant publisher
- stop MySQL
-- Subscriber fails. But Publisher keeps running though database is down
JBoss logs an error message in ChannelSupport.
{noformat}
21:37:47,292 ERROR [ChannelSupport] Failed to handle message
org.jboss.util.NestedSQLException: Unable to get managed connection for DefaultDS; -
nested throwable: (javax.resource.ResourceException: Unable to get managed connection for
DefaultDS)
{noformat}
But doesn't throw a JMSException. On the other hand, it throws a JMSException in case
of Queue.
See: ServerConnectionEndpoint
{code:java}
boolean sendMessage(JBossMessage msg, Transaction tx, boolean checkForDuplicates)
throws Exception
{
...
else if (dest.isQueue())
{
if (trace) { log.trace(this + " routing " + msg + " to
queue"); }
if (!postOffice.route(ref, new JMSCondition(true, dest.getName()), tx))
{
throw new JMSException("Failed to route " + ref + " to " +
dest.getName());
}
}
else
{
if (trace) { log.trace(this + " routing " + msg + " to
postoffice"); }
postOffice.route(ref, new JMSCondition(false, dest.getName()), tx);
}
if (trace) { log.trace("sent " + msg); }
return true;
}
{code}
This logic is written in revision 1237. But there is no reason to avoid throwing JMS
Exception for Topic?
https://source.jboss.org/browse/JBossMessaging/trunk/src/main/org/jboss/j...
{noformat}
------------------------------------------------------------------------
r1237 | timfox | 2006-08-31 03:36:36 +0900 (Thu, 31 Aug 2006) | 4 lines
Initial commit for clustering
{noformat}
Publisher doesn't get JMSException even if database (JMS
persistence) is down
-----------------------------------------------------------------------------
Key: JBMESSAGING-1919
URL: https://issues.jboss.org/browse/JBMESSAGING-1919
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.4.8.SP5, 1.4.8.SP6
Reporter: Toshiya Kobayashi
Assignee: Yong Hao Gao
Fix For: 1.4.0.SP3.CP15, 1.4.8.SP7
Attachments: jms-publisher-subscriber.zip
In case of Topic (PERSISTENT mode, Durable Subscriber), Publisher doesn't get
JMSException even if database (JMS persistence) is down. Attached a reproducer.
How to reproduce:
JBoss 5.1.2
- configure MySQL as JMS persistence manager (see attached
mysql-ds.xml/mysql-persistence-service.xml)
- unzip jms-publisher-subscriber.zip
- edit build.properties for your local env
- copy test-destination-service.xml to deploy dir
- (terminal 1) ant subscriber
- (terminal 2) ant publisher
- stop MySQL
-- Subscriber fails. But Publisher keeps running though database is down
JBoss logs an error message in ChannelSupport.
{noformat}
21:37:47,292 ERROR [ChannelSupport] Failed to handle message
org.jboss.util.NestedSQLException: Unable to get managed connection for DefaultDS; -
nested throwable: (javax.resource.ResourceException: Unable to get managed connection for
DefaultDS)
{noformat}
But doesn't throw a JMSException. On the other hand, it throws a JMSException in case
of Queue.
See: ServerConnectionEndpoint
{code:java}
boolean sendMessage(JBossMessage msg, Transaction tx, boolean checkForDuplicates)
throws Exception
{
...
else if (dest.isQueue())
{
if (trace) { log.trace(this + " routing " + msg + " to
queue"); }
if (!postOffice.route(ref, new JMSCondition(true, dest.getName()), tx))
{
throw new JMSException("Failed to route " + ref + " to "
+ dest.getName());
}
}
else
{
if (trace) { log.trace(this + " routing " + msg + " to
postoffice"); }
postOffice.route(ref, new JMSCondition(false, dest.getName()), tx);
}
if (trace) { log.trace("sent " + msg); }
return true;
}
{code}
This logic is written in revision 1237. But there is no reason to avoid throwing JMS
Exception for Topic?
https://source.jboss.org/browse/JBossMessaging/trunk/src/main/org/jboss/j...
{noformat}
------------------------------------------------------------------------
r1237 | timfox | 2006-08-31 03:36:36 +0900 (Thu, 31 Aug 2006) | 4 lines
Initial commit for clustering
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:53 p.m.
[
https://issues.jboss.org/browse/JBMESSAGING-1919?page=com.atlassian.jira....
]
Toshiya Kobayashi updated JBMESSAGING-1919:
-------------------------------------------
Attachment: mysql-ds.xml
mysql-persistence-service.xml
Publisher doesn't get JMSException even if database (JMS
persistence) is down
-----------------------------------------------------------------------------
Key: JBMESSAGING-1919
URL: https://issues.jboss.org/browse/JBMESSAGING-1919
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.4.8.SP5, 1.4.8.SP6
Reporter: Toshiya Kobayashi
Assignee: Yong Hao Gao
Fix For: 1.4.0.SP3.CP15, 1.4.8.SP7
Attachments: jms-publisher-subscriber.zip, mysql-ds.xml,
mysql-persistence-service.xml
In case of Topic (PERSISTENT mode, Durable Subscriber), Publisher doesn't get
JMSException even if database (JMS persistence) is down. Attached a reproducer.
How to reproduce:
JBoss 5.1.2
- configure MySQL as JMS persistence manager (see attached
mysql-ds.xml/mysql-persistence-service.xml)
- unzip jms-publisher-subscriber.zip
- edit build.properties for your local env
- copy test-destination-service.xml to deploy dir
- (terminal 1) ant subscriber
- (terminal 2) ant publisher
- stop MySQL
-- Subscriber fails. But Publisher keeps running though database is down
JBoss logs an error message in ChannelSupport.
{noformat}
21:37:47,292 ERROR [ChannelSupport] Failed to handle message
org.jboss.util.NestedSQLException: Unable to get managed connection for DefaultDS; -
nested throwable: (javax.resource.ResourceException: Unable to get managed connection for
DefaultDS)
{noformat}
But doesn't throw a JMSException. On the other hand, it throws a JMSException in case
of Queue.
See: ServerConnectionEndpoint
{code:java}
boolean sendMessage(JBossMessage msg, Transaction tx, boolean checkForDuplicates)
throws Exception
{
...
else if (dest.isQueue())
{
if (trace) { log.trace(this + " routing " + msg + " to
queue"); }
if (!postOffice.route(ref, new JMSCondition(true, dest.getName()), tx))
{
throw new JMSException("Failed to route " + ref + " to "
+ dest.getName());
}
}
else
{
if (trace) { log.trace(this + " routing " + msg + " to
postoffice"); }
postOffice.route(ref, new JMSCondition(false, dest.getName()), tx);
}
if (trace) { log.trace("sent " + msg); }
return true;
}
{code}
This logic is written in revision 1237. But there is no reason to avoid throwing JMS
Exception for Topic?
https://source.jboss.org/browse/JBossMessaging/trunk/src/main/org/jboss/j...
{noformat}
------------------------------------------------------------------------
r1237 | timfox | 2006-08-31 03:36:36 +0900 (Thu, 31 Aug 2006) | 4 lines
Initial commit for clustering
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:37 a.m.
[
https://issues.jboss.org/browse/JBMESSAGING-1919?page=com.atlassian.jira....
]
Yong Hao Gao closed JBMESSAGING-1919.
-------------------------------------
Resolution: Done
Closed as fixed. Thanks Toshiya for the tips on tests.
Please verify.
Publisher doesn't get JMSException even if database (JMS
persistence) is down
-----------------------------------------------------------------------------
Key: JBMESSAGING-1919
URL: https://issues.jboss.org/browse/JBMESSAGING-1919
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.4.8.SP5, 1.4.8.SP6
Reporter: Toshiya Kobayashi
Assignee: Yong Hao Gao
Fix For: 1.4.0.SP3.CP15, 1.4.8.SP7
Attachments: jms-publisher-subscriber.zip, mysql-ds.xml,
mysql-persistence-service.xml
In case of Topic (PERSISTENT mode, Durable Subscriber), Publisher doesn't get
JMSException even if database (JMS persistence) is down. Attached a reproducer.
How to reproduce:
JBoss 5.1.2
- configure MySQL as JMS persistence manager (see attached
mysql-ds.xml/mysql-persistence-service.xml)
- unzip jms-publisher-subscriber.zip
- edit build.properties for your local env
- copy test-destination-service.xml to deploy dir
- (terminal 1) ant subscriber
- (terminal 2) ant publisher
- stop MySQL
-- Subscriber fails. But Publisher keeps running though database is down
JBoss logs an error message in ChannelSupport.
{noformat}
21:37:47,292 ERROR [ChannelSupport] Failed to handle message
org.jboss.util.NestedSQLException: Unable to get managed connection for DefaultDS; -
nested throwable: (javax.resource.ResourceException: Unable to get managed connection for
DefaultDS)
{noformat}
But doesn't throw a JMSException. On the other hand, it throws a JMSException in case
of Queue.
See: ServerConnectionEndpoint
{code:java}
boolean sendMessage(JBossMessage msg, Transaction tx, boolean checkForDuplicates)
throws Exception
{
...
else if (dest.isQueue())
{
if (trace) { log.trace(this + " routing " + msg + " to
queue"); }
if (!postOffice.route(ref, new JMSCondition(true, dest.getName()), tx))
{
throw new JMSException("Failed to route " + ref + " to "
+ dest.getName());
}
}
else
{
if (trace) { log.trace(this + " routing " + msg + " to
postoffice"); }
postOffice.route(ref, new JMSCondition(false, dest.getName()), tx);
}
if (trace) { log.trace("sent " + msg); }
return true;
}
{code}
This logic is written in revision 1237. But there is no reason to avoid throwing JMS
Exception for Topic?
https://source.jboss.org/browse/JBossMessaging/trunk/src/main/org/jboss/j...
{noformat}
------------------------------------------------------------------------
r1237 | timfox | 2006-08-31 03:36:36 +0900 (Thu, 31 Aug 2006) | 4 lines
Initial commit for clustering
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:04 a.m.
[
https://issues.jboss.org/browse/JBMESSAGING-1919?page=com.atlassian.jira....
]
Toshiya Kobayashi commented on JBMESSAGING-1919:
------------------------------------------------
Thanks Howard.
I've verified the fix on my side as well.
Publisher doesn't get JMSException even if database (JMS
persistence) is down
-----------------------------------------------------------------------------
Key: JBMESSAGING-1919
URL: https://issues.jboss.org/browse/JBMESSAGING-1919
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.4.8.SP5, 1.4.8.SP6
Reporter: Toshiya Kobayashi
Assignee: Yong Hao Gao
Fix For: 1.4.0.SP3.CP15, 1.4.8.SP7
Attachments: jms-publisher-subscriber.zip, mysql-ds.xml,
mysql-persistence-service.xml
In case of Topic (PERSISTENT mode, Durable Subscriber), Publisher doesn't get
JMSException even if database (JMS persistence) is down. Attached a reproducer.
How to reproduce:
JBoss 5.1.2
- configure MySQL as JMS persistence manager (see attached
mysql-ds.xml/mysql-persistence-service.xml)
- unzip jms-publisher-subscriber.zip
- edit build.properties for your local env
- copy test-destination-service.xml to deploy dir
- (terminal 1) ant subscriber
- (terminal 2) ant publisher
- stop MySQL
-- Subscriber fails. But Publisher keeps running though database is down
JBoss logs an error message in ChannelSupport.
{noformat}
21:37:47,292 ERROR [ChannelSupport] Failed to handle message
org.jboss.util.NestedSQLException: Unable to get managed connection for DefaultDS; -
nested throwable: (javax.resource.ResourceException: Unable to get managed connection for
DefaultDS)
{noformat}
But doesn't throw a JMSException. On the other hand, it throws a JMSException in case
of Queue.
See: ServerConnectionEndpoint
{code:java}
boolean sendMessage(JBossMessage msg, Transaction tx, boolean checkForDuplicates)
throws Exception
{
...
else if (dest.isQueue())
{
if (trace) { log.trace(this + " routing " + msg + " to
queue"); }
if (!postOffice.route(ref, new JMSCondition(true, dest.getName()), tx))
{
throw new JMSException("Failed to route " + ref + " to "
+ dest.getName());
}
}
else
{
if (trace) { log.trace(this + " routing " + msg + " to
postoffice"); }
postOffice.route(ref, new JMSCondition(false, dest.getName()), tx);
}
if (trace) { log.trace("sent " + msg); }
return true;
}
{code}
This logic is written in revision 1237. But there is no reason to avoid throwing JMS
Exception for Topic?
https://source.jboss.org/browse/JBossMessaging/trunk/src/main/org/jboss/j...
{noformat}
------------------------------------------------------------------------
r1237 | timfox | 2006-08-31 03:36:36 +0900 (Thu, 31 Aug 2006) | 4 lines
Initial commit for clustering
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5147
days inactive
5166
days old
9 comments
2 participants
participants (2)
-
Toshiya Kobayashi (JIRA) -
Yong Hao Gao (JIRA)