[JBoss JIRA] Created: (JBESB-1544) Defer jBPM variable setting until in asynch job
by Kevin Conner (JIRA)
Defer jBPM variable setting until in asynch job
-----------------------------------------------
Key: JBESB-1544
URL: http://jira.jboss.com/jira/browse/JBESB-1544
Project: JBoss ESB
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Process flow
Affects Versions: 4.2.1 CP1
Reporter: Kevin Conner
Assigned To: Kevin Conner
Fix For: 4.2.1 CP1
The current codebase sets the process variables before creating the asynchronous job but, unfortunately, doing it in this fashion creates a single point of conflict in the root token.
The result is that, in a concurrent environment, we receive StaleObject exceptions when there are multiple callbacks trying to update the root token.
Deferring these settings until the asynchronous job has an opportunity to run will reduce the possibility of the conflict.
--
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
16 years, 4 months
[JBoss JIRA] Created: (JBESB-1543) notify jBPM JobExecutor at end of transaction
by Kevin Conner (JIRA)
notify jBPM JobExecutor at end of transaction
---------------------------------------------
Key: JBESB-1543
URL: http://jira.jboss.com/jira/browse/JBESB-1543
Project: JBoss ESB
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Process flow
Affects Versions: 4.2.1 CP1
Reporter: Kevin Conner
Assigned To: Kevin Conner
Fix For: 4.2.1 CP1
The jBPM DbMessageService creates jobs for consumption of the JobExecutor. When the MessageStore is closed it notifies the JobExecutor that some jobs have been created.
In a transactional environment this notification occurs during the normal processing of the transaction and, therefore, the transaction may not have committed by the time the JobExecutor scans.
The notification should really be made at the end of the transaction so that the modifications to the DB have been committed before the JobExecutor runs.
--
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
16 years, 4 months
[JBoss JIRA] Created: (JBESB-1492) "JMSException: Failed to route Reference" during failover
by Martin Vecera (JIRA)
"JMSException: Failed to route Reference" during failover
---------------------------------------------------------
Key: JBESB-1492
URL: http://jira.jboss.com/jira/browse/JBESB-1492
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Rosetta
Affects Versions: 4.2.1
Environment: SOA-P 4.2.1.beta1, Oracle DB
Reporter: Martin Vecera
First see atached archive for all the referenced files.
Problem:
I deployed the same service to two nodes in JMS cluster (see scen1_supported.png). Then I started to generate messages to the queue quickstart_helloworld_Request_gw. I tried several times to undeploy and deploy again the service on both nodes (not at both nodes at the same time). It isn't so easy to reproduce this issue when I start with clean DB and fresh server instances. But once the error appeared you can reach it 100%. The node where the service is currently undeployed shows the errors (see below and node1.log) unfinitely (for more then 1 minute). The second node stops processing the messages during the errors. Once the service is deployed again on the first node the normal processing continues.
2008-01-16 14:24:56,028 ERROR [org.jboss.messaging.util.ExceptionUtil] SessionEndpoint[yeg-zagowhbf-1-45evvhbf-5vn4jb-a4wya] send [c3j-c4sowhbf-1-45evvhbf-5vn4jb-a4wya]
javax.jms.JMSException: Failed to route Reference[62704]:RELIABLE to quickstart_helloworld_Request_esb
at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendMessage(ServerConnectionEndpoint.java:743)
at org.jboss.jms.server.endpoint.ServerSessionEndpoint.send(ServerSessionEndpoint.java:383)
at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$send$aop(SessionAdvised.java:87)
at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_7280680627620114891.invokeNext(SessionAdvised$send_7280680627620114891.java)
at org.jboss.jms.server.container.SecurityAspect.handleSend(SecurityAspect.java:157)
at sun.reflect.GeneratedMethodAccessor143.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:121)
at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_7280680627620114891.invokeNext(SessionAdvised$send_7280680627620114891.java)
at org.jboss.jms.server.endpoint.advised.SessionAdvised.send(SessionAdvised.java)
at org.jboss.jms.wireformat.SessionSendRequest.serverInvoke(SessionSendRequest.java:95)
at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:143)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:795)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:573)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:387)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:166)
I also tried scen1_unsupported.png configuration with the same result. I was not able to reach this problem when all the queues were deployed independently on the server.
For instructions on how to switch ESB to use Oracle DB see dbinstall.howto.txt.
To be able to deploy the Performance1 service you need to deploy test-result-service.sar first.
--
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
16 years, 4 months
[JBoss JIRA] Created: (JBESB-1539) Problem starting 2nd node in cluster for the first time
by Tom Cunningham (JIRA)
Problem starting 2nd node in cluster for the first time
-------------------------------------------------------
Key: JBESB-1539
URL: http://jira.jboss.com/jira/browse/JBESB-1539
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Message Store
Affects Versions: 4.2.1
Environment: JBoss EAP 4.3
JBoss ESB 4.2.1
Reporter: Tom Cunningham
Seeing a problem with JBoss ESB 4.2.1 on top of JBoss EAP 4.3. The first time (and only the first time) that the ESB queues start up on the second node in the cluster, they throw errors that the queue had already been created. I'm pasting the logs in here - the configuration here is internal so it should be possible to log on to their machine and tweak/test things if necessary. Contact Matt Hicks (mhicks(a)redhat.com).
--
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
16 years, 4 months