"kukeltje" wrote : so the 1 second is not to bad imo (jms could do this
automatically for you with the retry-timeout)
| ...
I hope you jocking! ;) I am not agree to loose 99% of performance by getting
only 1 command-exec instead of my current 100. 1 sec -solution is only solution
for Simp
this occurs with me when I have async on the fork...
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058679#4058679
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058679
___
j
with 3.2.1 :
anonymous wrote : 11:19:01,985 [pool-1-thread-1] DEBUG GraphElement - event
'node-leave' on 'Node(fileCheck)' for 'Token(/)'
| 11:19:02,003 [pool-1-thread-1] DEBUG GraphElement - event 'transition' on
'Transition(check-to-fork)' for 'Token(/)'
| 11:19:02,006 [pool-1-thread-1] DEB
"ax666" wrote : Ronald, you're absolutely right, but there's nothing I can do
now.
| Our hacks are not of a quality for a patch. I can quickly describe what we
did:
| - new job executor who is starting 1 job reader thread
| - job reader thread uses java executor service for thread pool
|
Ronald, you're absolutely right, but there's nothing I can do now.
Our hacks are not of a quality for a patch. I can quickly describe what we did:
- new job executor who is starting 1 job reader thread
- job reader thread uses java executor service for thread pool
- reads jobs from db and starts ne
Alex,
There are 3 ways to get this fixed quickly:
- Develop a good patch and contribute it
- Get many people to vote for the issue
- Buy commercial support and report it as a major issue.
There are currently to few people having a problem with this to get it 'fixed'
by the core developers workin
thanks ed for working on this problem. I'd like to see some of the developers
to work on this too to have it fixed in a public version. we did some bad hacks
similar to ed's to get this to work, but still, I believe its not production
ready.
right now I don't have any more time to work on this,
See (lengthy) update on http://jira.jboss.com/jira/browse/JBPM-983
-Ed Staub
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058347#4058347
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058347
I attached a new version of the test case to the jira issue. It's not working
despite the changes.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4056869#4056869
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4056869
___
no, correct, no subprocesses. I used the xml example in this topic
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4056516#4056516
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4056516
ronald, the polling is only in the testcase. I added it because sometimes
workflow simply did not finish. I will try the other stuff later and give a
report.
What I see now you're not using subprocesses.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4056504#4
Alex,
I did some tests and I have varying results. Varying in the sense that the same
test run multiple times sometimes pass and sometimes don't.
This is what I used for the jobexecuterconfig
|
|
|
|
|
|
|
|
|
|
My proc
same ones? if so, can you post a stacktrace? In the meantime I'll try to get
the case running
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4056396#4056396
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4056396
A quick test with both the join and fork set to async=false gave me ERRORS too.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4056386#4056386
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4056386
___
If you expect the fork to behave as a multi-threaded parallel execution, then
sorry.. that is not what jBPM is/does. If you want that, make the nodes in each
leg of a fork async, but not the fork itself.
According to the code, async on a node locks the currenttoken. Not strange then
that in th
Alex,
Building these kinds of 'does-this-file-exist' checks is not something we
promote in doing with jBPM timers. The better solution is to have an ESB like
solution, which often has really good file polling. This can then signal the
tokens.
You are correct in the assumption that JMS would n
Ronald is a late night worker ;) ok I read your post yesterday already but was
too tired to answer
The test case attached with the JIRA issue is very simple. Token concurrency
occurs when both enter the join node. I did not use any timers in this simple
test, though we have timers in the re
"fady.matar" wrote : If JMS like functionality is required consider using Mule.
| I hope this solves your problem
Or use JBoss AS (has JMS) or JBoss ESB ;-)
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4056240#4056240
Reply to the post :
http://www.jboss.
ok, I partly mixed 2 things up but... nevertheless, the one/multiple
threads thing of the jobexecutor was never explicitly meant to work (nor was it
not meant to work) and no, I was not saying there should be one mdb but maybe
the behaviour when jms is involved is different and why is it
Ronald,
Re JMS... can you explain how you think it will solve these problems? If you
mean that there would be only one bean in the pool, that's not solving it at
all - that's single-threading all requests.
As I see it, the problem looks like one of token synchronization, and I don't
see anyth
If JMS like functionality is required consider using Mule.
I hope this solves your problem
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4056133#4056133
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4056133
ok.. I think Tom will be reluctant to 'fix' this since (and I have to check
this) he did not want to build a new highly scalable async system where there
is JMS.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4056128#4056128
Reply to the post :
http://www.j
Ronald, we're running the war in Tomcat without Jms. Behavior is the same with
or without scripting.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4056096#4056096
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4056096
Now I come to think of it I/we overlooked something.
AFAIR, the async mechanism in the WAR version of jBPM was for simple
environments. For enterprise grade solutions, a switch should be made to JMS.
More than one MDB can be deployed there which can process the async actions.
(not scripted
The reason I asked for a scriptless version is that I'm not the scripted
version can run async very wel.. I assume the non-scripted version shows the
same (for you unwanted) behaviour?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4056034#4056034
Reply to t
I fulfilled Ronalds request and added a version of the test case that uses an
action handler. Our project state is, that jBPM allows only single thread
execution which isn't something we can live with, but I don't have the time to
investigate further. And yes, this should be fixed, right now I'm
Alex,
Apart from Ronald's request for scriptlessness, it doesn't look like anyone's
dug into your http://jira.jboss.com/jira/browse/JBPM-983. Do you still need a
fix? If so, I'll try to go after it in the next few days.
-Ed Staub
View the original post :
http://www.jboss.com/index.html?modu
ed, thanks for pointing htat out, I added the missing interface, the unit test
should not depend on anything now... alex
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4053162#4053162
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mo
Alex,
I took a quick look at the unit test. It uses a JbpmContextCallback class that
I don't recognize, or see an import for. Do you need to attach it?
I didn't look rigorously for other missing bits; you might want to.
-Ed Staub
View the original post :
http://www.jboss.com/index.html?modu
http://jira.jboss.com/jira/browse/JBPM-983
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4053103#4053103
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4053103
___
jboss-user m
executionContext.leaveNode(); in a startnode on an event? Does that work
correctly?
and the same in async nodes? hm... looks a bit strange to me What if
you use java classes for leaving these nodes. Same errors then?
View the original post :
http://www.jboss.com/index.html?module=bb&op
Could someone please confirm that this simple process doesn't work with more
than 1 JobExecutor thread configured?
|
|
|
| start of the process
|
|
| System.out.println("START");
|
I can't provide anything useful to go on with, in every run something different
doesn't work. Sometimes a subprocess is not executed any more, sometimes
variables are lost or an action handler's executionContext doesn't have a
contextInstance (executionContext.getContextInstance() returns null).
Alex,
That's not much to go on...
-Ed Staub
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051800#4051800
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051800
___
jboss-use
Ok, next one.
Looks like there's a problem with storing and signalling jobs. The last thing I
see in the logs is
| 16:26:55,267 JbpmJobExector:192.168.x.x:2 DEBUG DbMessageService - messages
were produced the jobExecutor will be signalled
|
after that no more jobs are executed though there
I reworked my processes and avoid timers now at all. The waiting and timing out
is done in the ActionHandlers now. Let's see what the next problem is.
The jBPM guys should write a simple process definition to test with, just async
join/fork with nodes using timers, all with multiple JobExecutor
Alex,
Maybe in Timer.Timer(token) and Timer.Timer() you could try calling
setExclusive().
Once again, both thanks and condolences for being a pioneer in this area!
-Ed Staub
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051715#4051715
Reply to the post :
37 matches
Mail list logo
