At revision: 1635567, I have put back the service call since it did not make any differences with the direct method call. Using the same load test I
got no timeout like before with the Minilang implementation
It must be run in the same transaction (else another thread might change the context) so your last proposition seems to be the right solution. I did
not implement it though since I did not need it.
Jacques
Le 30/10/2014 08:40, Scott Gray a écrit :
Or as an alternative it could be run in the same transaction right before
committing, to reduce the amount of time the lock is held.
Regards
Scott
On 30/10/2014, at 7:35 pm, Scott Gray <[email protected]> wrote:
I have serious doubts there's any significant performance problems with this
simple method. Given this problem occurred during load testing I would be
almost certain that the problem is lock contention on the ProductCalculatedInfo
records.
It's the same old story:
- Long running order creation transaction
- Updating a record that will be touched by many order creation transactions,
causing a lock on the record until the transaction is committed
- The transactions queue up, eventually they have to wait too long and the lock
wait timer runs out or the transaction timeout is hit
The service should be executed in separate transaction after the order
submission transaction is committed.
Regards
Scott
On 30/10/2014, at 7:23 pm, Adrian Crum <[email protected]>
wrote:
Thanks Jacopo.
I noticed the Mini-language service uses two deprecated elements:
https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+%28minilang%29+Reference
<calculate> should be replaced with <set> and <call-class-method> should be replaced
with <script>.
Perhaps if that service was updated performance would improve.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 10/30/2014 5:57 AM, Jacopo Cappellato wrote:
On Oct 29, 2014, at 8:24 PM, Jacques Le Roux <[email protected]>
wrote:
Apart what I reported in the commit comment and the Jira description, I did not
make other measures. Before it was blocking the JMeter test after it passed.
I suspect that the main difference could be Minilang vs Java, not between
service vs method call: this is why I think it would be interesting to test the
latter (java service vs java method).
We should not switch to direct Java method calls so lightly, at least not
before trying our best to find the root causes (in the service call chain) of
the low performance.
This effort would (if we find the bottleneck in the service call and manage to
fix it) improve the whole system in one shot rather just fixing one service.
Even if the difference is Minilang vs Java, it may be interesting to try to
figure out what is the reason for it (I suspect it could be the larger number
of reflexion) and try to fix it.
I am willing to help you in these tasks but in the meantime I would change you
latest code to use a service call (to Java) rather than a direct method call,
mostly for consistency with the rest of the codebase.
Kind regards,
Jacopo
