Hi all,
We use 3.1.4 in production for more than a year now. Overall we are satisfied.
The bottlenecks appears to be access to variables instance, something we do
plenty of when populating our jBPM driven SWING GUI. Add to that the fact that
our app puts put a fair amount of values in the jBPM
Hi salaboy21,
The process is virtually a hello world process with a single task. The
variables we store in the engine are mostly String values. So they are
cache-able.
The problem is that I don't see how to do that efficiently. It is the very
nature of BPM to be long lived. So the values
Hi,
What's your process definition? Is that task assigned to b not just a left
over from a previous/other process instance?
Because the answer to your question is otherwise YES :)
Best regards,
Johan
View the original post :
Hi all,
I ran into the following unpleasant surprise. I basically wrapped jbpm 3.1.4 up
and put it into a session bean (EJB2.x). As the number of tasks grew we
discovered that access to process variables became sluggish.
To keep a long story short profiling revealed that the same code when
Hi all,
I run into a performance problem here. My app creates an inbox-like task list.
To populate that list with relevant information I retrieve the process
variables assoc'd with each of the tasks. Unfortunately this lookup takes
around 40ms per task (cummulated time of all the required
Ah ok I see. Well I saw I complicated things anyway. There seems to be a
findActiveNodesByProcessInstance() in the GraphSession
So combining that with
getGraphSession().findProcessInstances(processDefinitionId), which returns you
a list of processes, you could get the list you are looking for.
Hi,
I don't know if that's the best way to do this but here is how I did it (just
last week in fact).
NOTE: I did this for jbpm3.1 but things may not have changed that much for 3.2.
You need to do 2 things:
1) make your own DbPersistenceServiceFactory
2) patch your jbpm.cfg.xml
Some snippets
Hi,
You can get the root token for your process. From there you can find out in
which node(s) it resides.
A bit like below (this collects all the active nodes) but then again you'll
need to do some instanceof work to see what type of node you actually got.
| ...
|
Hi Fabien;
My answer solution for 3.1.x it using the create-timer event (if this event
still exists in 3.2 you're in business).
Regards,
Johan
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4094058#4094058
Reply to the post :
If I understand it well from the stack trace you associated an action with a
transition (correct?). Something goes wrong in your action handler. Did you
debug that?
Regards,
Johan
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4083391#4083391
Reply to the
Look at process variables. If the classes are mapped with hibernate or they are
serializable then you should not have too much trouble. See chapter 10 of the
doc.
Regards,
Johan
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4064856#4064856
Reply to the post
Sorry for the late reply.
anonymous wrote : The log message certainly doesn't jump out and bite you!
anonymous wrote : Does it stand out if the queries are not displayed fully?
The output I pasted in this thread is that with DEBUG set for
log4j.logger.org.jbpm . So it is definitely
anonymous wrote : Hypersonic can work in multiple modes. TCP Server,
Standalone, InMemory.
| As far as I know the InMemory mode stores all your data in memory and
| flushes them to the disk when you shutdown the server. (not 100% sure)
The in-memory-db is a volatile db. Once closed it
Ok, I found it. A stupid mistake for a change. I should have seen the
| select exceptionh0_.PROCESSDEFINITION_ as PROCESSD5_1_, except
| ionh0_.ID_ as ID1_1_, exceptionh0_.GRAPHELEMENTINDEX_ as GRAPHELE6_1_,
exceptionh0_.ID_ as ID1_7_0_,
| exceptionh0_.EXCEPTIONCLASSNAME_ as
Hi all,
I'm in desperate need for some pointers. I try to introduce jbpm (3.1.4) into
an existing EJB2.X app. The jbpm code is wrapped in the thoroughly tested
session bean, works. When the 2 are put together things collide. Monitoring of
the db queries indicates that the business logic and
I'm no expert but in
src\java.jbpm.test\org\jbpm\context\exe\VariableQueryDbTest.java
there is an example of a query to another type of value. Granted it does not
use org.jbpm.context.exe.VariableInstance but
org.jbpm.context.exe.variableinstance.XXX directly which is probably not what
you
Thanks for the reaction guys!
The queries contain some sensitive/personal data and I just don't want my head
chopped off by my boss :-P
Well I can post an edited (and somewhat shorter version of the output). It
contains JBPM log info but also the queries, I don't think it is confusing. The
There is only one thread, that's just the next loop in the test. The
setRollBackOnly() idea is worth checking out, I'll do that. Thanks
Johan
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4064054#4064054
Reply to the post :
Hi,
Actually it is indirectly through the hibernate.cfg.xml that jbpm is hardwired
to the identity module.
| !-- following mapping files have a dependendy on --
| !-- 'jbpm-identity-{version}.jar', mapping files --
| !-- of the pluggable jbpm identity component. --
|
Hi all,
For testing purposes I'd like the easily switch the jBPM configuration
programmatically. I know I could replace the jbpm.cfg.xml by hand but that's
not so practical (think unittests...). I would have liked to override the
jbpm.cfg.xml default by setting a system property. Due to my
The classes are not deployed on the database as such. The proces definition is
stored in the db. This includes the definition of each and every node, action,
assignment and all the other definitions in a process. Note that all these
element are always bound to one proces definition. No reuse
You got a good point there Ronald. Now that I think of it, I just complicated
things.
Johan
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4042920#4042920
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4042920
@pedwards: why do you get hostile? I read you post. My post merely confirmed
what you were expecting by sketching howwhere it is in the code. I'm certainly
not looking for trouble but it's a very strange way of reacting to the input of
other people. I just wanted to help.
Best regards,
Johan
I'm by no means an expert but I had to set hibernate.transaction.factory_class
to org.hibernate.transaction.CMTTransactionFactory
for my weblogic 8.1 to work. Well, someone did it for me but it works for me ;)
Better info here http://www.hibernate.org/42.html
Johan
View the original post :
Hi Ricardo,
The execution method of the ActionHandler interface has an ExecutionContext
parameter. You can use that to pass values to your action handler using process
variables. Think of as a per process blackboard ;)
You can define process-wide actions as well as actions bound to exceptions,
Hi,
Make sure that the directories (not the files themselves) containing
jbpm.cfg.xml and simple/processdefinition.xml are in your classpath.
Hope this solves it.
Regards,
Johan
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4024994#4024994
Reply to the
I found the 'why of the stack trace mentioned in the previous post. A lost
e.printStackTrace in the close() methode in org.jbpm.svc.Service at line 213
(for jbpm-3.1.4).
Johan
ps: does this need an entry in JIRA?
View the original post :
In the meanwhile I had a chance to try the code too. It works but does not
solve the problem :(
So I resumed my quest and found the real source of the many SAXParserFactory
instantiations: JbpmContext.getSession (see below).
Hmmm, I see a solution in caching the configuration in the
@Ronald:
How do I go about submitting my patch? Or will this all becoming clear when
I'll open the issues in JIRA?
Regards,
Johan
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4024246#4024246
Reply to the post :
Ok, it's done
http://jira.jboss.com/jira/browse/JBPM-858
I don't know how to make a build so I could not test the code but it should do
the job.
Johan
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4024279#4024279
Reply to the post :
Stupid question, but is classpath ok? I mean this just a class not found...
Regards,
Johan
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4021192#4021192
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4021192
I had the problem listed below. Turns out is was a classpath issue. In my case
there was some interference in lookup of the JpdlEntityResolver and the
EntityResolver setup provided by my Weblogic.jar.
Maybe this solves the problem for you. If not crank up your log4j.properties to
DEBUG and see
I had the problem listed below. Turns out is was a classpath issue. In my case
there was some interference in lookup of the JpdlEntityResolver and the
EntityResolver setup provided by my Weblogic.jar.
Maybe this solves the problem for you. If not crank up your log4j.properties to
DEBUG and see
Twice 'yes' and once 'no'.
Yes, I can see that too that it is default behaviour of the xerces lib (not
really the JVM as you said).
Yes, it is not jBPM code that causes this. Not directly at least.
But also no, because in the end it is jBPM code that (albeit indirectly) causes
these stat()
Maybe you'll find what you need in :
jbpm-3.1.2\src\java.jbpm\org\jbpm\taskmgmt\def\
There are a few controllors in that example.
Best regards,
Johan
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4018917#4018917
Reply to the post :
In the meanwhile I've implemented this approach. And it solves the problem.
But I can't catch the exception very early on. So my process produces ugly
stack traces upon unsuccesful commits.
I'm not sure whether replace the DbPersistenceService(Factory) (through the
service definition in the
Me again...
Hmmm, is my question so stupid? If so, I gladly settle for a look at thread nr
XXX ... type of reply :) Just shoot
How are other people handling this then? With carefully crafted assignment
handlers?
As you can see I'm desperately in need of some jBPM wisdom here ;)
Best
I know the topic has been discussed frequently in this forum but I can't find
the answer I'm looking for.
My question is: How to handle the concurrent access to a task assigned to an
actor pool?
findPoolTaskInstance(actorId) will return all the tasks assigned to any pool
the actor is a member
@estaub : good idea!
It's done: http://jira.jboss.com/jira/browse/JBPM-827
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4005760#4005760
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4005760
Is there no jBPM guru even remotely interested in this problem?
Let me reminder you of the facts:
- take the Websale demo
- wrap it in a for loop
- see how your machine grinds to halt after 4000 iterations
If this is not the result of my stupidity (always possible, then please tell me
what I
Processes have not yet finished (i.e. in the end state) as defined in your
process definition.
If you have some tasks (likely ;) ) then take a look at the JBPM_TASKINSTANCE
table to see where the processes got in their execution.
Regards,
Johan
View the original post :
No progress with this problem! I ran the Websale example with more success so I
guess the problem resides in the way I have defined the identities or the
assignment(s) then. After all the hibernate code that eat up all the time
relates exactly to this.
| identity
| !-- 2 doctors --
|
Hi all,
As a test I have wrapped up the Websale demo code in a loop. In the loop a
process is instantiated (one at a time) and the different tasks are handled
(See fullCycle() in code below).
Initially one iteration takes 0.2 secs (not too fast...) but performance drops
after a while.
After
Hi Koen,
Many thanks for your answer!
You're are right of course, below the relevant code and definition.
I've run into the exact same problem using a HSQLDB as well as a Sybase backend.
The process definition is (IMHO) simple:
| ?xml version=1.0 encoding=UTF-8?
|
| process-definition
Koen,
The method was initially in a loop, but since it is supposed to handle all the
instances it only called once in my test program.
I initialize the jbpmcConfiguration like this:
| static JbpmConfiguration jbpmConfiguration =
JbpmConfiguration.getInstance();
|
I'll follow your
Hi all,
I'm evaluating jBPM(3.1.x) and therefore making simple test programs. To my
surprise the profiler showed that the TaskInstance.end() method consumes 90+%
of the time. In turn the time this spent in this method breaks down in:
- Hibernate.IdentitySession.getUserByName() 46%
-
46 matches
Mail list logo
