Hi guys,
removing synchronized from begin( int timeout) will cause issues.
The problematic code is the following:
(starting from line 180 in TransactionUtil.java - trunk )
// reset the transaction stamps, just in case...
clearTransactionStamps();
// initialize the start stamp
I take my words back about the workaround.
It's much more complicated.
On Tue, 2010-06-01 at 09:23 +0300, Deyan Tsvetanov wrote:
Hi guys,
removing synchronized from begin( int timeout) will cause issues.
The problematic code is the following:
(starting from line 180 in
Thanks for the findings and suggestionseven I am facing the same problem
deploying in Jboss4.2 and tested with Jmeter for it's performance.
Everytime I start putting load on server it gets me Error: OutofMemory or
OutofSwapSpace or Not able to create a new native thread even though there
is
Hi rhh,
this looks like a different issue.
It is a memory leak and imho has nothing to do with the synchronized
TransactionUtil.begin() and commit() methods.
First you have to check out the max heap memory set for JBoss. Look for
an option -Xmx256m.
Increase it to 1024m.
If the test
Hi Deyan,
I have tried out these things i.e (option -Xmx256m Increase it to 1024m).
The Server runs fine with 2-5 users load, but goes out of memory for 100
users load when tested with Jmeter for it's performance.
Do I need to profile the Ofbiz code.
Or, Can u suggest any other solution.
Hi rhh,
yes, it looks like a memory leak.
When you have a memory leak you have to profile each component you have
doubts about.
What screens have you tested with jMeter ?
You have to run a profiler, start the jMeter test again and if possible
- share the results. After that we could analyze
Hi,
we probably found a simple solution for the synchronized begin()
problem. We set the TransactionUtil.debugResources flag to false; so no
more DebugXaResources are created in the begin() method, which seems to
be the problematic (performance-wise) part.
Now this method is a lot less
To be clear, I wasn't recommending that we remove synchronized from the begin
method in OFBiz, just that they remove it temporarily and then redo their
performance tests to see if that really is the problem.
You're absolutely right that more work will be necessary to localize the
Hi David,
yes, the thread-local vars are thread safe. However in order to assign
them a synchronized block or method is needed. There is no way to avoid
synchronized block if we want to create a transaction using a static
method without any arguments or without making the caller to keep a
return
Hi,
we are currently evaluating Apache OFBiz for use in one of our projects.
We expect a high load on our application. So we did a test with jMeter
on the sample ecommerce application with 100 parallel sessions and in
average 400 msec (randomized) wait time between requests.
During profiling we
1st level of answer, did you set caches?
https://cwiki.apache.org/confluence/display/OFBTECH/Apache+OFBiz+Technical+Production+Setup+Guide#ApacheOFBizTechnicalProductionSetupGuide-CacheSettings
https://cwiki.apache.org/confluence/display/OFBADMIN/Scaling+and+Performance+Plan
Jacques
From:
Hi,
I'm working with Martin on this project.
We have commented the various cache options as described in the Wiki (and
mailing list),
EXPIRE TIME is 0 in all except for product.* when viewing
/webtools/control/FindUtilCache
Logging is disabled, as are several components.
Also, we have
The theory that Martin mentioned is interesting, and quite possible. Have you
tried removing the synchronized keyword from the begin method to see if it
helps?
That would just be to test the theory, and if that does turn out to be the
bottleneck then the sensitive parts of the method should
13 matches
Mail list logo
