[jBPM Users] - Re: Process Step Exception
by guancio
I got the same exception using jbpm 3.2 on JBoss 5. After 4 hours of investigation I've found that my development approach was not correct.
The main cause of the problem was that I was trying to use the JBPM enterprise installation from a Web Application deployed on the same JBoss container. My first attempt was to add the jbpm-identity and jbpm-jpdl jars as J2EE module dependencies and deploy them inside WEB-INF/lib of my War.
Initially, this step was required to avoid class not found exception while accessing to the jbpm structures.
I think that the java.lang.ClassCastException occurred because the interface of org.jbpm.msg.jms.JmsMessageServiceFactory is not present inside jbpm-identity and jbpm-jpdl jars. Instead the interface is located inside the jbpm-enterprise.jar directory.
Namely, I think that Java run-time raises the exception because jbpm-enterprise.jar is loaded by a different Java class loader.
I solved my problem as follows:
| I removed jbpm-* jars from my WEB-INF/lib deployment
| I deployed the war of my application inside deploy/jbpm directory of JBoss, instead of deploy. This avoid the class not found exceptions
| I added the web.xml and jboss-web.xml deployment descriptors inside my WEB-INF directory, using the contents described in http://docs.jboss.com/jbpm/v3.2/userguide/html_single/#clientcomponents. This avoid jms name not bound exceptions.
|
|
| I think that JBoss documentation on how to use jbpm from Web and enterprise applications really lacks details and a good tutorial.
|
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4270272#4270272
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4270272
16 years, 1 month
[jBPM Users] - Re: task & timers
by MohReece
Unfortunately your stack trace doesn't show the real (original) exception, maybe there is a 'caused by' trace underneath it? But from this one, more particular the line
at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:276)
we are able to see that the exception originates in the executeAction(...) method, indicating there's either an exception is thrown in the execution of the Action (and thus most likely in the ActionHandler), or something went wrong in the locking of the Token (and that would be my first guess here).
When you signal a Token from within an ActionHandler, chances are that the call executing the ActionHandler already locked the Token (for the duration of the Action's execution, see GraphElement.java lines 241-264). The signal call causes the node-leave event, which in turn causes your DefaultEnd handler to be called... but before it gets there it tries to lock the Token - again.
A signal should be used 'from the outside' to trigger a process instance to move on, from the inside it's possibly safe (depends on the node type really) to directly use the leave(...) method. You can try replacing the line
token.signal(isOK ? "OK" : "KO");
with
executionContext.getNode().leave(executionContext, isOK ? "OK" : "KO");
to see whether this works for you.
Hope this helps a bit more!
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4270261#4270261
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4270261
16 years, 1 month
[JBoss Cache Users] - data Gravitation on first call - fetches state from backup
by baranowb
Hey
I have been playing with cache recently a bit again. bfore posting got through forum posts about gravitation - some seemed closely related.
In jboss wiki I saw post about organization of data, which (/data/server1,/data/server2) which is a bit odd and framkly not applicable.
Version = 3.1.0GA - one that ships with AS 5.1
Ok so setup is:
2+ nodes, buddy groups == 2
Conf:
| <property name="buddyReplicationConfig">
| <bean class="org.jboss.cache.config.BuddyReplicationConfig">
|
| <!-- Just set to true to turn on buddy replication -->
| <property name="enabled">true</property>
|
| <!-- A way to specify a preferred replication group. We try
| and pick a buddy who shares the same pool name (falling
| back to other buddies if not available). -->
| <property name="buddyPoolName">default</property>
|
| <property name="buddyCommunicationTimeout">17500</property>
|
| <!-- Do not change these -->
| <property name="autoDataGravitation">true</property>
| <property name="dataGravitationRemoveOnFind">false</property>
| <property name="dataGravitationSearchBackupTrees">true</property>
|
| <property name="buddyLocatorConfig">
| <bean class="org.jboss.cache.buddyreplication.NextMemberBuddyLocatorConfig">
| <!-- The number of backup copies we maintain -->
| <property name="numBuddies">2</property>
| <!-- Means that each node will *try* to select a buddy on
| a different physical host. If not able to do so
| though, it will fall back to colocated nodes. -->
| <property name="ignoreColocatedBuddies">false</property>
| </bean>
| </property>
| </bean>
| </property>
|
Now. Data is organized as follows:
/ac
/ACH[1] { x=y}
/SomeOtherdataOfACH
/timers
/timer1 {x=y}
/timer2 {x=y}
/SomeMoreDataOfTimer
etc.
Now upon startup of each node we fetch /, than ac or any other "data root".
>From what manik said JBC performs gravitation per node, so before making any calls related to / and immediate children(ac,timer, ...)
I override options:
- cachemodelocal = true
- skipdatagravitation = true
Now I would assume taht there is only local check for existance. And if node is not found it would be added silently, without any children. This seems(as there is no other node) when first node starts.
Now consider scenario:
N_1, N_2
1. N_1 starts, it initializes itself, creates / and all immediate children.
2. something gets deployed on N_1, children of /ac and other are created.
2. N_2 starts, it gets to point when it wants to retrieve /ac
- _BUDDY_BACKUP_/N_1_PORT with all content of N_1 data exists.
- cache mode is set to local, data gravitation is supresed.
so its like:
| InvocationContext ic = getJBossCache().getInvocationContext();
| ic.getOptionOverrides().setCacheModeLocal(true);
| ic.getOptionOverrides().setSkipDataGravitation(true);
| Node root = getJBossCache().getRoot();
|
| ic.getOptionOverrides().setCacheModeLocal(true);
| ic.getOptionOverrides().setSkipDataGravitation(true);
| //where nodeFqn == /ac, /timers, .....
| this.node=root.getChild(nodeFqn);
|
After this I can see contents of N_1 cache as:
| /ac
| /timers
| /something else
| /_BUDDY_BACKUP_/N_2_PORT
| /ac
| /ACH[1] { x=y}
| /SomeOtherdataOfACH
| /timers
| /timer1 {x=y}
| /timer2 {x=y}
| /SomeMoreDataOfTimer
|
In trace level I see that gravitation happens, a bit unexpected, isnt it ?
If service/app performs some operations after startup bulk gravitation, nothing like that happens.
N_1 now can freely add content to any immediate child of "/", same goes for N_2 or any other - changes do not trigger gravitation(even without changing override options like now it is done).
here is part of trace log: http://pastebin.com/f321486d1
Any idea why this happens on init, and after that it does not(as expected) ?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4270255#4270255
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4270255
16 years, 1 month
