[jBPM] - in jBPM 4.3, can a state node's handler choose its outgoing transition?
by Tun Mang
Tun Mang [http://community.jboss.org/people/tunmang] created the discussion
"in jBPM 4.3, can a state node's handler choose its outgoing transition?"
To view the discussion, visit: http://community.jboss.org/message/549404#549404
--------------------------------------------------------------
Hi there,
For a particular process definition, we would like to add a state node which associates with an "end" event handler as shown below:
<state name="JobTranscode" >
<on event="end">
<event-listener class="com....components.TranscodeHandler" />
</on>
<transition name="Failed" to="UserTask"/>
<transition name="Success" to="end1"/>
</state>
There will be a stand-alone application calling the "signal process" for this state node so that the TranscodeHandler class (implements EventListener) will receive the "end event". And the TranscodeHandler class will override the "notify" function to implement the logic to decide a final outgoing transition for this state node.
Is this doable in jBPM 4.3 ? If yes, how does the stand-alone application call the "signal process" ? And how does the (override) "notify" function set the final outgoing transition ?
Or this is doable in jBPM, but the approach is different from what we thought ?
Any advice is very appreciated.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/549404#549404]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 10 months
[jBPM Development] - Close ProcessEngine upon BPM console undeployment
by Alejandro Guizar
Alejandro Guizar [http://community.jboss.org/people/alex.guizar%40jboss.com] created the discussion
"Close ProcessEngine upon BPM console undeployment"
To view the discussion, visit: http://community.jboss.org/message/549378#549378
--------------------------------------------------------------
Regarding https://jira.jboss.org/browse/JBPM-2881 JBPM-2881, it seems the process engine is not closed when the BPM console is undeployed. ProcessEngineImpl stops the job executor on close. However, the job dispatcher thread is still running after the web application stops, as evidenced by the following stack trace.
22/06/2010 08:43:28 PM org.apache.catalina.loader.WebappClassLoader loadClass
INFO: Illegal access: this web application instance has been stopped already.
Could not load org.jbpm.pvm.internal.tx.StandardTransaction.
The eventual following stack trace is caused by an error thrown for debugging purposes
as well as to attempt to terminate the thread which caused the illegal access,
and has no functional impact.
java.lang.IllegalStateException
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1402)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1361)
at org.jbpm.pvm.internal.util.ReflectUtil.classForName(ReflectUtil.java:453)
at org.jbpm.pvm.internal.wire.descriptor.ObjectDescriptor.construct(ObjectDescriptor.java:141)
at org.jbpm.pvm.internal.wire.WireContext.construct(WireContext.java:487)
at org.jbpm.pvm.internal.wire.WireContext.create(WireContext.java:466)
at org.jbpm.pvm.internal.wire.WireContext.create(WireContext.java:455)
at org.jbpm.pvm.internal.wire.WireContext.get(WireContext.java:429)
at org.jbpm.pvm.internal.wire.WireContext.get(WireContext.java:339)
at org.jbpm.pvm.internal.wire.WireContext.get(WireContext.java:706)
at org.jbpm.pvm.internal.env.BasicEnvironment.get(BasicEnvironment.java:132)
at org.jbpm.pvm.internal.env.BasicEnvironment.get(BasicEnvironment.java:123)
at org.jbpm.pvm.internal.tx.StandardTransactionInterceptor.execute(StandardTransactionInterceptor.java:46)
at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.executeInNewEnvironment(EnvironmentInterceptor.java:53)
at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:40)
at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:56)
at org.jbpm.pvm.internal.svc.SkipInterceptor.execute(SkipInterceptor.java:43)
at org.jbpm.pvm.internal.jobexecutor.DispatcherThread.acquireJobs(DispatcherThread.java:126)
at org.jbpm.pvm.internal.jobexecutor.DispatcherThread.run(DispatcherThread.java:67)
I did not develop the console integration and lack the knowledge required to place the ProcessEngine.close() call properly. Any pointers in this direction would be very helpful.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/549378#549378]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 10 months
[JBoss Cache] - Jboss 1.2.4 Cache not replicated...
by rajsoni
rajsoni [http://community.jboss.org/people/rajsoni] created the discussion
"Jboss 1.2.4 Cache not replicated..."
To view the discussion, visit: http://community.jboss.org/message/549375#549375
--------------------------------------------------------------
Hi,
Am trying to use JbossCache with java 1.4.2_13.That's the java version our application is currently using so based on the compatibility matrix specified in the link below,we tried using the Jboss cache 1.2.4 SP2 version:
JDK compatibility:
http://community.jboss.org/wiki/jbosscache http://community.jboss.org/wiki/jbosscache
I need to be able to run the cache as standalone Java programs and any other node that joins the cluster should be able to read the data put in the cache by any node.I had got that working with the latest version of Jboss cache.However with 1.2.4 version I see that the node2 is not able to get the data put in the cache by node1.
Would really appreciate any help for this.From the logs I see that the clustering is working fine and node2 joins the cluster first created just with node1.The message communication is happening between the nodes as well
Here's how my replicationconfig xml file and the code for the nodes looks like:
<?xml version="1.0" encoding="UTF-8"?>
<!-- ===================================================================== -->
<!-- -->
<!-- Sample TreeCache Service Configuration -->
<!-- -->
<!-- ===================================================================== -->
<server>
<classpath codebase="./lib" archives="jboss-cache.jar, jgroups.jar"/>
<!-- ==================================================================== -->
<!-- Defines TreeCache configuration -->
<!-- ==================================================================== -->
<mbean code="org.jboss.cache.TreeCache"
name="jboss.cache:service=TreeCache">
<depends>jboss:service=Naming</depends>
<depends>jboss:service=TransactionManager</depends>
<!--
Configure the TransactionManager
-->
<attribute name="TransactionManagerLookupClass">org.jboss.cache.DummyTransactionManagerLookup</attribute>
<!--<attribute name="TransactionManagerLookupClass">org.jboss.cache.GenericTransactionManagerLookup</attribute>-->
<!--
Isolation level : SERIALIZABLE
REPEATABLE_READ (default)
READ_COMMITTED
READ_UNCOMMITTED
NONE
-->
<!--<attribute name="IsolationLevel">REPEATABLE_READ</attribute>-->
<attribute name="IsolationLevel">NONE</attribute>
<!--
Valid modes are LOCAL, REPL_ASYNC and REPL_SYNC
-->
<attribute name="CacheMode">REPL_ASYNC</attribute>
<!--
Just used for async repl: use a replication queue
-->
<attribute name="UseReplQueue">false</attribute>
<!--
Replication interval for replication queue (in ms)
-->
<attribute name="ReplQueueInterval">0</attribute>
<!--
Max number of elements which trigger replication
-->
<attribute name="ReplQueueMaxElements">0</attribute>
<!-- Name of cluster. Needs to be the same for all clusters, in order
to find each other
-->
<attribute name="ClusterName">insurancecluster</attribute>
<!-- JGroups protocol stack properties. Can also be a URL,
e.g. file:/home/bela/default.xml
<attribute name="ClusterProperties"></attribute>
-->
<attribute name="ClusterConfig">
<config>
<!-- UDP: if you have a multihomed machine,
set the bind_addr attribute to the appropriate NIC IP address -->
<!-- UDP: On Windows machines, because of the media sense feature
being broken with multicast (even after disabling media sense)
set the loopback attribute to true -->
<UDP mcast_addr="228.1.2.3" mcast_port="48866"
ip_ttl="64" ip_mcast="true"
mcast_send_buf_size="150000" mcast_recv_buf_size="80000"
ucast_send_buf_size="150000" ucast_recv_buf_size="80000"
loopback="false"
bind_addr="10.9.10.164"/>
<PING timeout="10000" num_initial_members="3"
up_thread="false" down_thread="false"/>
<!--<PING -->
<!--timeout="10000" -->
<!--num_initial_members="3"-->
<!--up_thread="false" -->
<!--down_thread="false"-->
<!--/>-->
<MERGE2 min_interval="10000" max_interval="20000"/>
<!-- NOTE: this was commented off in the example config file -->
<!--<FD shun="true" up_thread="true" down_thread="true" />-->
<FD
shun="false"
up_thread="true"
down_thread="true"
/>
<FD_SOCK/>
<VERIFY_SUSPECT timeout="1500"
up_thread="false" down_thread="false"/>
<pbcast.NAKACK gc_lag="50" retransmit_timeout="600,1200,2400,4800"
max_xmit_size="8192" up_thread="false" down_thread="false"/>
<UNICAST timeout="600,1200,2400" window_size="100" min_threshold="10"
down_thread="false"/>
<pbcast.STABLE desired_avg_gossip="20000"
up_thread="false" down_thread="false"/>
<FRAG frag_size="8192"
down_thread="false" up_thread="false"/>
<!--<pbcast.GMS join_timeout="5000" join_retry_timeout="2000"-->
<!--shun="true" print_local_addr="true"/>-->
<pbcast.GMS
join_timeout="5000"
join_retry_timeout="2000"
shun="false"
print_local_addr="true"
disable_initial_coord="false"
/>
<pbcast.STATE_TRANSFER up_thread="true" down_thread="true"/>
</config>
</attribute>
<!--
Whether or not to fetch state on joining a cluster
'true' (default)
-->
<attribute name="FetchStateOnStartup">true</attribute>
<attribute name="FetchInMemoryState">true</attribute>
<attribute name="StateRetrievalTimeout">60000</attribute>
<!--
The max amount of time (in milliseconds) we wait until the
initial state (ie. the contents of the cache) are retrieved from
existing members in a clustered environment
-->
<attribute name="InitialStateRetrievalTimeout">5000</attribute>
<!--
Number of milliseconds to wait until all responses for a
synchronous call have been received.
-->
<attribute name="SyncReplTimeout">20000</attribute>
<!-- Max number of milliseconds to wait for a lock acquisition -->
<attribute name="LockAcquisitionTimeout">15000</attribute>
<!-- Name of the eviction policy class. -->
<attribute name="EvictionPolicyClass"></attribute>
<!--
Indicate whether to use marshalling or not. Set this to true if you are running under a scoped
class loader, e.g., inside an application server. Default is "false".
-->
<attribute name="UseMarshalling">false</attribute>
</mbean>
<!-- Uncomment to get a graphical view of the TreeCache MBean above -->
<!--<mbean code="org.jboss.cache.TreeCacheView" name="jboss.cache:service=TreeCacheView">-->
<!--<depends>jboss.cache:service=TreeCache</depends>-->
<!--<attribute name="CacheService">jboss.cache:service=TreeCache</attribute>-->
<!--</mbean>-->
</server>
Code Node1 :
Fqn insuranceFqn = Fqn.fromString("/com/themunicenter/insurance");
cache = new TreeCache();
PropertyConfigurator config = new PropertyConfigurator();
config.configure(cache, "/usr/local/tmc/replication-configuration.xml");
cache.createService();
cache.startService();
HashMap map = new HashMap();
map.put("abc", "ValueToBeShown");
cache.put(insuranceFqn, map);
Code Node 2:
cache = new TreeCache();
PropertyConfigurator config = new PropertyConfigurator();
config.configure(cache, "/usr/local/tmc/MuniCenter/properties/replication-configuration.xml");
cache.createService();
cache.startService();
Fqn insuranceFqn = Fqn.fromString("/com/themunicenter/insurance");
String testData = (String) cache.get(insuranceFqn,"abc");
System.out.println("THE CACHE NOW IS"+testData);
The cache shows as NULL when node2 code runs:
Log from Server is attached here(showing the communication is happening fine between the nodes):
I say server here,since the progams put and pick messages in Jboss cache based on inflow of a JMS message on weblogic JMS queue.
Will really appreciate any pointers...thanks for taking time to look into this issue!!
The last few lines in server log shows:
2010-06-23 14:12:56,207 - WARN (STATE_TRANSFER.java:283:[UpHandler (STATE_TRANSFER)]) - state received from 10.9.10.164:44127 is null, will return null state to application
2010-06-23 14:12:56,207 - INFO (TreeCache.java:2632:[main]) - *state could not be retrieved (must be first member in group)*
2010-06-23 14:12:56,207 - INFO (TreeCache.java:4010:[Thread-10]) - new cache is null (may be first member in cluster)
2010-06-23 14:12:56,207 - INFO (TreeCache.java:1281:[main]) - Cache is started!!
2010-06-23 14:12:56,208 - DEBUG (PessimisticLockInterceptor.java:217:[main]) - failed to find or create child com of node /
2010-06-23 14:12:56,208 - DEBUG (TreeCache.java:2716:[main]) - _get("/com/themunicenter/insurance", 010824FU9, "true")
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/549375#549375]
Start a new discussion in JBoss Cache at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 10 months