[JBoss JIRA] Closed: (JBMESSAGING-353) ConnectionConsumerTest.testRedeliveryTransacted() fails on Mac OSX 10.4.6 but passes on Windows
by Tim Fox (JIRA)
[ http://jira.jboss.com/jira/browse/JBMESSAGING-353?page=all ]
Tim Fox closed JBMESSAGING-353.
-------------------------------
Resolution: Out of Date
The problem no longer seems to occur - probably because the message delivery code has been heavily refactored since it was posted.
> ConnectionConsumerTest.testRedeliveryTransacted() fails on Mac OSX 10.4.6 but passes on Windows
> -----------------------------------------------------------------------------------------------
>
> Key: JBMESSAGING-353
> URL: http://jira.jboss.com/jira/browse/JBMESSAGING-353
> Project: JBoss Messaging
> Issue Type: Bug
> Components: JMS Facade, Tests and Performance
> Affects Versions: 1.0.0, 1.0.1.CR1
> Environment: mac osx 10.4.6
> JDK 1.4.2_09
> JDK 1.5.0_04
> Reporter: Aaron Walker
> Assigned To: Aaron Walker
> Fix For: 2.0.0 Beta 1
>
> Attachments: messaging-tests.trace.log
>
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> The testRedeliveryTransacted fail with the following:
> 1) testRedeliveryTransacted(org.jboss.test.messaging.jms.ConnectionConsumerTest)junit.framework.AssertionFailedError: Didn't receive correct messages
> at org.jboss.test.messaging.jms.ConnectionConsumerTest.testRedeliveryTransacted(ConnectionConsumerTest.java:224)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at org.jboss.test.messaging.tools.junit.SelectiveTestRunner.main(SelectiveTestRunner.java:58)
> The issue revolves around the sess.rollback around line 433 in that after the rollback and the 3 messages get redelivered and on the 3rd message the following if (!tm.getJMSRedelivered()) at line 481 evaluates to true in that the getJMSRedelivered() is false when it should be true. By placing a 1ms sleep just prior to the rollback you can get the test to pass. So after my initial investigation It appears that it may be some sort of threading issue that shows up on my mac.
> I will attached the TRACE log for this If you look at line 765 of the log it shows that the delivery count for the message is 0 when it should be 1
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 8 months
[JBoss JIRA] Updated: (JBCACHE-97) ReadWriteLockWithUpgrade: UpgradeException with more than 1 reader/writer waiting to upgrade lock
by Manik Surtani (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-97?page=all ]
Manik Surtani updated JBCACHE-97:
---------------------------------
Fix Version/s: 2.1.0.GA
(was: 2.0.0.GA)
Complexity: High
> ReadWriteLockWithUpgrade: UpgradeException with more than 1 reader/writer waiting to upgrade lock
> -------------------------------------------------------------------------------------------------
>
> Key: JBCACHE-97
> URL: http://jira.jboss.com/jira/browse/JBCACHE-97
> Project: JBoss Cache
> Issue Type: Bug
> Components: Clustering
> Reporter: Bela Ban
> Assigned To: Jason T. Greene
> Fix For: 2.1.0.GA
>
>
> TxDeadlockUnitTestCase has 2 methods that show the following stack traces:
> testMoreThanOneUpgrader:
> Upgrader#0: get(/a/b/c)
> Upgrader#1: get(/a/b/c)
> main: locks:
> /a (read owners=[<null>:2, <null>:1])
> /b (read owners=[<null>:2, <null>:1])
> /c (read owners=[<null>:2, <null>:1])
> Upgrader#0: put(/a/b/c)
> Upgrader#1: put(/a/b/c)
> Upgrader#1: org.jboss.cache.lock.LockingException: acquireWriteLock(): lock upgrade failed for /a/b/c (caller=<null>:2); - nested throwable: (org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock)
> Upgrader#0: org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:2]
> Write lock owner: null
> (caller=<null>:1)
> org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:2]
> Write lock owner: null
> (caller=<null>:1)
> at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:155)
> at org.jboss.cache.Node.acquireWriteLock(Node.java:448)
> at org.jboss.cache.Node.acquire(Node.java:417)
> at org.jboss.cache.interceptors.LockInterceptor.lock(LockInterceptor.java:199)
> at org.jboss.cache.interceptors.LockInterceptor.invoke(LockInterceptor.java:144)
> at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40)
> at org.jboss.cache.interceptors.CreateIfNotExistsInterceptor.invoke(CreateIfNotExistsInterceptor.java:145)
> at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40)
> at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:35)
> at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:2998)
> at org.jboss.cache.TreeCache.put(TreeCache.java:1657)
> at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$MyUpgrader._run(TxDeadlockUnitTestCase.java:346)
> at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213)
> at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213)
> and
> testConcurrentUpgrade():
> MyThread#1: get(/a/b/c)
> MyThread#2: get(/a/b/c)
> MyThread#2: done, locks:
> /a (read owners=[<null>:2])
> /b (read owners=[<null>:2])
> /c (read owners=[<null>:2])
> MyThread#1: done, locks:
> /a (read owners=[<null>:2, <null>:1])
> /b (read owners=[<null>:2, <null>:1])
> /c (read owners=[<null>:2, <null>:1])
> MyThread#2: put(/a/b/c)
> MyThread#1: put(/a/b/c)
> MyThread#1: org.jboss.cache.lock.LockingException: acquireWriteLock(): lock upgrade failed for /a/b/c (caller=<null>:1); - nested throwable: (org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock)
> MyThread#2: org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:1]
> Write lock owner: null
> (caller=<null>:2)
> org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:1]
> Write lock owner: null
> (caller=<null>:2)
> at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:155)
> at org.jboss.cache.Node.acquireWriteLock(Node.java:448)
> at org.jboss.cache.Node.acquire(Node.java:417)
> at org.jboss.cache.interceptors.LockInterceptor.lock(LockInterceptor.java:199)
> at org.jboss.cache.interceptors.LockInterceptor.invoke(LockInterceptor.java:144)
> at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40)
> at org.jboss.cache.interceptors.CreateIfNotExistsInterceptor.invoke(CreateIfNotExistsInterceptor.java:145)
> at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40)
> at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:35)
> at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:2998)
> at org.jboss.cache.TreeCache.put(TreeCache.java:1657)
> at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$MyThread._run(TxDeadlockUnitTestCase.java:317)
> at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213)
> at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 8 months
[JBoss JIRA] Created: (JBMESSAGING-930) Error closing a session
by Bill Burke (JIRA)
Error closing a session
-----------------------
Key: JBMESSAGING-930
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-930
Project: JBoss Messaging
Issue Type: Bug
Affects Versions: 1.2.0.SP2
Reporter: Bill Burke
Assigned To: Clebert Suconic
Fix For: 1.2.0.SP2
Getting an error that I cannot reproduce all the time. I think it might be in the JMS Inbound adapter but I can't be sure. Using messaging version currently in AS Head: 1.2.0.SP.snapshot.aop2beta. I can't seem to reproduce it which leads me to believe it is a race condition someplace.
ERROR 28-03 17:15:21,093 (JmsServerSessionPool.java:getServerSession:141) -Unable to get a server session
java.lang.Exception: Cannot get a server session after the pool is stopped
at org.jboss.resource.adapter.jms.inflow.JmsServerSessionPool.getServerSession(JmsServerSessionPool.java:118)
at org.jboss.jms.client.JBossConnectionConsumer.run(JBossConnectionConsumer.java:272)
at java.lang.Thread.run(Thread.java:595)
WARN 28-03 17:15:21,093 (JBossConnectionConsumer.java:run:303) -Connection consumer closing due to error in listening thread JBossConnectionConsumer[22, 1]
javax.jms.JMSException: Unable to get a server session java.lang.Exception: Cannot get a server session after the pool is stopped
at org.jboss.resource.adapter.jms.inflow.JmsServerSessionPool.getServerSession(JmsServerSessionPool.java:142)
at org.jboss.jms.client.JBossConnectionConsumer.run(JBossConnectionConsumer.java:272)
at java.lang.Thread.run(Thread.java:595)
WARN 28-03 17:15:21,234 (Dispatcher.java:unregisterTarget:89) -Cannot find object with id 22 to register
ERROR 28-03 17:15:21,250 (ExceptionUtil.java:handleJMSInvocation:64) -ConsumerEndpoint[22] close [abe5q-hgmx02-ezu7vm8b-1-ezu7w52a-35]
javax.jms.IllegalStateException: Cannot find consumer with id 22 to remove
at org.jboss.jms.server.endpoint.ServerSessionEndpoint.removeConsumer(ServerSessionEndpoint.java:768)
at org.jboss.jms.server.endpoint.ServerConsumerEndpoint.close(ServerConsumerEndpoint.java:386)
at org.jboss.jms.server.endpoint.advised.ConsumerAdvised.org$jboss$jms$server$endpoint$advised$ConsumerAdvised$close$aop(ConsumerAdvised.java:59)
at org.jboss.jms.server.endpoint.advised.ConsumerAdvised$JoinPoint_close_N_4742752445160157748.dispatch(ConsumerAdvised$JoinPoint_close_N_4742752445160157748.java)
at org.jboss.jms.server.endpoint.advised.JoinPoint_close_N_4742752445160157748_91.invokeNext(JoinPoint_close_N_4742752445160157748_91.java)
at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
at org.jboss.jms.server.endpoint.advised.JoinPoint_close_N_4742752445160157748_91.invokeNext(JoinPoint_close_N_4742752445160157748_91.java)
at org.jboss.jms.server.endpoint.advised.JoinPoint_close_N_4742752445160157748_91.invokeJoinpoint(JoinPoint_close_N_4742752445160157748_91.java)
at org.jboss.jms.server.endpoint.advised.ConsumerAdvised$ConsumerAdvisedAdvisor.close_N_4742752445160157748(ConsumerAdvised$ConsumerAdvisedAdvisor.java)
at org.jboss.jms.server.endpoint.advised.ConsumerAdvised.close(ConsumerAdvised.java)
at org.jboss.jms.wireformat.CloseRequest.serverInvoke(CloseRequest.java:66)
at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:125)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:715)
at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:101)
at org.jboss.remoting.Client.invoke(Client.java:1414)
at org.jboss.remoting.Client.invoke(Client.java:511)
at org.jboss.remoting.Client.invoke(Client.java:499)
at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:184)
at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:155)
at org.jboss.jms.client.delegate.ClientConsumerDelegate.org$jboss$jms$client$delegate$ClientConsumerDelegate$close$aop(ClientConsumerDelegate.java:116)
at org.jboss.jms.client.delegate.ClientConsumerDelegate$JoinPoint_close_N_4742752445160157748.dispatch(ClientConsumerDelegate$JoinPoint_close_N_4742752445160157748.java)
at org.jboss.jms.client.delegate.JoinPoint_close_N_4742752445160157748_89.invokeNext(JoinPoint_close_N_4742752445160157748_89.java)
at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:91)
at org.jboss.jms.client.delegate.JoinPoint_close_N_4742752445160157748_89.invokeNext(JoinPoint_close_N_4742752445160157748_89.java)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:171)
at org.jboss.jms.client.delegate.JoinPoint_close_N_4742752445160157748_89.invokeNext(JoinPoint_close_N_4742752445160157748_89.java)
at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:71)
at org.jboss.jms.client.delegate.JoinPoint_close_N_4742752445160157748_89.invokeNext(JoinPoint_close_N_4742752445160157748_89.java)
at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
at org.jboss.jms.client.delegate.JoinPoint_close_N_4742752445160157748_89.invokeNext(JoinPoint_close_N_4742752445160157748_89.java)
at org.jboss.jms.client.delegate.JoinPoint_close_N_4742752445160157748_89.invokeJoinpoint(JoinPoint_close_N_4742752445160157748_89.java)
at org.jboss.jms.client.delegate.ClientConsumerDelegate$ClientConsumerDelegateAdvisor.close_N_4742752445160157748(ClientConsumerDelegate$ClientConsumerDelegateAdvisor.java)
at org.jboss.jms.client.delegate.ClientConsumerDelegate$ClientConsumerDelegateInstanceAdvisor.close_N_4742752445160157748(ClientConsumerDelegate$ClientConsumerDelegateInstanceAdvisor.java)
at org.jboss.jms.client.delegate.ClientConsumerDelegate.close(ClientConsumerDelegate.java)
at org.jboss.jms.client.container.ClosedInterceptor.maintainRelatives(ClosedInterceptor.java:296)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:166)
at org.jboss.jms.client.delegate.JoinPoint_closing_N_1847373599029068216_84.invokeNext(JoinPoint_closing_N_1847373599029068216_84.java)
at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:71)
at org.jboss.jms.client.delegate.JoinPoint_closing_N_1847373599029068216_84.invokeNext(JoinPoint_closing_N_1847373599029068216_84.java)
at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
at org.jboss.jms.client.delegate.JoinPoint_closing_N_1847373599029068216_84.invokeNext(JoinPoint_closing_N_1847373599029068216_84.java)
at org.jboss.jms.client.delegate.JoinPoint_closing_N_1847373599029068216_84.invokeJoinpoint(JoinPoint_closing_N_1847373599029068216_84.java)
at org.jboss.jms.client.delegate.ClientSessionDelegate$ClientSessionDelegateAdvisor.closing_N_1847373599029068216(ClientSessionDelegate$ClientSessionDelegateAdvisor.java)
at org.jboss.jms.client.delegate.ClientSessionDelegate$ClientSessionDelegateInstanceAdvisor.closing_N_1847373599029068216(ClientSessionDelegate$ClientSessionDelegateInstanceAdvisor.java)
at org.jboss.jms.client.delegate.ClientSessionDelegate.closing(ClientSessionDelegate.java)
at org.jboss.jms.client.JBossConnectionConsumer.doClose(JBossConnectionConsumer.java:329)
at org.jboss.jms.client.JBossConnectionConsumer.run(JBossConnectionConsumer.java:308)
at java.lang.Thread.run(Thread.java:595)
ERROR 28-03 17:15:21,250 (DelegateSupport.java:handleThrowable:224) -Failed
java.lang.Exception: Can not make remoting client invocation due to not being connected to server.
at org.jboss.remoting.Client.invoke(Client.java:1419)
at org.jboss.remoting.Client.invoke(Client.java:511)
at org.jboss.remoting.Client.invoke(Client.java:499)
at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:184)
at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:155)
at org.jboss.jms.client.delegate.ClientSessionDelegate.org$jboss$jms$client$delegate$ClientSessionDelegate$closing$aop(ClientSessionDelegate.java:149)
at org.jboss.jms.client.delegate.ClientSessionDelegate$JoinPoint_closing_N_1847373599029068216.dispatch(ClientSessionDelegate$JoinPoint_closing_N_1847373599029068216.java)
at org.jboss.jms.client.delegate.JoinPoint_closing_N_1847373599029068216_84.invokeNext(JoinPoint_closing_N_1847373599029068216_84.java)
at org.jboss.jms.client.container.SessionAspect.handleClosing(SessionAspect.java:200)
at org.jboss.jms.client.delegate.JoinPoint_closing_N_1847373599029068216_84.invokeNext(JoinPoint_closing_N_1847373599029068216_84.java)
at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:91)
at org.jboss.jms.client.delegate.JoinPoint_closing_N_1847373599029068216_84.invokeNext(JoinPoint_closing_N_1847373599029068216_84.java)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:171)
at org.jboss.jms.client.delegate.JoinPoint_closing_N_1847373599029068216_84.invokeNext(JoinPoint_closing_N_1847373599029068216_84.java)
at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:71)
at org.jboss.jms.client.delegate.JoinPoint_closing_N_1847373599029068216_84.invokeNext(JoinPoint_closing_N_1847373599029068216_84.java)
at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
at org.jboss.jms.client.delegate.JoinPoint_closing_N_1847373599029068216_84.invokeNext(JoinPoint_closing_N_1847373599029068216_84.java)
at org.jboss.jms.client.delegate.JoinPoint_closing_N_1847373599029068216_84.invokeJoinpoint(JoinPoint_closing_N_1847373599029068216_84.java)
at org.jboss.jms.client.delegate.ClientSessionDelegate$ClientSessionDelegateAdvisor.closing_N_1847373599029068216(ClientSessionDelegate$ClientSessionDelegateAdvisor.java)
at org.jboss.jms.client.delegate.ClientSessionDelegate$ClientSessionDelegateInstanceAdvisor.closing_N_1847373599029068216(ClientSessionDelegate$ClientSessionDelegateInstanceAdvisor.java)
at org.jboss.jms.client.delegate.ClientSessionDelegate.closing(ClientSessionDelegate.java)
at org.jboss.jms.client.JBossConnectionConsumer.doClose(JBossConnectionConsumer.java:329)
at org.jboss.jms.client.JBossConnectionConsumer.run(JBossConnectionConsumer.java:308)
at java.lang.Thread.run(Thread.java:595)
ERROR 28-03 17:15:21,250 (JBossConnectionConsumer.java:run:312) -Failed to close connection consumer
org.jboss.jms.util.MessagingJMSException: Failed to invoke
at org.jboss.jms.client.delegate.DelegateSupport.handleThrowable(DelegateSupport.java:225)
at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:200)
at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:155)
at org.jboss.jms.client.delegate.ClientSessionDelegate.org$jboss$jms$client$delegate$ClientSessionDelegate$closing$aop(ClientSessionDelegate.java:149)
at org.jboss.jms.client.delegate.ClientSessionDelegate$JoinPoint_closing_N_1847373599029068216.dispatch(ClientSessionDelegate$JoinPoint_closing_N_1847373599029068216.java)
at org.jboss.jms.client.delegate.JoinPoint_closing_N_1847373599029068216_84.invokeNext(JoinPoint_closing_N_1847373599029068216_84.java)
at org.jboss.jms.client.container.SessionAspect.handleClosing(SessionAspect.java:200)
at org.jboss.jms.client.delegate.JoinPoint_closing_N_1847373599029068216_84.invokeNext(JoinPoint_closing_N_1847373599029068216_84.java)
at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:91)
at org.jboss.jms.client.delegate.JoinPoint_closing_N_1847373599029068216_84.invokeNext(JoinPoint_closing_N_1847373599029068216_84.java)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:171)
at org.jboss.jms.client.delegate.JoinPoint_closing_N_1847373599029068216_84.invokeNext(JoinPoint_closing_N_1847373599029068216_84.java)
at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:71)
at org.jboss.jms.client.delegate.JoinPoint_closing_N_1847373599029068216_84.invokeNext(JoinPoint_closing_N_1847373599029068216_84.java)
at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
at org.jboss.jms.client.delegate.JoinPoint_closing_N_1847373599029068216_84.invokeNext(JoinPoint_closing_N_1847373599029068216_84.java)
at org.jboss.jms.client.delegate.JoinPoint_closing_N_1847373599029068216_84.invokeJoinpoint(JoinPoint_closing_N_1847373599029068216_84.java)
at org.jboss.jms.client.delegate.ClientSessionDelegate$ClientSessionDelegateAdvisor.closing_N_1847373599029068216(ClientSessionDelegate$ClientSessionDelegateAdvisor.java)
at org.jboss.jms.client.delegate.ClientSessionDelegate$ClientSessionDelegateInstanceAdvisor.closing_N_1847373599029068216(ClientSessionDelegate$ClientSessionDelegateInstanceAdvisor.java)
at org.jboss.jms.client.delegate.ClientSessionDelegate.closing(ClientSessionDelegate.java)
at org.jboss.jms.client.JBossConnectionConsumer.doClose(JBossConnectionConsumer.java:329)
at org.jboss.jms.client.JBossConnectionConsumer.run(JBossConnectionConsumer.java:308)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.Exception: Can not make remoting client invocation due to not being connected to server.
at org.jboss.remoting.Client.invoke(Client.java:1419)
at org.jboss.remoting.Client.invoke(Client.java:511)
at org.jboss.remoting.Client.invoke(Client.java:499)
at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:184)
... 21 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 8 months
[JBoss JIRA] Created: (JBRULES-838) Disabling right-indexing means a rule no longer fires
by P Robinson (JIRA)
Disabling right-indexing means a rule no longer fires
-----------------------------------------------------
Key: JBRULES-838
URL: http://jira.jboss.com/jira/browse/JBRULES-838
Project: JBoss Rules
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 3.0.6, 3.0.5
Environment: Windows XP and also Linux Ubuntu. Using Drools within RepastJ social simulation framework, Java 1.6.0.
Reporter: P Robinson
Assigned To: Mark Proctor
When I disable right-indexing, one of the rules no longer fires the second time around ("Accept school place application" in school.drl, see test uploaded to forum posting) which escalates into further problems with the program.
The first symptom of the rule not firing is when the message "1JUST ACCEPTED WRONG NUM CHILDREN: 186 instead of 200" is printed to the console (as a direct result of the above rule not firing). This does not occur when right-indexing is enabled.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 8 months
[JBoss JIRA] Created: (JBRULES-790) DSL mechanism not working if some keywords are part of the DSL
by Gilles Dubuc (JIRA)
DSL mechanism not working if some keywords are part of the DSL
--------------------------------------------------------------
Key: JBRULES-790
URL: http://jira.jboss.com/jira/browse/JBRULES-790
Project: JBoss Rules
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Drl Parser/Builder
Affects Versions: 3.1-m1, 3.0.6
Environment: Issue happened with both 3.1-m1 and
Reporter: Gilles Dubuc
Assigned To: Mark Proctor
Please ignore what this rule actually does when executed, as this is a syntax issue in the DSL/DRL parsing.
If you have a DSL like this:
[when]Invoke rule executor=ruleExec: RuleExecutor()
[then]Execute rule "{id}"=ruleExec.ExecuteSubRule( new Long({id}));
and a DRL like that:
package something;
rule "1"
when
Invoke rule executor
then
Execute rule "5"
end
When calling addPackageFromnDrl( drl, dsl ) you get an exception about "Invoke" not being a keyword (I can reproduce the error and provide the exception if needed). What I'm guessing is happening is the following:
Before going through the DSL to translate the DRL file, the DRL is broken down into rules and their when/then parts. Since there is the word "rule" in "Execute rule executor" the parser thinks it's the start of a new rule. Even more so with "Execute rule "5"" because of the quotes. Strangely enough it probably goes beyond that stage and the parser assumes that "Invoke" is the only text present in the when part of rule "1". And obviously there is no translation for "Invoke" in the DSL.
Maybe I missed it, but I didn't see any mention of the fact that DRL keywords have to be avoided in the left parts or DSL statements. If it's missing from the documentation maybe it would be worth being added to it. It took me a huge amount of time before understanding that the issue came from there, banging my head for hours on the DSL translation suddenly not working even made me reimplement the DSL translation mechanism using StringTemplate...
I haven't checked if "when" and "then" induce similar issues, but if they do it might be limiting for some uses of the DSL to have to avoid these words. In that case, maybe revising the part of the parser interpreting a DSL-ed DRL would be required. It all comes down to the parser knowing accurately which parts of the DSL file are the rules, their LHS and RHS. As far as I know it shouldn't be possible to define a rule in the middle of the when statement of another one, so there is no reason why the "rule" in "Invoke rule executor" should be treated as the start of a new rule. Same goes for the "Execute rule" that sits in the RHS of another rule.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 8 months