[Design of JBoss ESB] - Transaction rollback in action pipeline
by beve
When using a global transaction with an action pipeline it is possible for a participant in the transaction to rollback the transaction. For example, an action invoking a database, could call rollback on the connection and have the global transaction rolled back.
But we are also seeing the need to be able to trigger a rollback from other actions in the pipeline.
One use case we have is where we are calling external webservices.
These webservices sometimes respond with faults, like the service is temporarliy unvailable or something like that.
We need to be able to resend these request to the webservices and thought we would use transactions for this.
When we receive a fault we would like to rollback the transaction, which will put the JMS message back on the queue for pickup. (assuming JMS transport here)
This in combination with specifying JCA/JMS redelivery properties like MaxDeliveryAttempts and RedeliveryDelay we can achive what we want.
For more information about how this redelivery could work see this jira : http://jira.jboss.com/jira/browse/JBESB-1563.
The problem is that to rollback the transaction we must throw a RuntimeException.
Is there a way to rollback the transaction in an action pipeline without throwing a RuntimeException?
Should we create an execption specifically for this need that can be used by actions, like a RollbackException?
Any thoughs on this?
Thanks,
Daniel
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132398#4132398
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132398
18 years, 1 month
[Design of JCA on JBoss] - JCA Statistics through JMX/JSR77
by vickyk
I was able to find that the
org.jboss.management.j2ee.JCAConnectionFactory.java's getPoolStats(..) does not capture the UseTime, WaitTime And WaitingThreadCount .
UseTime --> Time spend using the connection . { This is not available from the InternalManagedConnectionPool , not sure if this would be helpful}
WaitTime --> Time spent waiting for a connection to be available . { This is available through the InternalManagedConnectionPool.getTotalBlockTime() }
WaitingThreadCount --> The number of threads waiting for a connection . { This is yet not provided }
The WaitingThreadCount cannot be obtained from the Semaphore implemetation which we have , I was expecting it to have the methods which are a part of the jdk1.5 semaphore .
getQueueLength() in the java.util.concurrent.Semaphore can give us the details about the WaitingThreadCount but it is not available in the EDU.oswego.cs.dl.util.concurrent.FIFOSemaphore which is being used in the InternalManagedConnectionPool .
So I was thinking of using the Semaphore implementation from jdk1.5 in Jboss5 , which will eventually help us in getting WaitingThreadCount .
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132375#4132375
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132375
18 years, 1 month
[Design of OSGi Integration] - Re: Facade Questions
by johnbailey
"alesj" wrote : When mapping Controller states to bundle states, you should consider DeploymentStages, since those are probably the one's we're after.
| Those mentioned before are POJO centric.
|
| I would do something like this:
| ERROR --> UNINSTALLED
| NOT_INSTALLED --> INSTALLED (this one looks funny, but it's technically ok :-)
| CLASSLOADING --> RESOLVED
| REAL --> STARTING / STOPPING
| INSTALLED --> ACTIVE
It seems like the DeploymentStage isn't available through the DeploymentUnit or Controller context. I checked all the references of the DeploymentStage and didn't see it attached. It looks like the DeployersImpl translates the ControllerState into a DeploymentStage, which determines the Deployer to use.
| DeploymentControllerContext deploymentControllerContext = (DeploymentControllerContext) context;
| String stageName = toState.getStateString();
|
| DeploymentContext deploymentContext = deploymentControllerContext.getDeploymentContext();
| try
| {
| List<Deployer> theDeployers = getDeployersList(stageName);
| ...
Am I missing something? I will use the corrisponding ControllerStates for now, and we can move to the DeploymentStage if there is a way to get it. The only thing I don't see is the ControllerStates is the CLASSLOADING stage.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132359#4132359
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132359
18 years, 1 month
[Design of JBossCache] - NPE in InvalidationInterceptor.getNodeVersion()
by bstansberry＠jboss.com
>From a Hibernate/JBC integration test case:
| 16:15:20,049 WARN InvalidationInterceptor:270 - Unable to broadcast evicts as a part of the prepare phase. Rolling back.
| java.lang.NullPointerException
| at org.jboss.cache.interceptors.InvalidationInterceptor.getNodeVersion(InvalidationInterceptor.java:347)
| at org.jboss.cache.interceptors.InvalidationInterceptor.invalidateAcrossCluster(InvalidationInterceptor.java:336)
| at org.jboss.cache.interceptors.InvalidationInterceptor.invalidateModifications(InvalidationInterceptor.java:372)
| at org.jboss.cache.interceptors.InvalidationInterceptor.broadcastInvalidate(InvalidationInterceptor.java:266)
| at org.jboss.cache.interceptors.InvalidationInterceptor.handleCommitMethod(InvalidationInterceptor.java:208)
| at org.jboss.cache.interceptors.MethodDispacherInterceptor.invoke(MethodDispacherInterceptor.java:117)
| at org.jboss.cache.interceptors.Interceptor.nextInterceptor(Interceptor.java:111)
| at org.jboss.cache.interceptors.NotificationInterceptor.handleCommitMethod(NotificationInterceptor.java:42)
| at org.jboss.cache.interceptors.MethodDispacherInterceptor.invoke(MethodDispacherInterceptor.java:117)
| at org.jboss.cache.interceptors.Interceptor.nextInterceptor(Interceptor.java:111)
| at org.jboss.cache.interceptors.TxInterceptor.handleCommitRollback(TxInterceptor.java:849)
| at org.jboss.cache.interceptors.TxInterceptor.runCommitPhase(TxInterceptor.java:896)
| at org.jboss.cache.interceptors.TxInterceptor$RemoteSynchronizationHandler.afterCompletion(TxInterceptor.java:1240)
| at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.afterCompletion(TxInterceptor.java:1404)
| at org.jboss.cache.interceptors.OrderedSynchronizationHandler.afterCompletion(OrderedSynchronizationHandler.java:95)
| at org.hibernate.test.tm.SimpleJtaTransactionImpl.commit(SimpleJtaTransactionImpl.java:95)
| at org.hibernate.test.tm.SimpleJtaTransactionManagerImpl.commit(SimpleJtaTransactionManagerImpl.java:85)
| at org.hibernate.test.cache.jbc2.functional.bulk.BulkOperationsTest.createContacts(BulkOperationsTest.java:137)
| at org.hibernate.test.cache.jbc2.functional.bulk.BulkOperationsTest.testBulkOperations(BulkOperationsTest.java:87)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at junit.framework.TestCase.runTest(TestCase.java:154)
| at org.hibernate.junit.functional.FunctionalTestCase.runTest(FunctionalTestCase.java:125)
| at junit.framework.TestCase.runBare(TestCase.java:127)
| at org.hibernate.junit.UnitTestCase.runBare(UnitTestCase.java:63)
| at junit.framework.TestResult$1.protect(TestResult.java:106)
| at junit.framework.TestResult.runProtected(TestResult.java:124)
| at junit.framework.TestResult.run(TestResult.java:109)
| at junit.framework.TestCase.run(TestCase.java:118)
| at junit.framework.TestSuite.runTest(TestSuite.java:208)
| at junit.framework.TestSuite.run(TestSuite.java:203)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
| at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
| at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
| at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290)
| at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818)
This happens during a commit of a tx that did a bunch of put calls, plus some remove calls for nodes that didn't actually exist in the local cache.
The getNodeVersion() code that fails looks like this:
| protected DataVersion getNodeVersion(TransactionWorkspace w, Fqn f)
| {
| if (w == null) return null;
| WorkspaceNode wn = w.getNode(f);
| DataVersion v = wn.getVersion();
| ...
|
NPE in last line because wn is null.
I think the problem is because the fqn points to a node that doesn't exist in the workspace -- i.e. a nodeRemove() call was made for it, so the Fqn got associated with the tx, but no node w/ that fqn existed, so there's no node in the workspace.
I tried to write a simple unit test to demonstrate that, but it passes. ??? So, instead of a JIRA I'm opening a forum thread.
OT: the invalidation messages associated with a tx aren't batched. :-(
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132353#4132353
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132353
18 years, 1 month