[jBPM Users] - Re: deploy() takes an awefully LONG time
by kukeltje
"ajaygautam" wrote : "saraswati.santanu" wrote : Ajay,
| | I did not get the first part of your question
| |
| | anonymous wrote : shouldn't the query actually be performed at the database level !?!?
| |
| | The query will be performed at the db only.
| |
| | Do you mean a db procedure kind of thing? That will have other significant disadvantages. So that query there looks fine.
| |
| |
| |
|
| Well... what I meant was that instead of querying for everything, loading everything, then performing a find in java code, shouldn't jBPM be creating a query criteria with the call that goes to the database? I mean, whats the point of loading everything in memory, and searching through it... databases are designed for tasks like these...
|
|
It doesn't
List<ProcessDefinition> existingProcesses = repositorySession.createProcessDefinitionQuery()
| .processDefinitionName(processDefinitionName)
| .list();
|
only retrieves those processdefinitions with the same name.In most production environments that will only be a few....
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4270234#4270234
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4270234
15 years, 2 months
[jBPM Users] - Re: deploy() takes an awefully LONG time
by ajaygautam
"kukeltje" wrote : I do not get it either. jBPM retrieves all processdefinitions with the same name (how many can that be, just several I think) and loops over that.
|
| I again urge you to log additional things, you might e.g. have a problem with a reverse dns lookup why things take long...
|
| So I would not file a bug for this since it most likely will be marked invalid.
I can't seem to get my head around jbpm's logging. Do you have a log file I could use - that would generate the additional logs?
Here is what my log file looks like (DEBUG level, with NO class level filters):
| log4j.rootLogger=DEBUG, A1
|
| log4j.appender.A1=org.apache.log4j.ConsoleAppender
| log4j.appender.A1.layout=org.apache.log4j.PatternLayout
| log4j.appender.A1.layout.ConversionPattern=%d %-5p %C{1} %3x - %m%n
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4270232#4270232
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4270232
15 years, 2 months
[jBPM Users] - Re: deploy() takes an awefully LONG time
by ajaygautam
"saraswati.santanu" wrote : Ajay,
| I did not get the first part of your question
|
| anonymous wrote : shouldn't the query actually be performed at the database level !?!?
|
| The query will be performed at the db only.
|
| Do you mean a db procedure kind of thing? That will have other significant disadvantages. So that query there looks fine.
|
|
|
Well... what I meant was that instead of querying for everything, loading everything, then performing a find in java code, shouldn't jBPM be creating a query criteria with the call that goes to the database? I mean, whats the point of loading everything in memory, and searching through it... databases are designed for tasks like these...
"saraswati.santanu" wrote :
| About the second part, where the query seems to be fired in a loop - I think the goal should be to fire less number of queries. Though it appears that the queries are fired in a loop, but making query in that way actually will result in less number of queries (in fact no query to db most of the time). If you try to aggregate values and fire query then cache hit will not be possible most of the time.
I think is some misunderstanding here. I will code at the code again, and comment.
Thanks
Ajay
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4270231#4270231
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4270231
15 years, 2 months
[jBPM Users] - Re: task & timers
by jbosspnet
Thanks for the reply.
The java code that I have supplied is in effect incorrect: the classes are not abstract. My processes are a little more complex, so I had simplified before post in the forum to avoid a lot of code. But the concept of the check executed in a specific range time in a manual or in a automatic way is however my target.
I have followed your suggestion and from Jboss log I have seen that both timers are created by CreateTimerAction. The problem is the signal in the AutomaticCheckAction: this will fire an before-signal and a node-leave event on the task-node. The first is not handled but the second, due to end-task="true" attribute, will cause an task-end event, so the timer in the task will be removed.
So I have tried to change the process definition with end-task="false" (the default) to preserve both timers when the execution follows KO transition. (As you can guess, this transition goes into a node where I notify the KO status (with a log message or a mail) and the returns into the task-node "check".)
Now I obtain the following exception:
| org.jbpm.graph.def.DelegationException: org.jbpm.graph.def.GraphElement.raiseException(GraphElement.java:382)
| 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:597)
| at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:173)
| at org.jbpm.graph.def.ProcessDefinition_$$_javassist_184.raiseException(ProcessDefinition_$$_javassist_184.java)
| at org.jbpm.graph.def.GraphElement.raiseException(GraphElement.java:373)
| at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:276)
| at org.jbpm.graph.def.GraphElement.executeActions(GraphElement.java:215)
| at org.jbpm.graph.def.GraphElement.fireAndPropagateEvent(GraphElement.java:185)
| at org.jbpm.graph.def.GraphElement.fireEvent(GraphElement.java:169)
| at org.jbpm.graph.def.Node.leave(Node.java:381)
| at org.jbpm.graph.node.TaskNode.leave(TaskNode.java:209)
| 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:597)
| at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:173)
| at org.jbpm.graph.def.Node_$$_javassist_252.leave(Node_$$_javassist_252.java)
| at org.jbpm.graph.exe.Token.signal(Token.java:192)
| at org.jbpm.graph.exe.Token.signal(Token.java:155)
| 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:597)
| at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:173)
| at org.jbpm.graph.exe.Token_$$_javassist_186.signal(Token_$$_javassist_186.java)
|
in the AutomaticCheckAction at line
| token.signal(isOK ? "OK" : "KO");
|
This exception is also present int JBPM_JOB.EXCEPTION_ column.
I have notice that whan the execution leaves the task-node a CancelTimerAction will be invoked. This probably suggests that I never leave the node and the KO notification must be done in the task (in the AutomaticCheckAction). But this solution is valid only for the automatic check, not for the manual where I explicity click on a OK/KO form (and the notification can be done only in another node).
Any suggestions or any another approach?
Regards.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4270209#4270209
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4270209
15 years, 2 months