[jBPM] - jBPM persistent session ids
by Jason Jho
Jason Jho [https://community.jboss.org/people/jasonjho] created the discussion
"jBPM persistent session ids"
To view the discussion, visit: https://community.jboss.org/message/730695#730695
--------------------------------------------------------------
I am using jBPM 5.2.0 and I have a question about ksession ids. My understanding is that this session ID is used to reload a persisted session, but there is no clear indication how this is supposed to work when a server is restarted. For example, if I have a session ID [1] for a workflow process that is persisted and the server goes down, I can reload the session back to it's previous state using this same ID. However, how am I guaranteed that any new session ID created by the same knowledge base will be uniquely different from the persisted ID?
Ex:
int id = ksession.getId() ...
startProcess(...)
// server shuts down - restarts
int savedId = geSavedId();
session = JPAKnowledgeService.+loadStatefulKnowledgeSession+(savedId, kbase, *null*, env);
newSession = kbase.newStatelessKnowledgeSession(...)
newSession.getId() = ???
In the above scenario, could it be possible for newSession.getId() to have the same integer value as the previously saved ID?
If so, how would one be able to distinguish the 2 different sessions?
Thanks for any help.
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/730695#730695]
Start a new discussion in jBPM at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
14 years
[JBoss Remoting] - Re: WorkerThread exception occured .... InvocationTargetException / SocketTimeoutException
by Ron Sigal
Ron Sigal [https://community.jboss.org/people/ron_sigal] created the discussion
"Re: WorkerThread exception occured .... InvocationTargetException / SocketTimeoutException"
To view the discussion, visit: https://community.jboss.org/message/724880#724880
--------------------------------------------------------------
Hi Werner,
re: "For example with netstat I can see, that *2437* is a used port. I am wondering that I could recognize that this port is used by my testprogram istself"
It really wouldn't do any good. When you make a call on an EJB, it filters down to Remoting, which, if it can't find a pooled connection to reuse, will create a new socket, leading to ServerSocket.accept() returning a socket on the server.
It seems like something is preventing the client from completing the initialization of the connection, but I can't imagine what it is. You could use Wireshark to monitor what bytes, if any, get sent from the client to the server.
-Ron
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/724880#724880]
Start a new discussion in JBoss Remoting at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
14 years
[jBPM] - jBPM and OSGi integration
by annah
annah [https://community.jboss.org/people/annah] created the discussion
"jBPM and OSGi integration"
To view the discussion, visit: https://community.jboss.org/message/733337#733337
--------------------------------------------------------------
Hi!
I'm trying to run jBPM and Drools inside an OSGi container on Websphere app server. I have my own bundle which should use services provided by Drools and jBPM bundles.
I'm using Drools OSGi bundles downloaded from official site ( http://www.jboss.org/drools/downloads http://www.jboss.org/drools/downloads), however two of the jBPM bundles don't get activated: +org.jbpm.flow.builder+ and +org.jbpm.bpmn2.+
This is the output I get at the console showing that all drools and jbpm activators get started except for flow.builder and bpmn2 :
[02.05.12. 13:14:46:500 CEST] 00000027 SystemOut O registering compiler services
[02.05.12. 13:14:46:505 CEST] 00000027 SystemOut O compiler services registered
[02.05.12. 13:14:46:514 CEST] 00000027 SystemOut O registering api services
[02.05.12. 13:14:46:516 CEST] 00000027 SystemOut O registering api : org.drools.builder.impl.KnowledgeBuilderFactoryServiceImpl@40d31bc : interface org.drools.builder.KnowledgeBuilderFactoryService
[02.05.12. 13:14:46:516 CEST] 00000027 SystemOut O api drools services registered
[02.05.12. 13:14:46:518 CEST] 00000027 SystemOut O registering core services
[02.05.12. 13:14:46:519 CEST] 00000027 SystemOut O registering api : org.drools.io.impl.ResourceFactoryServiceImpl@411ebed : interface org.drools.io.ResourceFactoryService
[02.05.12. 13:14:46:521 CEST] 00000027 SystemOut O registering api : org.drools.impl.KnowledgeBaseFactoryServiceImpl@4120ed2 : interface org.drools.KnowledgeBaseFactoryService
[02.05.12. 13:14:46:522 CEST] 00000027 SystemOut O registering api : org.drools.marshalling.impl.MarshallerProviderImpl@41228ea : interface org.drools.marshalling.MarshallerProvider
[02.05.12. 13:14:46:522 CEST] 00000027 SystemOut O registering api : org.drools.marshalling.impl.MarshallerProviderImpl@41228ea : interface org.drools.marshalling.MarshallerProvider
[02.05.12. 13:14:46:522 CEST] 00000027 SystemOut O core services registered
[02.05.12. 13:14:46:531 CEST] 00000027 SystemOut O registering flow core services
[02.05.12. 13:14:46:532 CEST] 00000027 SystemOut O registering api : org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl@41408f9 : interface org.drools.runtime.process.ProcessRuntimeFactoryService
[02.05.12. 13:14:46:532 CEST] 00000027 SystemOut O registering compiler : org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl@41408f9 : interface org.drools.runtime.process.ProcessRuntimeFactoryService
[02.05.12. 13:14:46:533 CEST] 00000027 SystemOut O registering api : org.jbpm.marshalling.impl.ProcessMarshallerFactoryServiceImpl@4143d84 : interface org.drools.marshalling.impl.ProcessMarshallerFactoryService
[02.05.12. 13:14:46:533 CEST] 00000027 SystemOut O flow core services registered
.....
Has someone managed to get jbpm running inside OSGi?
Am I missing something, are there any other dependencies? These are bundles I added to my OSGi container:
com.springsource.antlr 2.7.6
com.springsource.com.sun.msv.datatype 0.0.0.20060615
com.springsource.com.sun.tools.xjc 2.1.7
com.springsource.com.sun.xml.bind 2.1.7
com.springsource.com.sun.xml.bind.jaxb1 2.1.7
com.springsource.com.sun.xml.fastinfoset 1.2.2
com.springsource.com.thoughtworks.xstream 1.3.1
com.springsource.javax.activation 1.1.1
com.springsource.javax.xml.bind 2.1.7
com.springsource.javax.xml.stream 1.0.1
com.springsource.org.antlr.runtime 3.1.3
com.springsource.org.apache.xerces 2.9.1
com.springsource.org.apache.xml.resolver 1.2.0
com.springsource.org.apache.xmlcommons 1.3.4
com.springsource.org.dom4j 1.6.1
com.springsource.org.jvnet.staxex 1.0.0
com.springsource.org.relaxng.datatype 1.0.0
com.springsource.org.xmlpull 1.1.4.c
org.drools.api 5.3.0.Final
org.drools.compiler 5.3.0.Final
org.drools.core 5.3.0.Final
org.drools.decisiontables 5.3.0.Final
org.jbpm.bpmn2 5.1.2.Final
org.jbpm.flow.core 5.1.2.Final
org.jbpm.flow.builder 5.1.2.Final
org.mvel2 2.1.0.drools4
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/733337#733337]
Start a new discussion in jBPM at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
14 years
[jBPM] - AS 7.1.2, JBPM 5.3 persistence : Getting Large Objects may not be used in auto-commit mode exception
by Vimal Kansal
Vimal Kansal [https://community.jboss.org/people/vimalkansal] created the discussion
"AS 7.1.2, JBPM 5.3 persistence : Getting Large Objects may not be used in auto-commit mode exception"
To view the discussion, visit: https://community.jboss.org/message/738264#738264
--------------------------------------------------------------
Hi,
I am using jBPM 5.3 as embedded engine in JEE6 web application and have configured the persistence. The application deploys and I can see jbpm tables getting created in the database. My sample code for executing the workflow is :
//@Stateless
@Named("workFlow")
public class WorkflowManager {
@Inject @Knowledge //@Knowledge is the user defined CDI qualifier.
private KnowledgeBase kbase;
@Inject
@JBPMPeristenceFactory // my own CDI Qualifier, for typesafe Injection of EntityManagerFactory
private EntityManagerFactory emf;
public void startWorkFlow(){
try {
TransactionManager tm = null;
tm = (TransactionManager)new InitialContext().lookup( "java:jboss/TransactionManager" ); //lookup the transaction manager
Environment env = KnowledgeBaseFactory.newEnvironment();
env.set( EnvironmentName.ENTITY_MANAGER_FACTORY,emf); //set the entity manager factory
env.set( EnvironmentName.TRANSACTION_MANAGER, tm); //set the transaction manager
ksession.startProcess("demo.jbpmDemo");
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
When the startWorkFlow method is invoked, I get the following exception :
I am not sure why it is being executed in auto commit mode. Also I am not sure whether it is PostGreSQL issue. Can somebody please help.
=============================================================================================
... 70 more
Caused by: javax.persistence.PersistenceException: org.hibernate.exception.GenericJDBCException: Large Objects may not be used in auto-commit mode.
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1365) [hibernate-entitymanager-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1293) [hibernate-entitymanager-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1299) [hibernate-entitymanager-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.ejb.AbstractEntityManagerImpl$CallbackExceptionMapperImpl.mapManagedFlushFailure(AbstractEntityManagerImpl.java:1485) [hibernate-entitymanager-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:109) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:164)
at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165)
... 73 more
Caused by: org.hibernate.exception.GenericJDBCException: Large Objects may not be used in auto-commit mode.
at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:54) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:125) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:110) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.engine.jdbc.internal.proxy.AbstractStatementProxyHandler.continueInvocation(AbstractStatementProxyHandler.java:129) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.engine.jdbc.internal.proxy.AbstractProxyHandler.invoke(AbstractProxyHandler.java:81) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at $Proxy67.setBlob(Unknown Source) at org.hibernate.type.descriptor.sql.BlobTypeDescriptor$3$1.doBind(BlobTypeDescriptor.java:91) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.type.descriptor.sql.BasicBinder.bind(BasicBinder.java:92) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.type.AbstractStandardBasicType.nullSafeSet(AbstractStandardBasicType.java:305) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.type.AbstractStandardBasicType.nullSafeSet(AbstractStandardBasicType.java:300) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.type.AbstractSingleColumnStandardBasicType.nullSafeSet(AbstractSingleColumnStandardBasicType.java:57) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.persister.entity.AbstractEntityPersister.dehydrate(AbstractEntityPersister.java:2598) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2852) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3296) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:88) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:362) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:354) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:275) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:326) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1181) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:379) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:104) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
... 79 more
Caused by: org.postgresql.util.PSQLException: Large Objects may not be used in auto-commit mode.
at org.postgresql.largeobject.LargeObjectManager.createLO(LargeObjectManager.java:241)
at org.postgresql.largeobject.LargeObjectManager.createLO(LargeObjectManager.java:228)
at org.postgresql.jdbc2.AbstractJdbc2Statement.setBlob(AbstractJdbc2Statement.java:2901)
at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.setBlob(WrappedPreparedStatement.java:1073)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_31]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_31]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_31]
at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_31]
at org.hibernate.engine.jdbc.internal.proxy.AbstractStatementProxyHandler.continueInvocation(AbstractStatementProxyHandler.java:122) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
... 98 more
===================================================================================================================================================
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/738264#738264]
Start a new discussion in jBPM at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
14 years, 1 month
