[
http://jira.jboss.com/jira/browse/BPEL-282?page=all ]
Alejandro Guizar resolved BPEL-282.
-----------------------------------
Resolution: Done
Committed new binaries. They are available from:
http://repository.jboss.com/jbpm/bpel/1.1.0.GA/lib/
Be aware that, due to the amount of changes introduced to achieve the goal of one-click
deployment (BPEL-216), ant build files from previous versions will not work with the new
binaries. Please obtain updated versions from CVS:
http://fisheye.jboss.com/browse/JBPM/jbpm.3/bpel/examples/common
The new deployment model no longer requires the web service deployment artifacts to be
provided by the client. They are generated by the server upon deploying the process
definition through the "deployprocess" ant task.
Partner services no longer need to be statically referenced in bpel-deployment.xml
(formerly bpel-application.xml). They can be dynamically registered in the central catalog
using the "registerpartner" ant task.
Check out the new web console by pointing your browser to
http://localhost:8080/jbpm-bpel
after you deploy the jBPM BPEL service.
Engine runs process instances in serie instead of in parallel
-------------------------------------------------------------
Key: BPEL-282
URL:
http://jira.jboss.com/jira/browse/BPEL-282
Project: JBoss jBPM BPEL
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: Engine
Affects Versions: jBPM BPEL 1.1 beta 3
Environment: RHEL
Reporter: Santiago Erquicia
Assigned To: Alejandro Guizar
Fix For: jBPM BPEL 1.1 GA
We are stress testing a BPEL process and we found out that the engine runs all the
requests it receives in serie. That means that if there are two or more concurrent users
of the system, one has to wait till the first process instance stops at some point (wait
state) so the other request can be processed.
On our test environment, we are calling a web service which is also calling another web
service. The are connection problems with the second one, so from time to time the web
service just times out. This means that a concurrent user has to wait for that time out,
and whatever is left of that process instance, in order to be processed.
On our JMeter test, the throughput keeps stable even if there number of request is bigger
than the throughput of the BPEL engine. The result is that the time for response of each
process request increases indefinitely if the usage is bigger than the throughput. This
obviously doesn't scale at all for the processing requirement we are considering.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira