Sorry, just a very quick answer (since I get my pile of work done and start
vacations next week :-)):
If you have actions which cannot be rolled back you should think about
introducing transaction boundaries (async=true in jbpm) correctly.
For the logging I basically extended the DbLoggingServ
anonymous wrote : We can't say that in this case the code has never happened,
Correct... It is an example where using non transactional external services
fails... so either send an additional mail from a node that you go to when the
'error' happens or whatever... business processes should take
Also in my opinion is correct to rollback process logs but what if in one of
the rolled back nodes jbpm sends an email to an operator or a customer or, in
general, triggers some operation in external systems?
We can't say that in this case the code has never happened,
in other words,
code has
What we did in a project is to exchange the LoggingService and to catch
Exceptions in the environment. As soon a exception is thrown (causing the
correct rollback) we send an event in a own transaction containing the log data
to some special service handling this (via ESB in this case, meaning J
Sure, on one hand it is overhead, but on the other hand you can scale better.
- Your real front-end worker threads return quicker (the delay to write a small
log entry to the jms queue is way lower than writing it to the db directly)
- So the number of threads simultaneously used will be lower (a
Hi,
anonymous wrote : most crashes we had were due to disk crashes
That´s an interesting piont - I did not thougth about it that way...
anonymous wrote : So logging async (JMS)
How much logging did you wrote asynchronously? I heard about such suggestions
earlier but personally I always thoug
does the gwt-console run under tomcat 5.5?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4207823#4207823
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4207823
___
jboss-user m
no, it is still not finished, but improved a lot in 3.3.1
1) is being taken care of in 4.0... logging is changing and will be
configurable as well. The thing is that 'governance' sometimes requires a lot
of info... so it is a tradeoff...
2) as said before... if there is a technical error by wh
Do you refer to the new GWT Console? - I tested it in 3.3.0 and it was not
really finished by then
Logging:
I would like to solve two issues - 1) the log service is just to slow - its the
main perfomance bottleneck of the enigne - 2) Is unsafe becuase it does not log
when something goes wro
The new console will display more about the logging and also have some general
reporting available, I suggest to take a look at it. It is in 3.3.1 already.
Regarding the not writing of errors... that is a indeed the case, but since the
cause of these rollbacks are (or should be) mostly technical
We had the same issue. We are currently building our own interface for that.
When it comes to logging and history it gets even more tricky - espacially in
cases something wrong happens:
My assumptions:
1) The process history is really not interesting when the process completed
without problems.
thank you for this information.
leads to another question related to log retrieval:
is there a tool out there that displays the process history (ie. path token has
taken) for a process instance? i can't find such thing in jbpm-console (3.2.3).
i know it would not be hard to code that but would b
We are currentlcy also playing around with huge data sizes.
The main performance bottleneck in jBPM is the database logging service and the
sive of the the logs table. Executing our test process with something about 150
nodes in 10 subprocesses the engine takes about 15seconds to execute it wit
10.000 jobs due each day. That is 10.000/(3.600*8) is 1 job per 3 seconds on
average. I do not see why that should not be possible.
The performance impact is related to the number of jobs that will end in that
period. If the 10.000 jobs end all at once, yes, that has an impact. otherwise
I thin
thank you for your answer.
a more detailed question:
what if i have 1.000.000 timers (jobs) with 10.000 jobs due each day? can the
jobexecutor handle that? is there a notable performance impact when it queries
the jobs-table?
hans
View the original post :
http://www.jboss.com/index.html?mod
it can run as many as your db can store
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203086#4203086
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203086
___
jboss-user mail
16 matches
Mail list logo
