[jira] [Created] (OFBIZ-4292) Remove Synchronized in internalBegin
Remove Synchronized in internalBegin Key: OFBIZ-4292 URL: https://issues.apache.org/jira/browse/OFBIZ-4292 Project: OFBiz Issue Type: Sub-task Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4282) TransactionUtil performance optimisations
[ https://issues.apache.org/jira/browse/OFBIZ-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-4282: Attachment: (was: patch-OFBIZ-4282.patch) TransactionUtil performance optimisations - Key: OFBIZ-4282 URL: https://issues.apache.org/jira/browse/OFBIZ-4282 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Labels: PERFORMANCE Hello, Reviewing TransactionUtil code, I have seen 2 problems: - internalBegin is uselessly synchronized , since it is a static method it is a very big useless Contention Point since not unthread safe instance variable is used - debugResources is true which creates a DebugXAResource (that creates an Exception) , it should be false and made an option for debuging These 2 modifications have been in our production for a while and we noticed CPU reduction and no more contention on TransactionUtil#begin Regards Philippe Mouawad http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4292) Remove Synchronized in internalBegin
[ https://issues.apache.org/jira/browse/OFBIZ-4292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-4292: Attachment: patch-OFBIZ-4292.patch The fix. Regards Philippe http://www.ubik-ingeniere.com Remove Synchronized in internalBegin Key: OFBIZ-4292 URL: https://issues.apache.org/jira/browse/OFBIZ-4292 Project: OFBiz Issue Type: Sub-task Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Labels: performance Attachments: patch-OFBIZ-4292.patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4293) Set TransactionUtil#debugResources default value to false and make it configurable
Set TransactionUtil#debugResources default value to false and make it configurable -- Key: OFBIZ-4293 URL: https://issues.apache.org/jira/browse/OFBIZ-4293 Project: OFBiz Issue Type: Sub-task Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad As asked by David and Jacques: I didn't say I'm against a configurable setting, like a properties file setting. I said I'm against changing the default in the code for all of OFBiz without making it configurable. On the topic of configuration: I'm against business-level configuration in properties files (that should go in the DB), I'm not against technical or system configuration in properties files, in fact that's just where it belongs. About debugResources (debug stack) We could easily create a properties for that -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4282) TransactionUtil performance optimisations
[ https://issues.apache.org/jira/browse/OFBIZ-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13038077#comment-13038077 ] Philippe Mouawad commented on OFBIZ-4282: - Hello, I created 2 subtasks (hope it's not a mistake), because I don't have time to do the configurable now, I will try to do it as soon as possible. Thank you both for your validation Regards Philippe TransactionUtil performance optimisations - Key: OFBIZ-4282 URL: https://issues.apache.org/jira/browse/OFBIZ-4282 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Labels: PERFORMANCE Hello, Reviewing TransactionUtil code, I have seen 2 problems: - internalBegin is uselessly synchronized , since it is a static method it is a very big useless Contention Point since not unthread safe instance variable is used - debugResources is true which creates a DebugXAResource (that creates an Exception) , it should be false and made an option for debuging These 2 modifications have been in our production for a while and we noticed CPU reduction and no more contention on TransactionUtil#begin Regards Philippe Mouawad http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4293) Set TransactionUtil#debugResources default value to false and make it configurable
[ https://issues.apache.org/jira/browse/OFBIZ-4293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13038089#comment-13038089 ] Philippe Mouawad commented on OFBIZ-4293: - Hello, I plan to add this configuration in entityengine.xml and call it: debug-xa-resources value=false / Are you OK with this ? Thank you Regards Philippe Set TransactionUtil#debugResources default value to false and make it configurable -- Key: OFBIZ-4293 URL: https://issues.apache.org/jira/browse/OFBIZ-4293 Project: OFBiz Issue Type: Sub-task Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Labels: performance As asked by David and Jacques: I didn't say I'm against a configurable setting, like a properties file setting. I said I'm against changing the default in the code for all of OFBiz without making it configurable. On the topic of configuration: I'm against business-level configuration in properties files (that should go in the DB), I'm not against technical or system configuration in properties files, in fact that's just where it belongs. About debugResources (debug stack) We could easily create a properties for that -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4293) Set TransactionUtil#debugResources default value to false and make it configurable
[ https://issues.apache.org/jira/browse/OFBIZ-4293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-4293: Attachment: patch-OFBIZ-4293.patch The patch, sorry it also contains removal of synchronized in internalBegin. Philippe http://www.ubik-ingenierie.com Set TransactionUtil#debugResources default value to false and make it configurable -- Key: OFBIZ-4293 URL: https://issues.apache.org/jira/browse/OFBIZ-4293 Project: OFBiz Issue Type: Sub-task Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Labels: performance Attachments: patch-OFBIZ-4293.patch As asked by David and Jacques: I didn't say I'm against a configurable setting, like a properties file setting. I said I'm against changing the default in the code for all of OFBiz without making it configurable. On the topic of configuration: I'm against business-level configuration in properties files (that should go in the DB), I'm not against technical or system configuration in properties files, in fact that's just where it belongs. About debugResources (debug stack) We could easily create a properties for that -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4282) TransactionUtil performance optimisations
[ https://issues.apache.org/jira/browse/OFBIZ-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13037522#comment-13037522 ] Philippe Mouawad commented on OFBIZ-4282: - Hello M. Jones, First let met describe to you how/when I propose an optimisation: 1) We track down in our production CPU and Contention points 2) We make thread dumps Then analyse them. We make a load test on a platform that mimics the production with only the change and track response times, CPU and monitor changes. We also profile ofbiz on load test platform with some well known Profiling tools I won't put here. Then to answer your remarks: 1) I am sorry but I don't agree on the fact that making the method synchronized the timeout for a transaction would bleed over into other transaction, timeout is a parameter so local to the call, synchro would be required if timeout was instance variable (and it wouldn't anyway protect from bleed, or static without being thread local). This modification is in production for more than a year now and Contention point was solved. I think synchronized was here at the start because there were some instance and static variables that were not thread safe, but there were some contribution (one of mine) that fixed the issue to make them Thread Local or synchronized so this is no more useful 2) I agree with you that this feature is helpful for finding the source of transaction timeout BUT consider its cost on a web site with 700 Transaction Hits/s (which is my case), we get 700 Exceptions created each second just for a potential issue, that's why I was saying that disabling it should be the default and proposing method to enable it thrhough webadmin once you have timeout transaction or through a property is better Anyway I repeat that these 2 fixes were HARDLY tested on production (where synchronisation issues have the best chance to occur) since a year now. Regards Philippe TransactionUtil performance optimisations - Key: OFBIZ-4282 URL: https://issues.apache.org/jira/browse/OFBIZ-4282 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Labels: PERFORMANCE Attachments: patch-OFBIZ-4282.patch Hello, Reviewing TransactionUtil code, I have seen 2 problems: - internalBegin is uselessly synchronized , since it is a static method it is a very big useless Contention Point since not unthread safe instance variable is used - debugResources is true which creates a DebugXAResource (that creates an Exception) , it should be false and made an option for debuging These 2 modifications have been in our production for a while and we noticed CPU reduction and no more contention on TransactionUtil#begin Regards Philippe Mouawad http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (OFBIZ-4282) TransactionUtil performance optimisations
[ https://issues.apache.org/jira/browse/OFBIZ-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13037522#comment-13037522 ] Philippe Mouawad edited comment on OFBIZ-4282 at 5/22/11 7:51 AM: -- Hello M. Jones, First let met describe to you how/when I propose an optimisation: 1) We track down in our production CPU and Contention points 2) We make thread dumps Then analyse them. We make a load test on a platform that mimics the production with only the change and track response times, CPU and monitor changes. We also profile ofbiz on load test platform with some well known Profiling tools I won't put here. Then to answer your remarks: 1) I am sorry but I don't agree on the fact that making the method not synchronized, the timeout for a transaction would bleed over into other transaction, timeout is a parameter so local to the call, synchro would be required if timeout was instance variable (and it wouldn't anyway protect from bleed) or static without being thread local. I think synchronized was here at the start because there were some instance and static variables in TransactionUtil that were not thread safe, but there were some contributions (one of mine if I remember well ?) that fixed the issues to make them Thread Local or use synchronized Collections so this is not more useful. This modification is in production for more than a year now and Contention point was solved. 2) I agree with you that this feature is helpful for finding the source of transaction timeout BUT consider its cost on a web site with 700 Transaction Hits/s (which is my case), we get 700 Exceptions created each second just for a potential issue, that's why I was saying that disabling it should be the default and proposing method to enable it thrhough webadmin once you have timeout transaction or through a property is better. Once again at the time we saw CPU on production servers drop from 5%. Anyway I repeat that these 2 fixes were HARDLY tested on preproduction then production (where synchronisation issues have the best chance to occur) since a year now. Regards Philippe was (Author: p.moua...@ubik-ingenierie.com): Hello M. Jones, First let met describe to you how/when I propose an optimisation: 1) We track down in our production CPU and Contention points 2) We make thread dumps Then analyse them. We make a load test on a platform that mimics the production with only the change and track response times, CPU and monitor changes. We also profile ofbiz on load test platform with some well known Profiling tools I won't put here. Then to answer your remarks: 1) I am sorry but I don't agree on the fact that making the method synchronized the timeout for a transaction would bleed over into other transaction, timeout is a parameter so local to the call, synchro would be required if timeout was instance variable (and it wouldn't anyway protect from bleed, or static without being thread local). This modification is in production for more than a year now and Contention point was solved. I think synchronized was here at the start because there were some instance and static variables that were not thread safe, but there were some contribution (one of mine) that fixed the issue to make them Thread Local or synchronized so this is no more useful 2) I agree with you that this feature is helpful for finding the source of transaction timeout BUT consider its cost on a web site with 700 Transaction Hits/s (which is my case), we get 700 Exceptions created each second just for a potential issue, that's why I was saying that disabling it should be the default and proposing method to enable it thrhough webadmin once you have timeout transaction or through a property is better Anyway I repeat that these 2 fixes were HARDLY tested on production (where synchronisation issues have the best chance to occur) since a year now. Regards Philippe TransactionUtil performance optimisations - Key: OFBIZ-4282 URL: https://issues.apache.org/jira/browse/OFBIZ-4282 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Labels: PERFORMANCE Attachments: patch-OFBIZ-4282.patch Hello, Reviewing TransactionUtil code, I have seen 2 problems: - internalBegin is uselessly synchronized , since it is a static method it is a very big useless Contention Point since not unthread safe instance variable is used - debugResources is true which creates a DebugXAResource (that creates an Exception) , it should be false and made an option for debuging These 2 modifications have been in our production for a while and we noticed CPU reduction and no more contention on TransactionUtil#begin Regards
[jira] [Commented] (OFBIZ-2353) SequenceUtil may generate duplicate IDs in Load Balancing mode
[ https://issues.apache.org/jira/browse/OFBIZ-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13037536#comment-13037536 ] Philippe Mouawad commented on OFBIZ-2353: - Hello Jacques, For Ofbiz we implemented a native DB Sequence since the target DB is Oracle, we used a sequence with INCREMENT BY N where N is = 50. I was talking about select for update but it was in another different context where I had to create a DB independent algo to generate unique ID in a clustered environment. In your case if you put maxTries to 100, you may have a contention point in the worst case since you may lock between 500 ms to 5s. But maybe you can reduce the risk by increasing bankSize to 50 or 100 then sequence generation will be less used. Regards Philippe SequenceUtil may generate duplicate IDs in Load Balancing mode --- Key: OFBIZ-2353 URL: https://issues.apache.org/jira/browse/OFBIZ-2353 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 4.0, Release Branch 09.04, SVN trunk Reporter: Philippe Mouawad Assignee: Adam Heath Priority: Critical If Ofbiz is deploy on 2 servers in Load Balancing Mode SequenceUtil will generate duplicate IDs because synchronization is done at JVM level instead of doing it in DB. A good replacement implementation would be: org.hibernate.id.enhanced.TableGenerator But it would involve a dependency on Hibernate Philippe www.ubik-ingenierie.com -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4290) UtilCache#getPropertyParam should test property existence instead of rely on MissingResourceException
UtilCache#getPropertyParam should test property existence instead of rely on MissingResourceException -- Key: OFBIZ-4290 URL: https://issues.apache.org/jira/browse/OFBIZ-4290 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Priority: Minor Attachments: patch-OFBIZ-4290.patch Hello, UtilCache#getPropertyParam should call res.containsKey instead of relying on catching MissingResourceException, which will reduce number of Exceptions created so CPU. Regards Philippe http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4290) UtilCache#getPropertyParam should test property existence instead of rely on MissingResourceException
[ https://issues.apache.org/jira/browse/OFBIZ-4290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-4290: Attachment: patch-OFBIZ-4290.patch The fix UtilCache#getPropertyParam should test property existence instead of rely on MissingResourceException -- Key: OFBIZ-4290 URL: https://issues.apache.org/jira/browse/OFBIZ-4290 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Priority: Minor Labels: performance Attachments: patch-OFBIZ-4290.patch Hello, UtilCache#getPropertyParam should call res.containsKey instead of relying on catching MissingResourceException, which will reduce number of Exceptions created so CPU. Regards Philippe http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4282) TransactionUtil performance optimisations
[ https://issues.apache.org/jira/browse/OFBIZ-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13037549#comment-13037549 ] Philippe Mouawad commented on OFBIZ-4282: - Again, I agree with you about useless transactions in some places but it is a more impacting change. So it would be located in ModelScreen#renderScreenString ? Regards Philippe TransactionUtil performance optimisations - Key: OFBIZ-4282 URL: https://issues.apache.org/jira/browse/OFBIZ-4282 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Labels: PERFORMANCE Attachments: patch-OFBIZ-4282.patch Hello, Reviewing TransactionUtil code, I have seen 2 problems: - internalBegin is uselessly synchronized , since it is a static method it is a very big useless Contention Point since not unthread safe instance variable is used - debugResources is true which creates a DebugXAResource (that creates an Exception) , it should be false and made an option for debuging These 2 modifications have been in our production for a while and we noticed CPU reduction and no more contention on TransactionUtil#begin Regards Philippe Mouawad http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4098) Ability to plug a new Cache Implementation
[ https://issues.apache.org/jira/browse/OFBIZ-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13037087#comment-13037087 ] Philippe Mouawad commented on OFBIZ-4098: - Hello, Are there any remarks regarding this work. Thank you Regards Philippe Ability to plug a new Cache Implementation -- Key: OFBIZ-4098 URL: https://issues.apache.org/jira/browse/OFBIZ-4098 Project: OFBiz Issue Type: New Feature Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Attachments: ofbiz-4098.patch Original Estimate: 96h Remaining Estimate: 96h Hello, I would like to contribute a patch to enable switching from Ofbiz native Cache (today UtilCache) to another implementation like EhCache for example. To avoid big code impacts, UtilCache would stay the same and delegate to the real cache implementation this will impact less classes and big impacts would stay in UtilCache package. Ability to plug another implementation like EhCache for example would enable easily plugin with Terracota for example which on big Web Site gives much performance enhancements. Is the format to contribute this kind of evolution also a patch ? Thank you Regards Philippe http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-1029) TransactionUtil Refactoring
[ https://issues.apache.org/jira/browse/OFBIZ-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13036041#comment-13036041 ] Philippe Mouawad commented on OFBIZ-1029: - Hello Karl, I looked at the patch but it is rather hard to read, could you attach the classes in a zip file instead of patch format ? Thank you Regards Philippe http://www.ubik-ingenierie.com TransactionUtil Refactoring --- Key: OFBIZ-1029 URL: https://issues.apache.org/jira/browse/OFBIZ-1029 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Environment: Win XP Reporter: Karl Eilebrecht Assignee: Si Chen Priority: Minor Fix For: SVN trunk Attachments: OfbizTransactionHandlingEn.pdf, patch9671.patch This issue is part of Key-Work Ofbiz Contribution Proposal. http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal Based on Release: 540035 Includes: - Required: JIRA-1016 Recommended: Classes: TransactionUtil.java, OfbizTransactionState.java, DebugXaResource.java, TxDelegate.java, CommonServices.java Description: Refactoring of TransactionUtil and helper for wrapping single operations in a new transaction. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4282) TransactionUtil performance optimisations
[ https://issues.apache.org/jira/browse/OFBIZ-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13036042#comment-13036042 ] Philippe Mouawad commented on OFBIZ-4282: - Hello Karl, I commented on OFBIZ-1029 TransactionUtil performance optimisations - Key: OFBIZ-4282 URL: https://issues.apache.org/jira/browse/OFBIZ-4282 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Labels: PERFORMANCE Attachments: patch-OFBIZ-4282.patch Hello, Reviewing TransactionUtil code, I have seen 2 problems: - internalBegin is uselessly synchronized , since it is a static method it is a very big useless Contention Point since not unthread safe instance variable is used - debugResources is true which creates a DebugXAResource (that creates an Exception) , it should be false and made an option for debuging These 2 modifications have been in our production for a while and we noticed CPU reduction and no more contention on TransactionUtil#begin Regards Philippe Mouawad http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4285) Performance : GenericDao does not always use complete PreparedStatement
Performance : GenericDao does not always use complete PreparedStatement
---
Key: OFBIZ-4285
URL: https://issues.apache.org/jira/browse/OFBIZ-4285
Project: OFBiz
Issue Type: Improvement
Components: framework
Affects Versions: SVN trunk
Reporter: Philippe Mouawad
Hello,
While profiling SQL requests going to DB I noticed a strange behaviour where
Ofbiz builds SQL Statement partly with ? and partly with inline values which
results in lower Database performances.
Example:
JobManager#poll ListGenericValue jobEnt = delegator.findByAnd(JobSandbox,
updateFields, order);
results in the following SQL query:
UPDATE ECFR.JOB_SANDBOX SET RUN_BY_INSTANCE_ID = ?, STATUS_ID = ? WHERE
((RUN_TIME = '2011-05-17 17:02:33.163' AND START_DATE_TIME IS NULL AND
CANCEL_DATE_TIME IS NULL AND RUN_BY_INSTANCE_ID IS NULL) AND (POOL_ID IS NULL
OR POOL_ID = 'poolfrt025'))
As you can see, RUN_TIME condition is inlined.
Analysing this behaviour, I think issue comes from EntityConditionBase#addValue:
protected void addValue(StringBuilder buffer, ModelField field, Object
value, ListEntityConditionParam params) {
SqlJdbcUtil.addValue(buffer, params == null ? null : field, value,
params);
}
and particularly:
params == null ? null : field
this ends up here in SqlJdbcUtil#addValueSingle and you can see that as field
is null :
public static void addValueSingle(StringBuilder buffer, ModelField field,
Object value, ListEntityConditionParam params) {
if (field != null) {
buffer.append('?');
} else {
buffer.append('\'').append(value).append('\'');
}
if (field != null params != null) params.add(new
EntityConditionParam(field, value));
}
I there some reason for this code ?
Is there another way to use delegator that makes it work better ?
Thank you
Regards
Philippe
http://www.ubik-ingenierie.com
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4286) Performance : GenericDao does not always use complete PreparedStatement
Performance : GenericDao does not always use complete PreparedStatement
---
Key: OFBIZ-4286
URL: https://issues.apache.org/jira/browse/OFBIZ-4286
Project: OFBiz
Issue Type: Improvement
Components: framework
Affects Versions: SVN trunk
Reporter: Philippe Mouawad
Hello,
While profiling SQL requests going to DB I noticed a strange behaviour where
Ofbiz builds SQL Statement partly with ? and partly with inline values which
results in lower Database performances.
Example:
JobManager#poll ListGenericValue jobEnt = delegator.findByAnd(JobSandbox,
updateFields, order);
results in the following SQL query:
UPDATE ECFR.JOB_SANDBOX SET RUN_BY_INSTANCE_ID = ?, STATUS_ID = ? WHERE
((RUN_TIME = '2011-05-17 17:02:33.163' AND START_DATE_TIME IS NULL AND
CANCEL_DATE_TIME IS NULL AND RUN_BY_INSTANCE_ID IS NULL) AND (POOL_ID IS NULL
OR POOL_ID = 'poolfrt025'))
As you can see, RUN_TIME condition is inlined.
Analysing this behaviour, I think issue comes from EntityConditionBase#addValue:
protected void addValue(StringBuilder buffer, ModelField field, Object
value, ListEntityConditionParam params) {
SqlJdbcUtil.addValue(buffer, params == null ? null : field, value,
params);
}
and particularly:
params == null ? null : field
this ends up here in SqlJdbcUtil#addValueSingle and you can see that as field
is null :
public static void addValueSingle(StringBuilder buffer, ModelField field,
Object value, ListEntityConditionParam params) {
if (field != null) {
buffer.append('?');
} else {
buffer.append('\'').append(value).append('\'');
}
if (field != null params != null) params.add(new
EntityConditionParam(field, value));
}
I there some reason for this code ?
Is there another way to use delegator that makes it work better ?
Thank you
Regards
Philippe
http://www.ubik-ingenierie.com
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4285) Performance : GenericDao does not always use complete PreparedStatement
[
https://issues.apache.org/jira/browse/OFBIZ-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philippe Mouawad updated OFBIZ-4285:
Description:
Hello,
While profiling SQL requests going to DB I noticed a strange behaviour where
Ofbiz builds SQL Statement partly with ? and partly with inline values which
results in lower Database performances.
Issue existed on updateByCondition and has been fixed but it still exists in
deleteByCondition.
It also exists in find where EntityFunction are used
I there some reason for this code ?
Is there another way to use delegator that makes it work better ?
Thank you
Regards
Philippe
http://www.ubik-ingenierie.com
was:
Hello,
While profiling SQL requests going to DB I noticed a strange behaviour where
Ofbiz builds SQL Statement partly with ? and partly with inline values which
results in lower Database performances.
Example:
JobManager#poll ListGenericValue jobEnt = delegator.findByAnd(JobSandbox,
updateFields, order);
results in the following SQL query:
UPDATE ECFR.JOB_SANDBOX SET RUN_BY_INSTANCE_ID = ?, STATUS_ID = ? WHERE
((RUN_TIME = '2011-05-17 17:02:33.163' AND START_DATE_TIME IS NULL AND
CANCEL_DATE_TIME IS NULL AND RUN_BY_INSTANCE_ID IS NULL) AND (POOL_ID IS NULL
OR POOL_ID = 'poolfrt025'))
As you can see, RUN_TIME condition is inlined.
Analysing this behaviour, I think issue comes from EntityConditionBase#addValue:
protected void addValue(StringBuilder buffer, ModelField field, Object
value, ListEntityConditionParam params) {
SqlJdbcUtil.addValue(buffer, params == null ? null : field, value,
params);
}
and particularly:
params == null ? null : field
this ends up here in SqlJdbcUtil#addValueSingle and you can see that as field
is null :
public static void addValueSingle(StringBuilder buffer, ModelField field,
Object value, ListEntityConditionParam params) {
if (field != null) {
buffer.append('?');
} else {
buffer.append('\'').append(value).append('\'');
}
if (field != null params != null) params.add(new
EntityConditionParam(field, value));
}
I there some reason for this code ?
Is there another way to use delegator that makes it work better ?
Thank you
Regards
Philippe
http://www.ubik-ingenierie.com
Performance : GenericDao does not always use complete PreparedStatement
---
Key: OFBIZ-4285
URL: https://issues.apache.org/jira/browse/OFBIZ-4285
Project: OFBiz
Issue Type: Improvement
Components: framework
Affects Versions: SVN trunk
Reporter: Philippe Mouawad
Labels: PERFORMANCE
Hello,
While profiling SQL requests going to DB I noticed a strange behaviour where
Ofbiz builds SQL Statement partly with ? and partly with inline values which
results in lower Database performances.
Issue existed on updateByCondition and has been fixed but it still exists in
deleteByCondition.
It also exists in find where EntityFunction are used
I there some reason for this code ?
Is there another way to use delegator that makes it work better ?
Thank you
Regards
Philippe
http://www.ubik-ingenierie.com
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (OFBIZ-4286) Performance : GenericDao does not always use complete PreparedStatement
[
https://issues.apache.org/jira/browse/OFBIZ-4286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philippe Mouawad closed OFBIZ-4286.
---
Performance : GenericDao does not always use complete PreparedStatement
---
Key: OFBIZ-4286
URL: https://issues.apache.org/jira/browse/OFBIZ-4286
Project: OFBiz
Issue Type: Improvement
Components: framework
Affects Versions: SVN trunk
Reporter: Philippe Mouawad
Hello,
While profiling SQL requests going to DB I noticed a strange behaviour where
Ofbiz builds SQL Statement partly with ? and partly with inline values which
results in lower Database performances.
Example:
JobManager#poll ListGenericValue jobEnt =
delegator.findByAnd(JobSandbox, updateFields, order);
results in the following SQL query:
UPDATE ECFR.JOB_SANDBOX SET RUN_BY_INSTANCE_ID = ?, STATUS_ID = ? WHERE
((RUN_TIME = '2011-05-17 17:02:33.163' AND START_DATE_TIME IS NULL AND
CANCEL_DATE_TIME IS NULL AND RUN_BY_INSTANCE_ID IS NULL) AND (POOL_ID IS NULL
OR POOL_ID = 'poolfrt025'))
As you can see, RUN_TIME condition is inlined.
Analysing this behaviour, I think issue comes from
EntityConditionBase#addValue:
protected void addValue(StringBuilder buffer, ModelField field, Object
value, ListEntityConditionParam params) {
SqlJdbcUtil.addValue(buffer, params == null ? null : field, value,
params);
}
and particularly:
params == null ? null : field
this ends up here in SqlJdbcUtil#addValueSingle and you can see that as field
is null :
public static void addValueSingle(StringBuilder buffer, ModelField field,
Object value, ListEntityConditionParam params) {
if (field != null) {
buffer.append('?');
} else {
buffer.append('\'').append(value).append('\'');
}
if (field != null params != null) params.add(new
EntityConditionParam(field, value));
}
I there some reason for this code ?
Is there another way to use delegator that makes it work better ?
Thank you
Regards
Philippe
http://www.ubik-ingenierie.com
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OFBIZ-4286) Performance : GenericDao does not always use complete PreparedStatement
[
https://issues.apache.org/jira/browse/OFBIZ-4286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philippe Mouawad resolved OFBIZ-4286.
-
Resolution: Duplicate
Duplicate OFBIZ-4285
Performance : GenericDao does not always use complete PreparedStatement
---
Key: OFBIZ-4286
URL: https://issues.apache.org/jira/browse/OFBIZ-4286
Project: OFBiz
Issue Type: Improvement
Components: framework
Affects Versions: SVN trunk
Reporter: Philippe Mouawad
Hello,
While profiling SQL requests going to DB I noticed a strange behaviour where
Ofbiz builds SQL Statement partly with ? and partly with inline values which
results in lower Database performances.
Example:
JobManager#poll ListGenericValue jobEnt =
delegator.findByAnd(JobSandbox, updateFields, order);
results in the following SQL query:
UPDATE ECFR.JOB_SANDBOX SET RUN_BY_INSTANCE_ID = ?, STATUS_ID = ? WHERE
((RUN_TIME = '2011-05-17 17:02:33.163' AND START_DATE_TIME IS NULL AND
CANCEL_DATE_TIME IS NULL AND RUN_BY_INSTANCE_ID IS NULL) AND (POOL_ID IS NULL
OR POOL_ID = 'poolfrt025'))
As you can see, RUN_TIME condition is inlined.
Analysing this behaviour, I think issue comes from
EntityConditionBase#addValue:
protected void addValue(StringBuilder buffer, ModelField field, Object
value, ListEntityConditionParam params) {
SqlJdbcUtil.addValue(buffer, params == null ? null : field, value,
params);
}
and particularly:
params == null ? null : field
this ends up here in SqlJdbcUtil#addValueSingle and you can see that as field
is null :
public static void addValueSingle(StringBuilder buffer, ModelField field,
Object value, ListEntityConditionParam params) {
if (field != null) {
buffer.append('?');
} else {
buffer.append('\'').append(value).append('\'');
}
if (field != null params != null) params.add(new
EntityConditionParam(field, value));
}
I there some reason for this code ?
Is there another way to use delegator that makes it work better ?
Thank you
Regards
Philippe
http://www.ubik-ingenierie.com
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4285) Performance : GenericDao does not always use complete PreparedStatement
[ https://issues.apache.org/jira/browse/OFBIZ-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-4285: Attachment: patch-OFBIZ-4285-genericDAO.patch Patch that fixes deleteByCondition Philippe Mouawad http://www.ubik-ingenierie.com Performance : GenericDao does not always use complete PreparedStatement --- Key: OFBIZ-4285 URL: https://issues.apache.org/jira/browse/OFBIZ-4285 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Labels: PERFORMANCE Attachments: patch-OFBIZ-4285-genericDAO.patch Hello, While profiling SQL requests going to DB I noticed a strange behaviour where Ofbiz builds SQL Statement partly with ? and partly with inline values which results in lower Database performances. Issue existed on updateByCondition and has been fixed but it still exists in deleteByCondition. It also exists in find where EntityFunction are used I there some reason for this code ? Is there another way to use delegator that makes it work better ? Thank you Regards Philippe http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4285) Performance : GenericDao does not always use complete PreparedStatement
[ https://issues.apache.org/jira/browse/OFBIZ-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-4285: Attachment: patch-OFBIZ-4285-2.patch Patch that fixes issue on SELECT queries. I am less sur of this one, your critics are welcome. Philippe http://www.ubik-ingenierie.com Performance : GenericDao does not always use complete PreparedStatement --- Key: OFBIZ-4285 URL: https://issues.apache.org/jira/browse/OFBIZ-4285 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Labels: PERFORMANCE Attachments: patch-OFBIZ-4285-2.patch, patch-OFBIZ-4285-genericDAO.patch Hello, While profiling SQL requests going to DB I noticed a strange behaviour where Ofbiz builds SQL Statement partly with ? and partly with inline values which results in lower Database performances. Issue existed on updateByCondition and has been fixed but it still exists in deleteByCondition. It also exists in find where EntityFunction are used I there some reason for this code ? Is there another way to use delegator that makes it work better ? Thank you Regards Philippe http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4285) Performance : GenericDao does not always use complete PreparedStatement
[ https://issues.apache.org/jira/browse/OFBIZ-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-4285: Description: Hello, While profiling SQL requests going to DB I noticed a strange behaviour where Ofbiz builds SQL Statement partly with ? and partly with inline values which results in lower Database performances. Issue existed on updateByCondition and has been fixed but it still exists in deleteByCondition. It also exists in find where EntityFunction are used for Select queries Thank you Regards Philippe http://www.ubik-ingenierie.com was: Hello, While profiling SQL requests going to DB I noticed a strange behaviour where Ofbiz builds SQL Statement partly with ? and partly with inline values which results in lower Database performances. Issue existed on updateByCondition and has been fixed but it still exists in deleteByCondition. It also exists in find where EntityFunction are used I there some reason for this code ? Is there another way to use delegator that makes it work better ? Thank you Regards Philippe http://www.ubik-ingenierie.com Performance : GenericDao does not always use complete PreparedStatement --- Key: OFBIZ-4285 URL: https://issues.apache.org/jira/browse/OFBIZ-4285 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Labels: PERFORMANCE Attachments: patch-OFBIZ-4285-2.patch, patch-OFBIZ-4285-genericDAO.patch Hello, While profiling SQL requests going to DB I noticed a strange behaviour where Ofbiz builds SQL Statement partly with ? and partly with inline values which results in lower Database performances. Issue existed on updateByCondition and has been fixed but it still exists in deleteByCondition. It also exists in find where EntityFunction are used for Select queries Thank you Regards Philippe http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4278) ModelScreen does not rollback transaction when ScreenRenderException occurs
[ https://issues.apache.org/jira/browse/OFBIZ-4278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-4278: Attachment: patch-OFBIZ-4278.patch The patch that fixes the issue. Philippe Mouawad http://www.ubik-ingenierie.com ModelScreen does not rollback transaction when ScreenRenderException occurs --- Key: OFBIZ-4278 URL: https://issues.apache.org/jira/browse/OFBIZ-4278 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Attachments: patch-OFBIZ-4278.patch Hello, Is there any reason why ModelScreen#renderScreenString() does not call TransactionUtil#rollback when ScreenRenderException occurs. It does so when Exception or RuntimeException occur. Furthermore, what's the point in duplicating code for Exception and RuntimeException ? As I am not sure if there is a reason , I ask, if you confirm it is useless I will provide a patch. Regards Philippe -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4282) TransactionUtil performance optimisations
TransactionUtil performance optimisations - Key: OFBIZ-4282 URL: https://issues.apache.org/jira/browse/OFBIZ-4282 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Hello, Reviewing TransactionUtil code, I have seen 2 problems: - internalBegin is uselessly synchronized , since it is a static method it is a very big useless Contention Point since not unthread safe instance variable is used - debugResources is true which creates a DebugXAResource (that creates an Exception) , it should be false and made an option for debuging These 2 modifications have been in our production for a while and we noticed CPU reduction and no more contention on TransactionUtil#begin Regards Philippe Mouawad http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4282) TransactionUtil performance optimisations
[ https://issues.apache.org/jira/browse/OFBIZ-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-4282: Attachment: patch-OFBIZ-4282.patch Patch that fixes the issue TransactionUtil performance optimisations - Key: OFBIZ-4282 URL: https://issues.apache.org/jira/browse/OFBIZ-4282 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Labels: PERFORMANCE Attachments: patch-OFBIZ-4282.patch Hello, Reviewing TransactionUtil code, I have seen 2 problems: - internalBegin is uselessly synchronized , since it is a static method it is a very big useless Contention Point since not unthread safe instance variable is used - debugResources is true which creates a DebugXAResource (that creates an Exception) , it should be false and made an option for debuging These 2 modifications have been in our production for a while and we noticed CPU reduction and no more contention on TransactionUtil#begin Regards Philippe Mouawad http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4283) DBCPConnectionFactory Configuration and Performance improvements
DBCPConnectionFactory Configuration and Performance improvements Key: OFBIZ-4283 URL: https://issues.apache.org/jira/browse/OFBIZ-4283 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Hello, I enhanced DBCPConnectionFactory to provide more configuration options of DBCP: - jdbc-properties - test-on-borrow - test-on-return - test-while-idle - pool-timeout - soft-min-evictable-idle-time-millis And to read some existing one like validationQuery called pool-jdbc-test-stmt in Ofbiz XSD. I also added PreparedStatement Cache: - jdbc-maxOpenPreparedStatements These improvement require upgrade to: - commons-dbcp-1.4 - commons-pool-1.5.6 I also enhanced XSD. These enhancement make the JDBC pooling much more stable and fast. Regards Philippe Mouawad http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4283) DBCPConnectionFactory Configuration and Performance improvements
[ https://issues.apache.org/jira/browse/OFBIZ-4283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-4283: Attachment: patch-OFBIZ-4283.patch Patch to: entity-config.xsd DBCPConnectionFactory.java This patch requires: - commons-dbcp-1.4.jar - commons-pool-1.5.6.jar DBCPConnectionFactory Configuration and Performance improvements Key: OFBIZ-4283 URL: https://issues.apache.org/jira/browse/OFBIZ-4283 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Labels: PERFORMANCE Attachments: patch-OFBIZ-4283.patch Hello, I enhanced DBCPConnectionFactory to provide more configuration options of DBCP: - jdbc-properties - test-on-borrow - test-on-return - test-while-idle - pool-timeout - soft-min-evictable-idle-time-millis And to read some existing one like validationQuery called pool-jdbc-test-stmt in Ofbiz XSD. I also added PreparedStatement Cache: - jdbc-maxOpenPreparedStatements These improvement require upgrade to: - commons-dbcp-1.4 - commons-pool-1.5.6 I also enhanced XSD. These enhancement make the JDBC pooling much more stable and fast. Regards Philippe Mouawad http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-2353) SequenceUtil may generate duplicate IDs in Load Balancing mode
[ https://issues.apache.org/jira/browse/OFBIZ-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13033511#comment-13033511 ] Philippe Mouawad commented on OFBIZ-2353: - Hello Jacques, No we didn't implement Karl Algorithm. What we did was to use another ID generator that relies on Oracle Sequences. But this approach is tightly related to Sequence mechanism available in POSTGRES, Oracle and DB2 (not mysql from what I know). Karl approach seems right to me but I agree there's a risk of infinite loop if you don't protect with a number of tries. I once implemented this kind of algorithm and we used Pessimistic locking (select for update in Oracle) , this feature seems to be cross DB since it exists in Hibernate so maybe it can also work. My opinion is to rely on native DB mechanisms instead of trying it in Java. Either Sequences if they exist everywhere or pessimistic locking Regards Philippe SequenceUtil may generate duplicate IDs in Load Balancing mode --- Key: OFBIZ-2353 URL: https://issues.apache.org/jira/browse/OFBIZ-2353 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 4.0, Release Branch 09.04, SVN trunk Reporter: Philippe Mouawad Assignee: Adam Heath Priority: Critical If Ofbiz is deploy on 2 servers in Load Balancing Mode SequenceUtil will generate duplicate IDs because synchronization is done at JVM level instead of doing it in DB. A good replacement implementation would be: org.hibernate.id.enhanced.TableGenerator But it would involve a dependency on Hibernate Philippe www.ubik-ingenierie.com -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4277) Performance : In TransactionUtil StackTrace begining tracing should not be enabled by default
Performance : In TransactionUtil StackTrace begining tracing should not be enabled by default - Key: OFBIZ-4277 URL: https://issues.apache.org/jira/browse/OFBIZ-4277 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Hello, Currently, TransactionUtil creates a new Exception() to trace start of a transaction + all associated mechanism in suspend. This has a big CPU cost in heavy load, I think this should be an option disabled by default and that can be enabled through dynadmin. Regards Philippe http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4278) ModelScreen does not rollback transaction when ScreenRenderException occurs
ModelScreen does not rollback transaction when ScreenRenderException occurs --- Key: OFBIZ-4278 URL: https://issues.apache.org/jira/browse/OFBIZ-4278 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Hello, Is there any reason why ModelScreen#renderScreenString() does not call TransactionUtil#rollback when ScreenRenderException occurs. It does so when Exception or RuntimeException occur. Furthermore, what's the point in duplicating code for Exception and RuntimeException ? As I am not sure if there is a reason , I ask, if you confirm it is useless I will provide a patch. Regards Philippe -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4268) ResourceBundleMapWrapper memory usage improvement
[ https://issues.apache.org/jira/browse/OFBIZ-4268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13029226#comment-13029226 ] Philippe Mouawad commented on OFBIZ-4268: - Hello, UAT have been successful, patch is OK and has been put in production Regards Philippe http://www.ubik-ingenierie.com ResourceBundleMapWrapper memory usage improvement - Key: OFBIZ-4268 URL: https://issues.apache.org/jira/browse/OFBIZ-4268 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Labels: MEMORY, PERFORMANCE Attachments: patch-OFBIZ-4268.patch Hello, We are working on performance improvements while load testing the application, and I noticed that ResourceBundleMapWrapper uses arounbd 140 Ko per Serving thread, in our configuration with around 1000 thread, this is a big memory impact. I started investigating the class and code seems strange to me, in fact I don't understand why InternalRbmWrapper constructor copies creates a Map by copying content of ResourceBundle. Why not only have a reference and delegate calls to the ResourceBundle ? Furthermore since put methods throw RuntimeException, I really don't see any case where the Map will change. I made a test removing this code and delegating to resourceBundle and it seems OK. If someone knows why it was made like that I would really be interested, if there is no reason I will submit a patch Thank you Regards Philippe http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4268) ResourceBundleMapWrapper memory usage improvement
[ https://issues.apache.org/jira/browse/OFBIZ-4268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13029319#comment-13029319 ] Philippe Mouawad commented on OFBIZ-4268: - Hello Jacques, In fact I don't see any case where createMapWhenNeeded() will be used, but if you look at Adrian comment, I was afraid of introducing a regression so I kept this behaviour but made it lazy so building the map will occur only when it is required to (so will never happen I think) Regards Philippe http://www.ubik-ingenierie.com ResourceBundleMapWrapper memory usage improvement - Key: OFBIZ-4268 URL: https://issues.apache.org/jira/browse/OFBIZ-4268 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Assignee: Jacques Le Roux Labels: MEMORY, PERFORMANCE Attachments: patch-OFBIZ-4268.patch Hello, We are working on performance improvements while load testing the application, and I noticed that ResourceBundleMapWrapper uses arounbd 140 Ko per Serving thread, in our configuration with around 1000 thread, this is a big memory impact. I started investigating the class and code seems strange to me, in fact I don't understand why InternalRbmWrapper constructor copies creates a Map by copying content of ResourceBundle. Why not only have a reference and delegate calls to the ResourceBundle ? Furthermore since put methods throw RuntimeException, I really don't see any case where the Map will change. I made a test removing this code and delegating to resourceBundle and it seems OK. If someone knows why it was made like that I would really be interested, if there is no reason I will submit a patch Thank you Regards Philippe http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4268) ResourceBundleMapWrapper memory usage improvement
[ https://issues.apache.org/jira/browse/OFBIZ-4268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-4268: Attachment: patch-OFBIZ-4268.patch Patch that creates the Map only when it is required ResourceBundleMapWrapper memory usage improvement - Key: OFBIZ-4268 URL: https://issues.apache.org/jira/browse/OFBIZ-4268 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Labels: MEMORY, PERFORMANCE Attachments: patch-OFBIZ-4268.patch Hello, We are working on performance improvements while load testing the application, and I noticed that ResourceBundleMapWrapper uses arounbd 140 Ko per Serving thread, in our configuration with around 1000 thread, this is a big memory impact. I started investigating the class and code seems strange to me, in fact I don't understand why InternalRbmWrapper constructor copies creates a Map by copying content of ResourceBundle. Why not only have a reference and delegate calls to the ResourceBundle ? Furthermore since put methods throw RuntimeException, I really don't see any case where the Map will change. I made a test removing this code and delegating to resourceBundle and it seems OK. If someone knows why it was made like that I would really be interested, if there is no reason I will submit a patch Thank you Regards Philippe http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4268) ResourceBundleMapWrapper memory usage improvement
[ https://issues.apache.org/jira/browse/OFBIZ-4268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13027315#comment-13027315 ] Philippe Mouawad commented on OFBIZ-4268: - Hello, Here is the patch, our load tests were concluding, both memory usage and CPU where reduced. Full UAT will occur within next 2 weeks, I will comment when they are ended. Regards Philippe http://www.ubik-ingenierie.com ResourceBundleMapWrapper memory usage improvement - Key: OFBIZ-4268 URL: https://issues.apache.org/jira/browse/OFBIZ-4268 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Labels: MEMORY, PERFORMANCE Attachments: patch-OFBIZ-4268.patch Hello, We are working on performance improvements while load testing the application, and I noticed that ResourceBundleMapWrapper uses arounbd 140 Ko per Serving thread, in our configuration with around 1000 thread, this is a big memory impact. I started investigating the class and code seems strange to me, in fact I don't understand why InternalRbmWrapper constructor copies creates a Map by copying content of ResourceBundle. Why not only have a reference and delegate calls to the ResourceBundle ? Furthermore since put methods throw RuntimeException, I really don't see any case where the Map will change. I made a test removing this code and delegating to resourceBundle and it seems OK. If someone knows why it was made like that I would really be interested, if there is no reason I will submit a patch Thank you Regards Philippe http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4268) ResourceBundleMapWrapper memory usage improvement
ResourceBundleMapWrapper memory usage improvement - Key: OFBIZ-4268 URL: https://issues.apache.org/jira/browse/OFBIZ-4268 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Hello, We are working on performance improvements while load testing the application, and I noticed that ResourceBundleMapWrapper uses arounbd 140 Ko per Serving thread, in our configuration with around 1000 thread, this is a big memory impact. I started investigating the class and code seems strange to me, in fact I don't understand why InternalRbmWrapper constructor copies creates a Map by copying content of ResourceBundle. Why not only have a reference and delegate calls to the ResourceBundle ? Furthermore since put methods throw RuntimeException, I really don't see any case where the Map will change. I made a test removing this code and delegating to resourceBundle and it seems OK. If someone knows why it was made like that I would really be interested, if there is no reason I will submit a patch Thank you Regards Philippe http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4268) ResourceBundleMapWrapper memory usage improvement
[ https://issues.apache.org/jira/browse/OFBIZ-4268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13026949#comment-13026949 ] Philippe Mouawad commented on OFBIZ-4268: - Hello, Thank you for your very rapid response. I propose to implement the following: - I will just lazy build the Map once it is requested but till then I will use ResourceBundle, so this will not change the behaviour, It will make us gain CPU + Memory when methods not using map will be accessed. My first tests seem OK but we plan a full UTA so if I submit this patch be confident It will work. Regards Philippe http://www.ubik-ingenierie.com ResourceBundleMapWrapper memory usage improvement - Key: OFBIZ-4268 URL: https://issues.apache.org/jira/browse/OFBIZ-4268 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Labels: MEMORY, PERFORMANCE Hello, We are working on performance improvements while load testing the application, and I noticed that ResourceBundleMapWrapper uses arounbd 140 Ko per Serving thread, in our configuration with around 1000 thread, this is a big memory impact. I started investigating the class and code seems strange to me, in fact I don't understand why InternalRbmWrapper constructor copies creates a Map by copying content of ResourceBundle. Why not only have a reference and delegate calls to the ResourceBundle ? Furthermore since put methods throw RuntimeException, I really don't see any case where the Map will change. I made a test removing this code and delegating to resourceBundle and it seems OK. If someone knows why it was made like that I would really be interested, if there is no reason I will submit a patch Thank you Regards Philippe http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4220) Current implementation of UtilCache has a memory leak if maxInMemory is set
[ https://issues.apache.org/jira/browse/OFBIZ-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009332#comment-13009332 ] Philippe Mouawad commented on OFBIZ-4220: - Hello Erwan, I cannot answer to this question, I didn't follow very closely this library. If JUnit tests cover widely the class then there is no big risk , otherwise it would require more thorough testing. I can test with this last version if you want but it will only answer to the leak issue. Anyway issue is fixed even without upgrading. Regards Philippe Current implementation of UtilCache has a memory leak if maxInMemory is set --- Key: OFBIZ-4220 URL: https://issues.apache.org/jira/browse/OFBIZ-4220 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Environment: ALL Reporter: Philippe Mouawad Priority: Critical Labels: CACHE, LEAK, MEMORY Attachments: TestMemoryLeak.java, leak.png, patch-4220.patch If maxInMemory is set on caches, then current implementation will leak if many puts are done in cache. We made some load testing and current implementation ends very rapidly in an OutOfMemory. Philippe Mouawad http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (OFBIZ-4220) Current implementation of UtilCache has a memory leak
[ https://issues.apache.org/jira/browse/OFBIZ-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13008845#comment-13008845 ] Philippe Mouawad edited comment on OFBIZ-4220 at 3/20/11 3:54 PM: -- The main source for this leak is: ExecutionPool registration. Object retains lot of references to Caches that may be not be used anymore. I made a test with 256m affected , and ExecutionPool retains through 164 Mo in an array of 1134867 elements. I made a new test by commenting ExecutionPool.addPulse(line); in tryRegister and no OOM occurs. From my understanding: - ExecutionPool is used to collect elements in the Cache and handle expiry - ExecutionPoolPulseWorker runs in N threads to cleanup the queue , where N is the number of processors if I understand well I think issue comes from the fact that removed elements are still in Expiry Queue and in the test case PUT is too heavy (50 threads) while expiry threads are only 2. But this test case mimics what may happen in real life. Philippe http://www.ubik-ingenierie.com was (Author: p.moua...@ubik-ingenierie.com): There is another source for this leak in: ExecutionPool registration. Object retains lot of references to Caches that may be not be used anymore. Current implementation of UtilCache has a memory leak - Key: OFBIZ-4220 URL: https://issues.apache.org/jira/browse/OFBIZ-4220 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Environment: ALL Reporter: Philippe Mouawad Labels: CACHE, LEAK, MEMORY Attachments: TestMemoryLeak.java Hello, Since some time UtilCache has been updated to replace the WeakHashMap by a ConcurrentHashMap: private static final ConcurrentHashMapString, UtilCache?, ? utilCacheTable = new ConcurrentHashMapString, UtilCache?, ?(); I think this fix to concurrency issues has introduced a memory leak or at least a much bigger impact on Memory. Indeed descendent of AbstractCache (particularly AbstractEntityConditionCache, EntityListCache) tend to create many caches that do not need to always persist in time. The old WeakHashMap handled this by enabling them to disappear while today the Hard ref disables this. We made some load testing and current implementation ends with an OutOfMemory. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-4220) Current implementation of UtilCache has a memory leak
[ https://issues.apache.org/jira/browse/OFBIZ-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-4220: Attachment: patch-4220.patch Fix to the ExecutionPool leak. You can test its efficiency with provided TestMemoryLeak Philippe Mouawad http://www.ubik-ingenierie.com Current implementation of UtilCache has a memory leak - Key: OFBIZ-4220 URL: https://issues.apache.org/jira/browse/OFBIZ-4220 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Environment: ALL Reporter: Philippe Mouawad Labels: CACHE, LEAK, MEMORY Attachments: TestMemoryLeak.java, leak.png, patch-4220.patch Hello, Since some time UtilCache has been updated to replace the WeakHashMap by a ConcurrentHashMap: private static final ConcurrentHashMapString, UtilCache?, ? utilCacheTable = new ConcurrentHashMapString, UtilCache?, ?(); I think this fix to concurrency issues has introduced a memory leak or at least a much bigger impact on Memory. Indeed descendent of AbstractCache (particularly AbstractEntityConditionCache, EntityListCache) tend to create many caches that do not need to always persist in time. The old WeakHashMap handled this by enabling them to disappear while today the Hard ref disables this. We made some load testing and current implementation ends with an OutOfMemory. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4222) UtilCache has memory leak if many temporary caches are created
UtilCache has memory leak if many temporary caches are created -- Key: OFBIZ-4222 URL: https://issues.apache.org/jira/browse/OFBIZ-4222 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Since some time UtilCache has been updated to replace the WeakHashMap by a ConcurrentHashMap: private static final ConcurrentHashMapString, UtilCache?, ? utilCacheTable = new ConcurrentHashMapString, UtilCache?, ?(); I think this fix to concurrency issues has introduced a memory leak or at least a much bigger impact on Memory. Indeed descendent of AbstractCache (particularly AbstractEntityConditionCache, EntityListCache) tend to create many caches that do not need to always persist in time. The old WeakHashMap handled this by enabling them to disappear while today the Hard ref disables this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4220) Current implementation of UtilCache has a memory leak if maxInMemory is set
[ https://issues.apache.org/jira/browse/OFBIZ-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-4220: Priority: Critical (was: Major) Description: If maxInMemory is set on caches, then current implementation will leak if many puts are done in cache. We made some load testing and current implementation ends very rapidly in an OutOfMemory. Philippe Mouawad http://www.ubik-ingenierie.com was: Hello, Since some time UtilCache has been updated to replace the WeakHashMap by a ConcurrentHashMap: private static final ConcurrentHashMapString, UtilCache?, ? utilCacheTable = new ConcurrentHashMapString, UtilCache?, ?(); I think this fix to concurrency issues has introduced a memory leak or at least a much bigger impact on Memory. Indeed descendent of AbstractCache (particularly AbstractEntityConditionCache, EntityListCache) tend to create many caches that do not need to always persist in time. The old WeakHashMap handled this by enabling them to disappear while today the Hard ref disables this. We made some load testing and current implementation ends with an OutOfMemory. Summary: Current implementation of UtilCache has a memory leak if maxInMemory is set (was: Current implementation of UtilCache has a memory leak) Current implementation of UtilCache has a memory leak if maxInMemory is set --- Key: OFBIZ-4220 URL: https://issues.apache.org/jira/browse/OFBIZ-4220 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Environment: ALL Reporter: Philippe Mouawad Priority: Critical Labels: CACHE, LEAK, MEMORY Attachments: TestMemoryLeak.java, leak.png, patch-4220.patch If maxInMemory is set on caches, then current implementation will leak if many puts are done in cache. We made some load testing and current implementation ends very rapidly in an OutOfMemory. Philippe Mouawad http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (OFBIZ-4220) Current implementation of UtilCache has a memory leak
Current implementation of UtilCache has a memory leak - Key: OFBIZ-4220 URL: https://issues.apache.org/jira/browse/OFBIZ-4220 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Environment: ALL Reporter: Philippe Mouawad Hello, Since some time UtilCache has been updated to replace the WeakHashMap by a ConcurrentHashMap: private static final ConcurrentHashMapString, UtilCache?, ? utilCacheTable = new ConcurrentHashMapString, UtilCache?, ?(); I think this fix to concurrency issues has introduced a memory leak or at least a much bigger impact on Memory. Indeed descendent of AbstractCache (particularly AbstractEntityConditionCache, EntityListCache) tend to create many caches that do not need to always persist in time. The old WeakHashMap handled this by enabling them to disappear while today the Hard ref disables this. We made some load testing and current implementation ends with an OutOfMemory. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-4220) Current implementation of UtilCache has a memory leak
[ https://issues.apache.org/jira/browse/OFBIZ-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-4220: Attachment: patch_OFBIZ-4220.patch Fix to the issue Philippe http://www.ubik-ingenierie.com Current implementation of UtilCache has a memory leak - Key: OFBIZ-4220 URL: https://issues.apache.org/jira/browse/OFBIZ-4220 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Environment: ALL Reporter: Philippe Mouawad Labels: CACHE, LEAK, MEMORY Attachments: patch_OFBIZ-4220.patch Hello, Since some time UtilCache has been updated to replace the WeakHashMap by a ConcurrentHashMap: private static final ConcurrentHashMapString, UtilCache?, ? utilCacheTable = new ConcurrentHashMapString, UtilCache?, ?(); I think this fix to concurrency issues has introduced a memory leak or at least a much bigger impact on Memory. Indeed descendent of AbstractCache (particularly AbstractEntityConditionCache, EntityListCache) tend to create many caches that do not need to always persist in time. The old WeakHashMap handled this by enabling them to disappear while today the Hard ref disables this. We made some load testing and current implementation ends with an OutOfMemory. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-4220) Current implementation of UtilCache has a memory leak
[ https://issues.apache.org/jira/browse/OFBIZ-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-4220: Attachment: (was: patch_OFBIZ-4220.patch) Current implementation of UtilCache has a memory leak - Key: OFBIZ-4220 URL: https://issues.apache.org/jira/browse/OFBIZ-4220 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Environment: ALL Reporter: Philippe Mouawad Labels: CACHE, LEAK, MEMORY Hello, Since some time UtilCache has been updated to replace the WeakHashMap by a ConcurrentHashMap: private static final ConcurrentHashMapString, UtilCache?, ? utilCacheTable = new ConcurrentHashMapString, UtilCache?, ?(); I think this fix to concurrency issues has introduced a memory leak or at least a much bigger impact on Memory. Indeed descendent of AbstractCache (particularly AbstractEntityConditionCache, EntityListCache) tend to create many caches that do not need to always persist in time. The old WeakHashMap handled this by enabling them to disappear while today the Hard ref disables this. We made some load testing and current implementation ends with an OutOfMemory. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-4220) Current implementation of UtilCache has a memory leak
[ https://issues.apache.org/jira/browse/OFBIZ-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-4220: Comment: was deleted (was: Fix to the issue Philippe http://www.ubik-ingenierie.com) Current implementation of UtilCache has a memory leak - Key: OFBIZ-4220 URL: https://issues.apache.org/jira/browse/OFBIZ-4220 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Environment: ALL Reporter: Philippe Mouawad Labels: CACHE, LEAK, MEMORY Hello, Since some time UtilCache has been updated to replace the WeakHashMap by a ConcurrentHashMap: private static final ConcurrentHashMapString, UtilCache?, ? utilCacheTable = new ConcurrentHashMapString, UtilCache?, ?(); I think this fix to concurrency issues has introduced a memory leak or at least a much bigger impact on Memory. Indeed descendent of AbstractCache (particularly AbstractEntityConditionCache, EntityListCache) tend to create many caches that do not need to always persist in time. The old WeakHashMap handled this by enabling them to disappear while today the Hard ref disables this. We made some load testing and current implementation ends with an OutOfMemory. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OFBIZ-4220) Current implementation of UtilCache has a memory leak
[ https://issues.apache.org/jira/browse/OFBIZ-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13008845#comment-13008845 ] Philippe Mouawad commented on OFBIZ-4220: - There is another source for this leak in: ExecutionPool registration. Object retains lot of references to Caches that may be not be used anymore. Current implementation of UtilCache has a memory leak - Key: OFBIZ-4220 URL: https://issues.apache.org/jira/browse/OFBIZ-4220 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Environment: ALL Reporter: Philippe Mouawad Labels: CACHE, LEAK, MEMORY Hello, Since some time UtilCache has been updated to replace the WeakHashMap by a ConcurrentHashMap: private static final ConcurrentHashMapString, UtilCache?, ? utilCacheTable = new ConcurrentHashMapString, UtilCache?, ?(); I think this fix to concurrency issues has introduced a memory leak or at least a much bigger impact on Memory. Indeed descendent of AbstractCache (particularly AbstractEntityConditionCache, EntityListCache) tend to create many caches that do not need to always persist in time. The old WeakHashMap handled this by enabling them to disappear while today the Hard ref disables this. We made some load testing and current implementation ends with an OutOfMemory. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-4220) Current implementation of UtilCache has a memory leak
[ https://issues.apache.org/jira/browse/OFBIZ-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-4220: Attachment: TestMemoryLeak.java Test case that reproduces the issue Current implementation of UtilCache has a memory leak - Key: OFBIZ-4220 URL: https://issues.apache.org/jira/browse/OFBIZ-4220 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Environment: ALL Reporter: Philippe Mouawad Labels: CACHE, LEAK, MEMORY Attachments: TestMemoryLeak.java Hello, Since some time UtilCache has been updated to replace the WeakHashMap by a ConcurrentHashMap: private static final ConcurrentHashMapString, UtilCache?, ? utilCacheTable = new ConcurrentHashMapString, UtilCache?, ?(); I think this fix to concurrency issues has introduced a memory leak or at least a much bigger impact on Memory. Indeed descendent of AbstractCache (particularly AbstractEntityConditionCache, EntityListCache) tend to create many caches that do not need to always persist in time. The old WeakHashMap handled this by enabling them to disappear while today the Hard ref disables this. We made some load testing and current implementation ends with an OutOfMemory. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (OFBIZ-4103) missCountExpired and missCountExpired always equal to 0 in UtilCache
missCountExpired and missCountExpired always equal to 0 in UtilCache Key: OFBIZ-4103 URL: https://issues.apache.org/jira/browse/OFBIZ-4103 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Working on new Cache implementation plugin, I noticed these 2 fields are never modified. I plan to remove them in the new Cache interface and administration interface is it a problem ? Thank you Regards Philippe -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-4098) Ability to plug a new Cache Implementation
[ https://issues.apache.org/jira/browse/OFBIZ-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-4098: Attachment: patch-4098.patch Here is the patch that enable providing an alternative Cache implementation. I modified only on thing in JUnit test case, I added assertSame to make it compare through equals instead of references, because UtilCache is now only a Facade to real cache. Ability to plug a new Cache Implementation -- Key: OFBIZ-4098 URL: https://issues.apache.org/jira/browse/OFBIZ-4098 Project: OFBiz Issue Type: New Feature Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Attachments: patch-4098.patch Original Estimate: 96h Remaining Estimate: 96h Hello, I would like to contribute a patch to enable switching from Ofbiz native Cache (today UtilCache) to another implementation like EhCache for example. To avoid big code impacts, UtilCache would stay the same and delegate to the real cache implementation this will impact less classes and big impacts would stay in UtilCache package. Ability to plug another implementation like EhCache for example would enable easily plugin with Terracota for example which on big Web Site gives much performance enhancements. Is the format to contribute this kind of evolution also a patch ? Thank you Regards Philippe http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (OFBIZ-4098) Ability to plug a new Cache Implementation
[ https://issues.apache.org/jira/browse/OFBIZ-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12979354#action_12979354 ] Philippe Mouawad edited comment on OFBIZ-4098 at 1/9/11 11:28 AM: -- Hello, Here is the patch that enables providing an alternative Cache implementation, setup is done in CacheManagerFactory and defaults to ofbiz. So current behaviour is exactly the same as before but refactoring was done to ease new Implementation plugin. I modified only on thing in JUnit test case, I added assertSame to make it compare through equals instead of references, because UtilCache is now only a Facade to real cache. I will provide within a week EhCache implementation provided you agree with this first step. Philippe Mouawad http://www.ubik-ingenierie.com was (Author: pmouawad): Here is the patch that enable providing an alternative Cache implementation. I modified only on thing in JUnit test case, I added assertSame to make it compare through equals instead of references, because UtilCache is now only a Facade to real cache. Ability to plug a new Cache Implementation -- Key: OFBIZ-4098 URL: https://issues.apache.org/jira/browse/OFBIZ-4098 Project: OFBiz Issue Type: New Feature Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Attachments: patch-4098.patch Original Estimate: 96h Remaining Estimate: 96h Hello, I would like to contribute a patch to enable switching from Ofbiz native Cache (today UtilCache) to another implementation like EhCache for example. To avoid big code impacts, UtilCache would stay the same and delegate to the real cache implementation this will impact less classes and big impacts would stay in UtilCache package. Ability to plug another implementation like EhCache for example would enable easily plugin with Terracota for example which on big Web Site gives much performance enhancements. Is the format to contribute this kind of evolution also a patch ? Thank you Regards Philippe http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-4099) Is UtilCache#getNextDefaultIndex() mechanism useful
[ https://issues.apache.org/jira/browse/OFBIZ-4099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-4099: Attachment: ofbiz-4098.patch Here is it again with issue on classpath fixed. Is UtilCache#getNextDefaultIndex() mechanism useful --- Key: OFBIZ-4099 URL: https://issues.apache.org/jira/browse/OFBIZ-4099 Project: OFBiz Issue Type: Sub-task Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Original Estimate: 1h Remaining Estimate: 1h Hello, I don't understand the use of getNextDefaultIndex inside UtilCache, it seems to me a bit dangerous and useless to append to a cache name an index without the client being aware of this. Do you know why this feature exists and if it is really useful ? Thank you Philippe http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-4099) Is UtilCache#getNextDefaultIndex() mechanism useful
[ https://issues.apache.org/jira/browse/OFBIZ-4099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-4099: Attachment: (was: ofbiz-4098.patch) Is UtilCache#getNextDefaultIndex() mechanism useful --- Key: OFBIZ-4099 URL: https://issues.apache.org/jira/browse/OFBIZ-4099 Project: OFBiz Issue Type: Sub-task Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Original Estimate: 1h Remaining Estimate: 1h Hello, I don't understand the use of getNextDefaultIndex inside UtilCache, it seems to me a bit dangerous and useless to append to a cache name an index without the client being aware of this. Do you know why this feature exists and if it is really useful ? Thank you Philippe http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-4098) Ability to plug a new Cache Implementation
[ https://issues.apache.org/jira/browse/OFBIZ-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-4098: Attachment: (was: patch-4098.patch) Ability to plug a new Cache Implementation -- Key: OFBIZ-4098 URL: https://issues.apache.org/jira/browse/OFBIZ-4098 Project: OFBiz Issue Type: New Feature Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Original Estimate: 96h Remaining Estimate: 96h Hello, I would like to contribute a patch to enable switching from Ofbiz native Cache (today UtilCache) to another implementation like EhCache for example. To avoid big code impacts, UtilCache would stay the same and delegate to the real cache implementation this will impact less classes and big impacts would stay in UtilCache package. Ability to plug another implementation like EhCache for example would enable easily plugin with Terracota for example which on big Web Site gives much performance enhancements. Is the format to contribute this kind of evolution also a patch ? Thank you Regards Philippe http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-4098) Ability to plug a new Cache Implementation
[ https://issues.apache.org/jira/browse/OFBIZ-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-4098: Attachment: ofbiz-4098.patch With issue on classpath formatting fixed I hope. Ability to plug a new Cache Implementation -- Key: OFBIZ-4098 URL: https://issues.apache.org/jira/browse/OFBIZ-4098 Project: OFBiz Issue Type: New Feature Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Attachments: ofbiz-4098.patch Original Estimate: 96h Remaining Estimate: 96h Hello, I would like to contribute a patch to enable switching from Ofbiz native Cache (today UtilCache) to another implementation like EhCache for example. To avoid big code impacts, UtilCache would stay the same and delegate to the real cache implementation this will impact less classes and big impacts would stay in UtilCache package. Ability to plug another implementation like EhCache for example would enable easily plugin with Terracota for example which on big Web Site gives much performance enhancements. Is the format to contribute this kind of evolution also a patch ? Thank you Regards Philippe http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-4098) Ability to plug a new Cache Implementation
[ https://issues.apache.org/jira/browse/OFBIZ-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-4098: Attachment: (was: ofbiz-4098.patch) Ability to plug a new Cache Implementation -- Key: OFBIZ-4098 URL: https://issues.apache.org/jira/browse/OFBIZ-4098 Project: OFBiz Issue Type: New Feature Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Original Estimate: 96h Remaining Estimate: 96h Hello, I would like to contribute a patch to enable switching from Ofbiz native Cache (today UtilCache) to another implementation like EhCache for example. To avoid big code impacts, UtilCache would stay the same and delegate to the real cache implementation this will impact less classes and big impacts would stay in UtilCache package. Ability to plug another implementation like EhCache for example would enable easily plugin with Terracota for example which on big Web Site gives much performance enhancements. Is the format to contribute this kind of evolution also a patch ? Thank you Regards Philippe http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-4098) Ability to plug a new Cache Implementation
[ https://issues.apache.org/jira/browse/OFBIZ-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-4098: Attachment: ofbiz-4098.patch The good version. Ability to plug a new Cache Implementation -- Key: OFBIZ-4098 URL: https://issues.apache.org/jira/browse/OFBIZ-4098 Project: OFBiz Issue Type: New Feature Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Attachments: ofbiz-4098.patch Original Estimate: 96h Remaining Estimate: 96h Hello, I would like to contribute a patch to enable switching from Ofbiz native Cache (today UtilCache) to another implementation like EhCache for example. To avoid big code impacts, UtilCache would stay the same and delegate to the real cache implementation this will impact less classes and big impacts would stay in UtilCache package. Ability to plug another implementation like EhCache for example would enable easily plugin with Terracota for example which on big Web Site gives much performance enhancements. Is the format to contribute this kind of evolution also a patch ? Thank you Regards Philippe http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4098) Ability to plug a new Cache Implementation
[ https://issues.apache.org/jira/browse/OFBIZ-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12979371#action_12979371 ] Philippe Mouawad commented on OFBIZ-4098: - Yes It would be better but it would impact thousands of Ofbiz classes. Had I started it from scratch I would have done it as you suggest but now it is too impacting. Thank you Regards Philippe Ability to plug a new Cache Implementation -- Key: OFBIZ-4098 URL: https://issues.apache.org/jira/browse/OFBIZ-4098 Project: OFBiz Issue Type: New Feature Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Attachments: ofbiz-4098.patch Original Estimate: 96h Remaining Estimate: 96h Hello, I would like to contribute a patch to enable switching from Ofbiz native Cache (today UtilCache) to another implementation like EhCache for example. To avoid big code impacts, UtilCache would stay the same and delegate to the real cache implementation this will impact less classes and big impacts would stay in UtilCache package. Ability to plug another implementation like EhCache for example would enable easily plugin with Terracota for example which on big Web Site gives much performance enhancements. Is the format to contribute this kind of evolution also a patch ? Thank you Regards Philippe http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-4103) missCountExpired and missCountSoftRef always equal to 0 in UtilCache
[ https://issues.apache.org/jira/browse/OFBIZ-4103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-4103: Summary: missCountExpired and missCountSoftRef always equal to 0 in UtilCache (was: missCountExpired and missCountExpired always equal to 0 in UtilCache) missCountExpired and missCountSoftRef always equal to 0 in UtilCache Key: OFBIZ-4103 URL: https://issues.apache.org/jira/browse/OFBIZ-4103 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Working on new Cache implementation plugin, I noticed these 2 fields are never modified. I plan to remove them in the new Cache interface and administration interface is it a problem ? Thank you Regards Philippe -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-4098) Ability to plug a new Cache Implementation
Ability to plug a new Cache Implementation -- Key: OFBIZ-4098 URL: https://issues.apache.org/jira/browse/OFBIZ-4098 Project: OFBiz Issue Type: New Feature Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Hello, I would like to contribute a patch to enable switching from Ofbiz native Cache (today UtilCache) to another implementation like EhCache for example. To avoid big code impacts, UtilCache would stay the same and delegate to the real cache implementation this will impact less classes and big impacts would stay in UtilCache package. Ability to plug another implementation like EhCache for example would enable easily plugin with Terracota for example which on big Web Site gives much performance enhancements. Is the format to contribute this kind of evolution also a patch ? Thank you Regards Philippe http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4098) Ability to plug a new Cache Implementation
[ https://issues.apache.org/jira/browse/OFBIZ-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12979123#action_12979123 ] Philippe Mouawad commented on OFBIZ-4098: - Hello, Thank you for your answer. Here are the features I have seen until now that cannot be ported: - Soft references as you said and associated webtools update features - Putting null keys unless I use JSR Cache, do you know if it's an important feature ? - The feature mentionned in Subtask (but I am not sure it is useful) Regards Philippe http://www.ubik-ingenierie.com Ability to plug a new Cache Implementation -- Key: OFBIZ-4098 URL: https://issues.apache.org/jira/browse/OFBIZ-4098 Project: OFBiz Issue Type: New Feature Components: framework Affects Versions: SVN trunk Reporter: Philippe Mouawad Original Estimate: 96h Remaining Estimate: 96h Hello, I would like to contribute a patch to enable switching from Ofbiz native Cache (today UtilCache) to another implementation like EhCache for example. To avoid big code impacts, UtilCache would stay the same and delegate to the real cache implementation this will impact less classes and big impacts would stay in UtilCache package. Ability to plug another implementation like EhCache for example would enable easily plugin with Terracota for example which on big Web Site gives much performance enhancements. Is the format to contribute this kind of evolution also a patch ? Thank you Regards Philippe http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2353) SequenceUtil may generate duplicate IDs in Load Balancing mode
[ https://issues.apache.org/jira/browse/OFBIZ-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12777935#action_12777935 ] Philippe Mouawad commented on OFBIZ-2353: - Hello M. Le Roux, I had no time to handle this issue. Philippe. SequenceUtil may generate duplicate IDs in Load Balancing mode --- Key: OFBIZ-2353 URL: https://issues.apache.org/jira/browse/OFBIZ-2353 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 4.0, Release Branch 9.04, SVN trunk Reporter: Philippe Mouawad Priority: Critical If Ofbiz is deploy on 2 servers in Load Balancing Mode SequenceUtil will generate duplicate IDs because synchronization is done at JVM level instead of doing it in DB. A good replacement implementation would be: org.hibernate.id.enhanced.TableGenerator But it would involve a dependency on Hibernate Philippe www.ubik-ingenierie.com -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2599) Memory leak due to transaction management
[ https://issues.apache.org/jira/browse/OFBIZ-2599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12777936#action_12777936 ] Philippe Mouawad commented on OFBIZ-2599: - Thanks for taking my patch into account Philippe Mouawad http://www.ubik-ingenierie.com Memory leak due to transaction management - Key: OFBIZ-2599 URL: https://issues.apache.org/jira/browse/OFBIZ-2599 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 9.04, SVN trunk Environment: jdk5, commons-dbcp-head Reporter: Philippe Mouawad Assignee: Jacques Le Roux Priority: Critical Fix For: Release Branch 9.04, SVN trunk Attachments: commons-dbcp-1.3-r674758-patched.jar, memory.png, patch-DBCPConneectionFactory.txt Hello, We are been using Ofbiz with DBCP based implementation. Ofbiz uses a Head revision of DBCP (package org.apache.commons.dbcp.managed is the same as current TRUNK) and geronimo-transaction-1.0. We are having recurrent OutOfMemory which occur on a 2 days basis. See: https://issues.apache.org/jira/browse/DBCP-294 Philippe Mouawad http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2124) Ofbiz freeze
[ https://issues.apache.org/jira/browse/OFBIZ-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12777938#action_12777938 ] Philippe Mouawad commented on OFBIZ-2124: - Hello M. Le Roux, Do you think the patch will be applied soon ? Philippe Mouawad http://www.ubik-ingenierie.com Ofbiz freeze Key: OFBIZ-2124 URL: https://issues.apache.org/jira/browse/OFBIZ-2124 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Environment: JDK5 1.5.0_15-b04, Linux Reporter: Philippe Mouawad Assignee: Jacques Le Roux Priority: Critical Fix For: SVN trunk Attachments: OFBIZ-2124_Ofbiz_freeze.patch, patch-Freeze-to-Trunk.patch, ThreadDumps.zip In a certain scenario the application freezes, no more AJP connector thread are available. I attach 5 Thread dump done after the freeze -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-2636) Performance ISSUE in ModelServiceReader due to Too Coarse synchronization
Performance ISSUE in ModelServiceReader due to Too Coarse synchronization - Key: OFBIZ-2636 URL: https://issues.apache.org/jira/browse/OFBIZ-2636 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 4.0, Release Branch 9.04, SVN trunk Reporter: Philippe Mouawad In production, we monitor Thread Contention and have noticed big contention point in org.ofbiz.service.ModelServiceReader.getModelServices -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-2636) Performance ISSUE in ModelServiceReader due to Too Coarse synchronization
[ https://issues.apache.org/jira/browse/OFBIZ-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-2636: Attachment: thread_contention.txt Philippe Mouawad http://www.ubik-ingenierie.com Performance ISSUE in ModelServiceReader due to Too Coarse synchronization - Key: OFBIZ-2636 URL: https://issues.apache.org/jira/browse/OFBIZ-2636 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 4.0, Release Branch 9.04, SVN trunk Reporter: Philippe Mouawad Attachments: thread_contention.txt In production, we monitor Thread Contention and have noticed big contention point in org.ofbiz.service.ModelServiceReader.getModelServices -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-2599) Memory leak due to transaction management
[ https://issues.apache.org/jira/browse/OFBIZ-2599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-2599: Attachment: patch-DBCPConneectionFactory.txt Patch that relies on new commons-dbcp PoolableManagedConnectionFactory. Needs commons-dbcp trunk after project has taken into account patch to bug: https://issues.apache.org/jira/browse/DBCP-294 Memory leak due to transaction management - Key: OFBIZ-2599 URL: https://issues.apache.org/jira/browse/OFBIZ-2599 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 9.04, SVN trunk Environment: jdk5, commons-dbcp-head Reporter: Philippe Mouawad Priority: Critical Attachments: patch-DBCPConneectionFactory.txt Hello, We are been using Ofbiz with DBCP based implementation. Ofbiz uses a Head revision of DBCP (package org.apache.commons.dbcp.managed is the same as current TRUNK) and geronimo-transaction-1.0. We are having recurrent OutOfMemory which occur on a 2 days basis. See: https://issues.apache.org/jira/browse/DBCP-294 Philippe Mouawad http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-2599) Memory leak due to transaction management
Memory leak due to transaction management - Key: OFBIZ-2599 URL: https://issues.apache.org/jira/browse/OFBIZ-2599 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 9.04, SVN trunk Environment: jdk5, commons-dbcp-head Reporter: Philippe Mouawad Priority: Critical Hello, We are been using Ofbiz with DBCP based implementation. Ofbiz uses a Head revision of DBCP (package org.apache.commons.dbcp.managed is the same as current TRUNK) and geronimo-transaction-1.0. We are having recurrent OutOfMemory which occur on a 2 days basis. See: https://issues.apache.org/jira/browse/DBCP-294 Philippe Mouawad http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OFBIZ-2315) TransactionUtil : 3 Map corruptions related to mis synchronization
[ https://issues.apache.org/jira/browse/OFBIZ-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad resolved OFBIZ-2315. - Resolution: Fixed Fix Version/s: SVN trunk TransactionUtil : 3 Map corruptions related to mis synchronization -- Key: OFBIZ-2315 URL: https://issues.apache.org/jira/browse/OFBIZ-2315 Project: OFBiz Issue Type: Bug Affects Versions: Release Branch 4.0, SVN trunk Reporter: Philippe Mouawad Fix For: SVN trunk Attachments: ContentionLog.txt, patch-TransactionUtil.patch Randomly we are having Thread contention problems in production related to synchronization issues in this class. See attached log file. As you can see, a lot of threads are locked by some code called by TransactionUtil.setTransactionBeginStack that has been running for 180165 ms : Thread[default-invoker-Thread-4582999,5,main]:4590333, stackTrace: javolution.util.FastMap.mapEntry(Unknown Source) javolution.util.FastMap.access$1200(Unknown Source) javolution.util.FastMap$3.run(Unknown Source) javax.realtime.MemoryArea.executeInArea(Unknown Source) javolution.util.FastMap.resizeTable(Unknown Source) javolution.util.FastMap.mapEntry(Unknown Source) javolution.util.FastMap.addEntry(Unknown Source) javolution.util.FastMap.put(Unknown Source) org.ofbiz.entity.transaction.TransactionUtil.setTransactionBeginStack(TransactionUtil.java:657) org.ofbiz.entity.transaction.TransactionUtil.setTransactionBeginStack(TransactionUtil.java:646) org.ofbiz.entity.transaction.TransactionUtil.begin(TransactionUtil.java:135) org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:297) org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:208) org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:149) org.ofbiz.service.job.GenericServiceJob.exec(GenericServiceJob.java:69) org.ofbiz.service.job.JobInvoker.run(JobInvoker.java:240) java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2315) TransactionUtil : 3 Map corruptions related to mis synchronization
[ https://issues.apache.org/jira/browse/OFBIZ-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12714862#action_12714862 ] Philippe Mouawad commented on OFBIZ-2315: - Hello M. Le Roux, I confirm they have fixed the problems. Can you look at other issues I submitted and the patches. I also confirm that all the patches I submitted have been tested successfully in production. Philippe www.ubik-ingenierie.com TransactionUtil : 3 Map corruptions related to mis synchronization -- Key: OFBIZ-2315 URL: https://issues.apache.org/jira/browse/OFBIZ-2315 Project: OFBiz Issue Type: Bug Affects Versions: Release Branch 4.0, SVN trunk Reporter: Philippe Mouawad Fix For: SVN trunk Attachments: ContentionLog.txt, patch-TransactionUtil.patch Randomly we are having Thread contention problems in production related to synchronization issues in this class. See attached log file. As you can see, a lot of threads are locked by some code called by TransactionUtil.setTransactionBeginStack that has been running for 180165 ms : Thread[default-invoker-Thread-4582999,5,main]:4590333, stackTrace: javolution.util.FastMap.mapEntry(Unknown Source) javolution.util.FastMap.access$1200(Unknown Source) javolution.util.FastMap$3.run(Unknown Source) javax.realtime.MemoryArea.executeInArea(Unknown Source) javolution.util.FastMap.resizeTable(Unknown Source) javolution.util.FastMap.mapEntry(Unknown Source) javolution.util.FastMap.addEntry(Unknown Source) javolution.util.FastMap.put(Unknown Source) org.ofbiz.entity.transaction.TransactionUtil.setTransactionBeginStack(TransactionUtil.java:657) org.ofbiz.entity.transaction.TransactionUtil.setTransactionBeginStack(TransactionUtil.java:646) org.ofbiz.entity.transaction.TransactionUtil.begin(TransactionUtil.java:135) org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:297) org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:208) org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:149) org.ofbiz.service.job.GenericServiceJob.exec(GenericServiceJob.java:69) org.ofbiz.service.job.JobInvoker.run(JobInvoker.java:240) java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-2353) SequenceUtil may generate duplicate IDs in Load Balancing mode
SequenceUtil may generate duplicate IDs in Load Balancing mode --- Key: OFBIZ-2353 URL: https://issues.apache.org/jira/browse/OFBIZ-2353 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 4.0, Release Branch 9.04, SVN trunk Reporter: Philippe Mouawad Priority: Critical If Ofbiz is deploy on 2 servers in Load Balancing Mode SequenceUtil will generate duplicate IDs because synchronization is done at JVM level instead of doing it in DB. A good replacement implementation would be: org.hibernate.id.enhanced.TableGenerator But it would involve a dependency on Hibernate Philippe www.ubik-ingenierie.com -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-2315) TransactionUtil : 3 Map corruptions related to mis synchronization
TransactionUtil : 3 Map corruptions related to mis synchronization -- Key: OFBIZ-2315 URL: https://issues.apache.org/jira/browse/OFBIZ-2315 Project: OFBiz Issue Type: Bug Affects Versions: Release Branch 4.0, SVN trunk Reporter: Philippe Mouawad Randomly we are having Thread contention problems in production related to synchronization issues in this class. See attached log file. As you can see, a lot of threads are locked by some code called by TransactionUtil.setTransactionBeginStack that has been running for 180165 ms : Thread[default-invoker-Thread-4582999,5,main]:4590333, stackTrace: javolution.util.FastMap.mapEntry(Unknown Source) javolution.util.FastMap.access$1200(Unknown Source) javolution.util.FastMap$3.run(Unknown Source) javax.realtime.MemoryArea.executeInArea(Unknown Source) javolution.util.FastMap.resizeTable(Unknown Source) javolution.util.FastMap.mapEntry(Unknown Source) javolution.util.FastMap.addEntry(Unknown Source) javolution.util.FastMap.put(Unknown Source) org.ofbiz.entity.transaction.TransactionUtil.setTransactionBeginStack(TransactionUtil.java:657) org.ofbiz.entity.transaction.TransactionUtil.setTransactionBeginStack(TransactionUtil.java:646) org.ofbiz.entity.transaction.TransactionUtil.begin(TransactionUtil.java:135) org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:297) org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:208) org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:149) org.ofbiz.service.job.GenericServiceJob.exec(GenericServiceJob.java:69) org.ofbiz.service.job.JobInvoker.run(JobInvoker.java:240) java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-2315) TransactionUtil : 3 Map corruptions related to mis synchronization
[ https://issues.apache.org/jira/browse/OFBIZ-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-2315: Attachment: ContentionLog.txt Contention log TransactionUtil : 3 Map corruptions related to mis synchronization -- Key: OFBIZ-2315 URL: https://issues.apache.org/jira/browse/OFBIZ-2315 Project: OFBiz Issue Type: Bug Affects Versions: Release Branch 4.0, SVN trunk Reporter: Philippe Mouawad Attachments: ContentionLog.txt Randomly we are having Thread contention problems in production related to synchronization issues in this class. See attached log file. As you can see, a lot of threads are locked by some code called by TransactionUtil.setTransactionBeginStack that has been running for 180165 ms : Thread[default-invoker-Thread-4582999,5,main]:4590333, stackTrace: javolution.util.FastMap.mapEntry(Unknown Source) javolution.util.FastMap.access$1200(Unknown Source) javolution.util.FastMap$3.run(Unknown Source) javax.realtime.MemoryArea.executeInArea(Unknown Source) javolution.util.FastMap.resizeTable(Unknown Source) javolution.util.FastMap.mapEntry(Unknown Source) javolution.util.FastMap.addEntry(Unknown Source) javolution.util.FastMap.put(Unknown Source) org.ofbiz.entity.transaction.TransactionUtil.setTransactionBeginStack(TransactionUtil.java:657) org.ofbiz.entity.transaction.TransactionUtil.setTransactionBeginStack(TransactionUtil.java:646) org.ofbiz.entity.transaction.TransactionUtil.begin(TransactionUtil.java:135) org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:297) org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:208) org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:149) org.ofbiz.service.job.GenericServiceJob.exec(GenericServiceJob.java:69) org.ofbiz.service.job.JobInvoker.run(JobInvoker.java:240) java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2315) TransactionUtil : 3 Map corruptions related to mis synchronization
[ https://issues.apache.org/jira/browse/OFBIZ-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12700153#action_12700153 ] Philippe Mouawad commented on OFBIZ-2315: - After analysis, we can see that 2 maps : - allThreadsTransactionBeginStack - allThreadsTransactionBeginStackSave Are not synchronized and can be accessed (corrupted) from non synchronized blocks. This IMHO provokes corruption of FastMap and explains why the FastMap.resizeTable has been running for so long. TransactionUtil : 3 Map corruptions related to mis synchronization -- Key: OFBIZ-2315 URL: https://issues.apache.org/jira/browse/OFBIZ-2315 Project: OFBiz Issue Type: Bug Affects Versions: Release Branch 4.0, SVN trunk Reporter: Philippe Mouawad Attachments: ContentionLog.txt Randomly we are having Thread contention problems in production related to synchronization issues in this class. See attached log file. As you can see, a lot of threads are locked by some code called by TransactionUtil.setTransactionBeginStack that has been running for 180165 ms : Thread[default-invoker-Thread-4582999,5,main]:4590333, stackTrace: javolution.util.FastMap.mapEntry(Unknown Source) javolution.util.FastMap.access$1200(Unknown Source) javolution.util.FastMap$3.run(Unknown Source) javax.realtime.MemoryArea.executeInArea(Unknown Source) javolution.util.FastMap.resizeTable(Unknown Source) javolution.util.FastMap.mapEntry(Unknown Source) javolution.util.FastMap.addEntry(Unknown Source) javolution.util.FastMap.put(Unknown Source) org.ofbiz.entity.transaction.TransactionUtil.setTransactionBeginStack(TransactionUtil.java:657) org.ofbiz.entity.transaction.TransactionUtil.setTransactionBeginStack(TransactionUtil.java:646) org.ofbiz.entity.transaction.TransactionUtil.begin(TransactionUtil.java:135) org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:297) org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:208) org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:149) org.ofbiz.service.job.GenericServiceJob.exec(GenericServiceJob.java:69) org.ofbiz.service.job.JobInvoker.run(JobInvoker.java:240) java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-2315) TransactionUtil : 3 Map corruptions related to mis synchronization
[ https://issues.apache.org/jira/browse/OFBIZ-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-2315: Attachment: patch-TransactionUtil.patch Patch to TransactionUtil , ofbiz-trunk revision: 765951 TransactionUtil : 3 Map corruptions related to mis synchronization -- Key: OFBIZ-2315 URL: https://issues.apache.org/jira/browse/OFBIZ-2315 Project: OFBiz Issue Type: Bug Affects Versions: Release Branch 4.0, SVN trunk Reporter: Philippe Mouawad Attachments: ContentionLog.txt, patch-TransactionUtil.patch Randomly we are having Thread contention problems in production related to synchronization issues in this class. See attached log file. As you can see, a lot of threads are locked by some code called by TransactionUtil.setTransactionBeginStack that has been running for 180165 ms : Thread[default-invoker-Thread-4582999,5,main]:4590333, stackTrace: javolution.util.FastMap.mapEntry(Unknown Source) javolution.util.FastMap.access$1200(Unknown Source) javolution.util.FastMap$3.run(Unknown Source) javax.realtime.MemoryArea.executeInArea(Unknown Source) javolution.util.FastMap.resizeTable(Unknown Source) javolution.util.FastMap.mapEntry(Unknown Source) javolution.util.FastMap.addEntry(Unknown Source) javolution.util.FastMap.put(Unknown Source) org.ofbiz.entity.transaction.TransactionUtil.setTransactionBeginStack(TransactionUtil.java:657) org.ofbiz.entity.transaction.TransactionUtil.setTransactionBeginStack(TransactionUtil.java:646) org.ofbiz.entity.transaction.TransactionUtil.begin(TransactionUtil.java:135) org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:297) org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:208) org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:149) org.ofbiz.service.job.GenericServiceJob.exec(GenericServiceJob.java:69) org.ofbiz.service.job.JobInvoker.run(JobInvoker.java:240) java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2315) TransactionUtil : 3 Map corruptions related to mis synchronization
[ https://issues.apache.org/jira/browse/OFBIZ-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12700158#action_12700158 ] Philippe Mouawad commented on OFBIZ-2315: - Notice other synchronization problem on debugResMap. TransactionUtil : 3 Map corruptions related to mis synchronization -- Key: OFBIZ-2315 URL: https://issues.apache.org/jira/browse/OFBIZ-2315 Project: OFBiz Issue Type: Bug Affects Versions: Release Branch 4.0, SVN trunk Reporter: Philippe Mouawad Attachments: ContentionLog.txt, patch-TransactionUtil.patch Randomly we are having Thread contention problems in production related to synchronization issues in this class. See attached log file. As you can see, a lot of threads are locked by some code called by TransactionUtil.setTransactionBeginStack that has been running for 180165 ms : Thread[default-invoker-Thread-4582999,5,main]:4590333, stackTrace: javolution.util.FastMap.mapEntry(Unknown Source) javolution.util.FastMap.access$1200(Unknown Source) javolution.util.FastMap$3.run(Unknown Source) javax.realtime.MemoryArea.executeInArea(Unknown Source) javolution.util.FastMap.resizeTable(Unknown Source) javolution.util.FastMap.mapEntry(Unknown Source) javolution.util.FastMap.addEntry(Unknown Source) javolution.util.FastMap.put(Unknown Source) org.ofbiz.entity.transaction.TransactionUtil.setTransactionBeginStack(TransactionUtil.java:657) org.ofbiz.entity.transaction.TransactionUtil.setTransactionBeginStack(TransactionUtil.java:646) org.ofbiz.entity.transaction.TransactionUtil.begin(TransactionUtil.java:135) org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:297) org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:208) org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:149) org.ofbiz.service.job.GenericServiceJob.exec(GenericServiceJob.java:69) org.ofbiz.service.job.JobInvoker.run(JobInvoker.java:240) java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (OFBIZ-2315) TransactionUtil : 3 Map corruptions related to mis synchronization
[ https://issues.apache.org/jira/browse/OFBIZ-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12700155#action_12700155 ] Philippe Mouawad edited comment on OFBIZ-2315 at 4/17/09 5:45 AM: -- Patch to TransactionUtil , ofbiz-trunk revision: 765951 Philippe www.ubik-ingenierie.com was (Author: pmouawad): Patch to TransactionUtil , ofbiz-trunk revision: 765951 TransactionUtil : 3 Map corruptions related to mis synchronization -- Key: OFBIZ-2315 URL: https://issues.apache.org/jira/browse/OFBIZ-2315 Project: OFBiz Issue Type: Bug Affects Versions: Release Branch 4.0, SVN trunk Reporter: Philippe Mouawad Attachments: ContentionLog.txt, patch-TransactionUtil.patch Randomly we are having Thread contention problems in production related to synchronization issues in this class. See attached log file. As you can see, a lot of threads are locked by some code called by TransactionUtil.setTransactionBeginStack that has been running for 180165 ms : Thread[default-invoker-Thread-4582999,5,main]:4590333, stackTrace: javolution.util.FastMap.mapEntry(Unknown Source) javolution.util.FastMap.access$1200(Unknown Source) javolution.util.FastMap$3.run(Unknown Source) javax.realtime.MemoryArea.executeInArea(Unknown Source) javolution.util.FastMap.resizeTable(Unknown Source) javolution.util.FastMap.mapEntry(Unknown Source) javolution.util.FastMap.addEntry(Unknown Source) javolution.util.FastMap.put(Unknown Source) org.ofbiz.entity.transaction.TransactionUtil.setTransactionBeginStack(TransactionUtil.java:657) org.ofbiz.entity.transaction.TransactionUtil.setTransactionBeginStack(TransactionUtil.java:646) org.ofbiz.entity.transaction.TransactionUtil.begin(TransactionUtil.java:135) org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:297) org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:208) org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:149) org.ofbiz.service.job.GenericServiceJob.exec(GenericServiceJob.java:69) org.ofbiz.service.job.JobInvoker.run(JobInvoker.java:240) java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2186) OutOfMemory provoked by Cache overflow
[
https://issues.apache.org/jira/browse/OFBIZ-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12688000#action_12688000
]
Philippe Mouawad commented on OFBIZ-2186:
-
Hello M. Le Roux,
Yes.
- OFBIZ-2124 was blocking since the application was totally blocked
- This bug was also critical since the application dumpled every day on the 3
servers
We are now in production for 20 days with my 2 patches applied and the
situation is OK.
We have been tracking Memory and response Time, and we don't have memory leaks.
Philippe.
OutOfMemory provoked by Cache overflow
--
Key: OFBIZ-2186
URL: https://issues.apache.org/jira/browse/OFBIZ-2186
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk, Release Branch 4.0
Environment: Linux, JDK 1.5_15, Xmx set to 1156Mo
Reporter: Philippe Mouawad
Assignee: Jacques Le Roux
Priority: Critical
Attachments: CacheLineTable-patch.txt, OfbizBug.zip
In our production system, we had an OutOfMemoryError.
I analyzed the generated Heap Dump and found the following:
The cache entitycache.entity-list.default.ProductCategoryMember retains a
heap of 369314128 Bytes.
The LRUMap hold by this object is occupying this space (369314128) and this
object has a stange state:
- maxSize is set to 5000 (as set in the cache.properties)
- size is 128930 = PROBLEM
IN cache.properties:
entitycache.entity-list.default.ProductCategoryMember.expireTime=360
entitycache.entity-list.default.ProductCategoryMember.useSoftReference=true
entitycache.entity-list.default.ProductCategoryMember.maxInMemory=5000
entitycache.entity-list.default.ProductCategoryMember.maxSize=7500
I analyzed the code of LRUMap and its usage in CacheLineTable and IMHO the
bug is a missing synchonized in get():
public CacheLineV get(Object key) {
if (key == null) {
if (Debug.verboseOn()) Debug.logVerbose(In CacheLineTable tried
to get with null key, using NullObject + this.cacheName, module);
}
return getNoCheck(key);
}
Since LRUMap extends LinkedHashMap, if you look at get method, it changes the
state of the Map by calling e.recordAccess(this):
public V get(Object key) {
EntryK,V e = (EntryK,V)getEntry(key);
if (e == null)
return null;
e.recordAccess(this);
return e.value;
}
So the default of synchronization corrupts the state of LRUMap which grows
indefinitely
I will submit a patch for this on the trunk.
Philippe
www.ubik-ingenierie.com
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2186) OutOfMemory provoked by Cache overflow
[
https://issues.apache.org/jira/browse/OFBIZ-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12680105#action_12680105
]
Philippe Mouawad commented on OFBIZ-2186:
-
Hello M. Jones,
First thank you for your reactivity.
Second here is the status about the two previous patches:
- The first one (you proposed) made the production crash every day for 5 days,
an OOM was generated at least once a day on each server
- With the second one (my proposition) production has been up for 10 days (we
did a jmap to verify the leak was solved as I said), furthermore we didn't
notice slow response time (if you are worried about the synchronized block).
The ecommerce site we are using ofbiz for is a big one with 3 Balanced JVM
servers.
Now about you patch, I am not sure that your patch cannot introduce a Java
Deadlock risk since now there are 2 synchronization
occuring is the case of put/delete (one on the CacheLineTable through
synchronized and one on LRUMap through Collections.synchronizedMap wrapping).
As you may guess we cannot afford testing this new patch with the risk of
production crashing again, it is an ECommerce site.
I am wondering why you don't want to take my patch since it is OK on a big
production SITE and does not incur an important performance loss.
Thanks for your answer.
OutOfMemory provoked by Cache overflow
--
Key: OFBIZ-2186
URL: https://issues.apache.org/jira/browse/OFBIZ-2186
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk, Release Branch 4.0
Environment: Linux, JDK 1.5_15, Xmx set to 1156Mo
Reporter: Philippe Mouawad
Priority: Critical
Attachments: CacheLineTable-patch.txt, OfbizBug.zip
In our production system, we had an OutOfMemoryError.
I analyzed the generated Heap Dump and found the following:
The cache entitycache.entity-list.default.ProductCategoryMember retains a
heap of 369314128 Bytes.
The LRUMap hold by this object is occupying this space (369314128) and this
object has a stange state:
- maxSize is set to 5000 (as set in the cache.properties)
- size is 128930 = PROBLEM
IN cache.properties:
entitycache.entity-list.default.ProductCategoryMember.expireTime=360
entitycache.entity-list.default.ProductCategoryMember.useSoftReference=true
entitycache.entity-list.default.ProductCategoryMember.maxInMemory=5000
entitycache.entity-list.default.ProductCategoryMember.maxSize=7500
I analyzed the code of LRUMap and its usage in CacheLineTable and IMHO the
bug is a missing synchonized in get():
public CacheLineV get(Object key) {
if (key == null) {
if (Debug.verboseOn()) Debug.logVerbose(In CacheLineTable tried
to get with null key, using NullObject + this.cacheName, module);
}
return getNoCheck(key);
}
Since LRUMap extends LinkedHashMap, if you look at get method, it changes the
state of the Map by calling e.recordAccess(this):
public V get(Object key) {
EntryK,V e = (EntryK,V)getEntry(key);
if (e == null)
return null;
e.recordAccess(this);
return e.value;
}
So the default of synchronization corrupts the state of LRUMap which grows
indefinitely
I will submit a patch for this on the trunk.
Philippe
www.ubik-ingenierie.com
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2186) OutOfMemory provoked by Cache overflow
[
https://issues.apache.org/jira/browse/OFBIZ-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12680109#action_12680109
]
Philippe Mouawad commented on OFBIZ-2186:
-
Hello Again,
Concerning the Limitation on cache.
On a big SITE with a rather important catalog, not limiting the cache leads to
a lot of OutOfMemory .
We experienced these problems at first that's why we are limiting more and more
caches.
So you should not think that cache limitation concerns only few caches.
Philippe.
OutOfMemory provoked by Cache overflow
--
Key: OFBIZ-2186
URL: https://issues.apache.org/jira/browse/OFBIZ-2186
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk, Release Branch 4.0
Environment: Linux, JDK 1.5_15, Xmx set to 1156Mo
Reporter: Philippe Mouawad
Priority: Critical
Attachments: CacheLineTable-patch.txt, OfbizBug.zip
In our production system, we had an OutOfMemoryError.
I analyzed the generated Heap Dump and found the following:
The cache entitycache.entity-list.default.ProductCategoryMember retains a
heap of 369314128 Bytes.
The LRUMap hold by this object is occupying this space (369314128) and this
object has a stange state:
- maxSize is set to 5000 (as set in the cache.properties)
- size is 128930 = PROBLEM
IN cache.properties:
entitycache.entity-list.default.ProductCategoryMember.expireTime=360
entitycache.entity-list.default.ProductCategoryMember.useSoftReference=true
entitycache.entity-list.default.ProductCategoryMember.maxInMemory=5000
entitycache.entity-list.default.ProductCategoryMember.maxSize=7500
I analyzed the code of LRUMap and its usage in CacheLineTable and IMHO the
bug is a missing synchonized in get():
public CacheLineV get(Object key) {
if (key == null) {
if (Debug.verboseOn()) Debug.logVerbose(In CacheLineTable tried
to get with null key, using NullObject + this.cacheName, module);
}
return getNoCheck(key);
}
Since LRUMap extends LinkedHashMap, if you look at get method, it changes the
state of the Map by calling e.recordAccess(this):
public V get(Object key) {
EntryK,V e = (EntryK,V)getEntry(key);
if (e == null)
return null;
e.recordAccess(this);
return e.value;
}
So the default of synchronization corrupts the state of LRUMap which grows
indefinitely
I will submit a patch for this on the trunk.
Philippe
www.ubik-ingenierie.com
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2186) OutOfMemory provoked by Cache overflow
[
https://issues.apache.org/jira/browse/OFBIZ-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12680008#action_12680008
]
Philippe Mouawad commented on OFBIZ-2186:
-
Hello M. Jones,
A colleague (Benoit) examined in detail your patch, the problem comes from the
fact that the synchronized block is on 2 different objects so synchronization
fails.
OutOfMemory provoked by Cache overflow
--
Key: OFBIZ-2186
URL: https://issues.apache.org/jira/browse/OFBIZ-2186
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk, Release Branch 4.0
Environment: Linux, JDK 1.5_15, Xmx set to 1156Mo
Reporter: Philippe Mouawad
Priority: Critical
Attachments: CacheLineTable-patch.txt, OfbizBug.zip
In our production system, we had an OutOfMemoryError.
I analyzed the generated Heap Dump and found the following:
The cache entitycache.entity-list.default.ProductCategoryMember retains a
heap of 369314128 Bytes.
The LRUMap hold by this object is occupying this space (369314128) and this
object has a stange state:
- maxSize is set to 5000 (as set in the cache.properties)
- size is 128930 = PROBLEM
IN cache.properties:
entitycache.entity-list.default.ProductCategoryMember.expireTime=360
entitycache.entity-list.default.ProductCategoryMember.useSoftReference=true
entitycache.entity-list.default.ProductCategoryMember.maxInMemory=5000
entitycache.entity-list.default.ProductCategoryMember.maxSize=7500
I analyzed the code of LRUMap and its usage in CacheLineTable and IMHO the
bug is a missing synchonized in get():
public CacheLineV get(Object key) {
if (key == null) {
if (Debug.verboseOn()) Debug.logVerbose(In CacheLineTable tried
to get with null key, using NullObject + this.cacheName, module);
}
return getNoCheck(key);
}
Since LRUMap extends LinkedHashMap, if you look at get method, it changes the
state of the Map by calling e.recordAccess(this):
public V get(Object key) {
EntryK,V e = (EntryK,V)getEntry(key);
if (e == null)
return null;
e.recordAccess(this);
return e.value;
}
So the default of synchronization corrupts the state of LRUMap which grows
indefinitely
I will submit a patch for this on the trunk.
Philippe
www.ubik-ingenierie.com
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2186) OutOfMemory provoked by Cache overflow
[
https://issues.apache.org/jira/browse/OFBIZ-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12679609#action_12679609
]
Philippe Mouawad commented on OFBIZ-2186:
-
Hello M. Jones,
Thank you for taking into account this bug.
We tested the patch you proposed in production, the same problem occured, the
size of LRUMap exceed the configured maxSize.
We tested the initial patch I proposed and the problem is solved, we did a
voluntary heap dump using jmap, and the hprof file generated shows that the
size of LRUMap is OK.
I hope you can take into account this remark as soon as possible.
Philippe
www.ubik-ingenierie.com
OutOfMemory provoked by Cache overflow
--
Key: OFBIZ-2186
URL: https://issues.apache.org/jira/browse/OFBIZ-2186
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk, Release Branch 4.0
Environment: Linux, JDK 1.5_15, Xmx set to 1156Mo
Reporter: Philippe Mouawad
Priority: Critical
Attachments: CacheLineTable-patch.txt, OfbizBug.zip
In our production system, we had an OutOfMemoryError.
I analyzed the generated Heap Dump and found the following:
The cache entitycache.entity-list.default.ProductCategoryMember retains a
heap of 369314128 Bytes.
The LRUMap hold by this object is occupying this space (369314128) and this
object has a stange state:
- maxSize is set to 5000 (as set in the cache.properties)
- size is 128930 = PROBLEM
IN cache.properties:
entitycache.entity-list.default.ProductCategoryMember.expireTime=360
entitycache.entity-list.default.ProductCategoryMember.useSoftReference=true
entitycache.entity-list.default.ProductCategoryMember.maxInMemory=5000
entitycache.entity-list.default.ProductCategoryMember.maxSize=7500
I analyzed the code of LRUMap and its usage in CacheLineTable and IMHO the
bug is a missing synchonized in get():
public CacheLineV get(Object key) {
if (key == null) {
if (Debug.verboseOn()) Debug.logVerbose(In CacheLineTable tried
to get with null key, using NullObject + this.cacheName, module);
}
return getNoCheck(key);
}
Since LRUMap extends LinkedHashMap, if you look at get method, it changes the
state of the Map by calling e.recordAccess(this):
public V get(Object key) {
EntryK,V e = (EntryK,V)getEntry(key);
if (e == null)
return null;
e.recordAccess(this);
return e.value;
}
So the default of synchronization corrupts the state of LRUMap which grows
indefinitely
I will submit a patch for this on the trunk.
Philippe
www.ubik-ingenierie.com
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2124) Ofbiz freeze
[ https://issues.apache.org/jira/browse/OFBIZ-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12673230#action_12673230 ] Philippe Mouawad commented on OFBIZ-2124: - Hello M. Gray, Was the patch applied ? I don't see any SVN commit or change. Thank you for your answer Ofbiz freeze Key: OFBIZ-2124 URL: https://issues.apache.org/jira/browse/OFBIZ-2124 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Environment: JDK5 1.5.0_15-b04, Linux Reporter: Philippe Mouawad Priority: Critical Fix For: SVN trunk Attachments: patch-Freeze-to-Trunk.patch, ThreadDumps.zip In a certain scenario the application freezes, no more AJP connector thread are available. I attach 5 Thread dump done after the freeze -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-2186) OutOfMemory provoked by Cache overflow
OutOfMemory provoked by Cache overflow
--
Key: OFBIZ-2186
URL: https://issues.apache.org/jira/browse/OFBIZ-2186
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk, Release Branch 4.0
Environment: Linux, JDK 1.5_15, Xmx set to 1156Mo
Reporter: Philippe Mouawad
Priority: Critical
In our production system, we had an OutOfMemoryError.
I analyzed the generated Heap Dump and found the following:
The cache entitycache.entity-list.default.ProductCategoryMember retains a heap
of 369314128 Bytes.
The LRUMap hold by this object is occupying this space (369314128) and this
object has a stange state:
- maxSize is set to 5000 (as set in the cache.properties)
- size is 128930 = PROBLEM
IN cache.properties:
entitycache.entity-list.default.ProductCategoryMember.expireTime=360
entitycache.entity-list.default.ProductCategoryMember.useSoftReference=true
entitycache.entity-list.default.ProductCategoryMember.maxInMemory=5000
entitycache.entity-list.default.ProductCategoryMember.maxSize=7500
I analyzed the code of LRUMap and its usage in CacheLineTable and IMHO the bug
is a missing synchonized in get():
public CacheLineV get(Object key) {
if (key == null) {
if (Debug.verboseOn()) Debug.logVerbose(In CacheLineTable tried to
get with null key, using NullObject + this.cacheName, module);
}
return getNoCheck(key);
}
Since LRUMap extends LinkedHashMap, if you look at get method, it changes the
state of the Map by calling e.recordAccess(this):
public V get(Object key) {
EntryK,V e = (EntryK,V)getEntry(key);
if (e == null)
return null;
e.recordAccess(this);
return e.value;
}
So the default of synchronization corrupts the state of LRUMap which grows
indefinitely
I will submit a patch for this on the trunk.
Philippe
www.ubik-ingenierie.com
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-2186) OutOfMemory provoked by Cache overflow
[
https://issues.apache.org/jira/browse/OFBIZ-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philippe Mouawad updated OFBIZ-2186:
Attachment: CacheLineTable-patch.txt
Addition of synchronized to get()
OutOfMemory provoked by Cache overflow
--
Key: OFBIZ-2186
URL: https://issues.apache.org/jira/browse/OFBIZ-2186
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk, Release Branch 4.0
Environment: Linux, JDK 1.5_15, Xmx set to 1156Mo
Reporter: Philippe Mouawad
Priority: Critical
Attachments: CacheLineTable-patch.txt
In our production system, we had an OutOfMemoryError.
I analyzed the generated Heap Dump and found the following:
The cache entitycache.entity-list.default.ProductCategoryMember retains a
heap of 369314128 Bytes.
The LRUMap hold by this object is occupying this space (369314128) and this
object has a stange state:
- maxSize is set to 5000 (as set in the cache.properties)
- size is 128930 = PROBLEM
IN cache.properties:
entitycache.entity-list.default.ProductCategoryMember.expireTime=360
entitycache.entity-list.default.ProductCategoryMember.useSoftReference=true
entitycache.entity-list.default.ProductCategoryMember.maxInMemory=5000
entitycache.entity-list.default.ProductCategoryMember.maxSize=7500
I analyzed the code of LRUMap and its usage in CacheLineTable and IMHO the
bug is a missing synchonized in get():
public CacheLineV get(Object key) {
if (key == null) {
if (Debug.verboseOn()) Debug.logVerbose(In CacheLineTable tried
to get with null key, using NullObject + this.cacheName, module);
}
return getNoCheck(key);
}
Since LRUMap extends LinkedHashMap, if you look at get method, it changes the
state of the Map by calling e.recordAccess(this):
public V get(Object key) {
EntryK,V e = (EntryK,V)getEntry(key);
if (e == null)
return null;
e.recordAccess(this);
return e.value;
}
So the default of synchronization corrupts the state of LRUMap which grows
indefinitely
I will submit a patch for this on the trunk.
Philippe
www.ubik-ingenierie.com
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2186) OutOfMemory provoked by Cache overflow
[
https://issues.apache.org/jira/browse/OFBIZ-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12673321#action_12673321
]
Philippe Mouawad commented on OFBIZ-2186:
-
Hello M. Jones,
If you don't think that my arguments are correct, can you explain why ?
I agree with you about the synchronization performance loss but is it acceptable
that this absence of synchronization provokes a server crash through OOM ?
I will propose another solution soon based on another implementation of LRU but
meanwhile we will put this in production and come back with results.
Now about my explanation, since a LRU is used, LRU is computed based on get(),
look at the code of LinkedHashMap and you will see that get() modifies the state
of the Map, if so Synchronization is mandatory.
Tell me what kind of info you need to be convinced.
To be more convinced run the program I attach with the following options on a
JDK 5:
-Xmx5m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=C:/temp/
It will throw an OutOfMemory.
Add synchronized to CacheLineUsage#get() and see NO MORE PROBLEM.
Inspect the Heap Dump and you get exactly what I told you:
size of Map is 31362 while maxSize is 5000
Memory occupation is 6056872
OutOfMemory provoked by Cache overflow
--
Key: OFBIZ-2186
URL: https://issues.apache.org/jira/browse/OFBIZ-2186
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk, Release Branch 4.0
Environment: Linux, JDK 1.5_15, Xmx set to 1156Mo
Reporter: Philippe Mouawad
Priority: Critical
Attachments: CacheLineTable-patch.txt
In our production system, we had an OutOfMemoryError.
I analyzed the generated Heap Dump and found the following:
The cache entitycache.entity-list.default.ProductCategoryMember retains a
heap of 369314128 Bytes.
The LRUMap hold by this object is occupying this space (369314128) and this
object has a stange state:
- maxSize is set to 5000 (as set in the cache.properties)
- size is 128930 = PROBLEM
IN cache.properties:
entitycache.entity-list.default.ProductCategoryMember.expireTime=360
entitycache.entity-list.default.ProductCategoryMember.useSoftReference=true
entitycache.entity-list.default.ProductCategoryMember.maxInMemory=5000
entitycache.entity-list.default.ProductCategoryMember.maxSize=7500
I analyzed the code of LRUMap and its usage in CacheLineTable and IMHO the
bug is a missing synchonized in get():
public CacheLineV get(Object key) {
if (key == null) {
if (Debug.verboseOn()) Debug.logVerbose(In CacheLineTable tried
to get with null key, using NullObject + this.cacheName, module);
}
return getNoCheck(key);
}
Since LRUMap extends LinkedHashMap, if you look at get method, it changes the
state of the Map by calling e.recordAccess(this):
public V get(Object key) {
EntryK,V e = (EntryK,V)getEntry(key);
if (e == null)
return null;
e.recordAccess(this);
return e.value;
}
So the default of synchronization corrupts the state of LRUMap which grows
indefinitely
I will submit a patch for this on the trunk.
Philippe
www.ubik-ingenierie.com
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-2186) OutOfMemory provoked by Cache overflow
[
https://issues.apache.org/jira/browse/OFBIZ-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philippe Mouawad updated OFBIZ-2186:
Attachment: OfbizBug.zip
Mimics the bug.
LRUMap is Ofbiz class
CacheLineUsage uses the LRUMap the way CacheLineTable uses it, no synchro on get
TestLRU run some threads
Run this with -Xmx set to 5Mo
OutOfMemory provoked by Cache overflow
--
Key: OFBIZ-2186
URL: https://issues.apache.org/jira/browse/OFBIZ-2186
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk, Release Branch 4.0
Environment: Linux, JDK 1.5_15, Xmx set to 1156Mo
Reporter: Philippe Mouawad
Priority: Critical
Attachments: CacheLineTable-patch.txt, OfbizBug.zip
In our production system, we had an OutOfMemoryError.
I analyzed the generated Heap Dump and found the following:
The cache entitycache.entity-list.default.ProductCategoryMember retains a
heap of 369314128 Bytes.
The LRUMap hold by this object is occupying this space (369314128) and this
object has a stange state:
- maxSize is set to 5000 (as set in the cache.properties)
- size is 128930 = PROBLEM
IN cache.properties:
entitycache.entity-list.default.ProductCategoryMember.expireTime=360
entitycache.entity-list.default.ProductCategoryMember.useSoftReference=true
entitycache.entity-list.default.ProductCategoryMember.maxInMemory=5000
entitycache.entity-list.default.ProductCategoryMember.maxSize=7500
I analyzed the code of LRUMap and its usage in CacheLineTable and IMHO the
bug is a missing synchonized in get():
public CacheLineV get(Object key) {
if (key == null) {
if (Debug.verboseOn()) Debug.logVerbose(In CacheLineTable tried
to get with null key, using NullObject + this.cacheName, module);
}
return getNoCheck(key);
}
Since LRUMap extends LinkedHashMap, if you look at get method, it changes the
state of the Map by calling e.recordAccess(this):
public V get(Object key) {
EntryK,V e = (EntryK,V)getEntry(key);
if (e == null)
return null;
e.recordAccess(this);
return e.value;
}
So the default of synchronization corrupts the state of LRUMap which grows
indefinitely
I will submit a patch for this on the trunk.
Philippe
www.ubik-ingenierie.com
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2124) Ofbiz freeze
[ https://issues.apache.org/jira/browse/OFBIZ-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666526#action_12666526 ] Philippe Mouawad commented on OFBIZ-2124: - A patch on the trunk. I can path the 4.0 release if you want. Philippe http://www.ubik-ingenierie.com Ofbiz freeze Key: OFBIZ-2124 URL: https://issues.apache.org/jira/browse/OFBIZ-2124 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 4.0 Environment: JDK5 1.5.0_15-b04, Linux Reporter: Philippe Mouawad Priority: Critical Attachments: patch-Freeze-to-Trunk.patch, ThreadDumps.zip In a certain scenario the application freezes, no more AJP connector thread are available. I attach 5 Thread dump done after the freeze -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-2124) Ofbiz freeze
Ofbiz freeze Key: OFBIZ-2124 URL: https://issues.apache.org/jira/browse/OFBIZ-2124 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 4.0 Environment: JDK5 1.5.0_15-b04, Linux Reporter: Philippe Mouawad Priority: Critical In a certain scenario the application freezes, no more AJP connector thread are available. I attach 5 Thread dump done after the freeze -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-2124) Ofbiz freeze
[ https://issues.apache.org/jira/browse/OFBIZ-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-2124: Attachment: ThreadDumps.zip 4 Thread dumps done after the freeze Ofbiz freeze Key: OFBIZ-2124 URL: https://issues.apache.org/jira/browse/OFBIZ-2124 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 4.0 Environment: JDK5 1.5.0_15-b04, Linux Reporter: Philippe Mouawad Priority: Critical Attachments: ThreadDumps.zip In a certain scenario the application freezes, no more AJP connector thread are available. I attach 5 Thread dump done after the freeze -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2124) Ofbiz freeze
[ https://issues.apache.org/jira/browse/OFBIZ-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12664165#action_12664165 ] Philippe Mouawad commented on OFBIZ-2124: - After analysis the lock seems to come from very slow response time in GenericDelegator.clearAllCaches and particularily in CacheLineTable.keySet. Furthermore, looking at org.ofbiz.base.util.cache.UtilCache, the class seems to have some synchronisation problems: 1) utilCacheTable.put calls are not synchronized 2) findCache synchronizes access to utilCacheTable while only getting an element which has big performance impact since utilCacheTable is static 3) clearExpiredFromAllCaches and clearAllCaches does not synchronize while clearCachesThatStartWith does, why ? Ofbiz freeze Key: OFBIZ-2124 URL: https://issues.apache.org/jira/browse/OFBIZ-2124 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 4.0 Environment: JDK5 1.5.0_15-b04, Linux Reporter: Philippe Mouawad Priority: Critical Attachments: ThreadDumps.zip In a certain scenario the application freezes, no more AJP connector thread are available. I attach 5 Thread dump done after the freeze -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-2124) Ofbiz freeze
[ https://issues.apache.org/jira/browse/OFBIZ-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-2124: Attachment: patch-Freeze-to-Trunk.patch Here is a patch that synchronizes correctly the access to utilCacheTable Ofbiz freeze Key: OFBIZ-2124 URL: https://issues.apache.org/jira/browse/OFBIZ-2124 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 4.0 Environment: JDK5 1.5.0_15-b04, Linux Reporter: Philippe Mouawad Priority: Critical Attachments: patch-Freeze-to-Trunk.patch, ThreadDumps.zip In a certain scenario the application freezes, no more AJP connector thread are available. I attach 5 Thread dump done after the freeze -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-2124) Ofbiz freeze
[ https://issues.apache.org/jira/browse/OFBIZ-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-2124: Attachment: patch-Freeze-to-Trunk.patch Corrects synchronisation and optimises findCache Ofbiz freeze Key: OFBIZ-2124 URL: https://issues.apache.org/jira/browse/OFBIZ-2124 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 4.0 Environment: JDK5 1.5.0_15-b04, Linux Reporter: Philippe Mouawad Priority: Critical Attachments: patch-Freeze-to-Trunk.patch, ThreadDumps.zip In a certain scenario the application freezes, no more AJP connector thread are available. I attach 5 Thread dump done after the freeze -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-2124) Ofbiz freeze
[ https://issues.apache.org/jira/browse/OFBIZ-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-2124: Attachment: (was: patch-Freeze-to-Trunk.patch) Ofbiz freeze Key: OFBIZ-2124 URL: https://issues.apache.org/jira/browse/OFBIZ-2124 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 4.0 Environment: JDK5 1.5.0_15-b04, Linux Reporter: Philippe Mouawad Priority: Critical Attachments: patch-Freeze-to-Trunk.patch, ThreadDumps.zip In a certain scenario the application freezes, no more AJP connector thread are available. I attach 5 Thread dump done after the freeze -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-2124) Ofbiz freeze
[ https://issues.apache.org/jira/browse/OFBIZ-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-2124: Attachment: patch-Freeze-to-Trunk.patch The correct version Ofbiz freeze Key: OFBIZ-2124 URL: https://issues.apache.org/jira/browse/OFBIZ-2124 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 4.0 Environment: JDK5 1.5.0_15-b04, Linux Reporter: Philippe Mouawad Priority: Critical Attachments: patch-Freeze-to-Trunk.patch, patch-Freeze-to-Trunk.patch, ThreadDumps.zip In a certain scenario the application freezes, no more AJP connector thread are available. I attach 5 Thread dump done after the freeze -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-2124) Ofbiz freeze
[ https://issues.apache.org/jira/browse/OFBIZ-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-2124: Attachment: (was: patch-Freeze-to-Trunk.patch) Ofbiz freeze Key: OFBIZ-2124 URL: https://issues.apache.org/jira/browse/OFBIZ-2124 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 4.0 Environment: JDK5 1.5.0_15-b04, Linux Reporter: Philippe Mouawad Priority: Critical Attachments: patch-Freeze-to-Trunk.patch, ThreadDumps.zip In a certain scenario the application freezes, no more AJP connector thread are available. I attach 5 Thread dump done after the freeze -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-2124) Ofbiz freeze
[ https://issues.apache.org/jira/browse/OFBIZ-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-2124: Attachment: patch-Freeze-to-Trunk.patch Corrects synchronisation in class Ofbiz freeze Key: OFBIZ-2124 URL: https://issues.apache.org/jira/browse/OFBIZ-2124 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 4.0 Environment: JDK5 1.5.0_15-b04, Linux Reporter: Philippe Mouawad Priority: Critical Attachments: patch-Freeze-to-Trunk.patch, ThreadDumps.zip In a certain scenario the application freezes, no more AJP connector thread are available. I attach 5 Thread dump done after the freeze -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-2124) Ofbiz freeze
[ https://issues.apache.org/jira/browse/OFBIZ-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated OFBIZ-2124: Attachment: (was: patch-Freeze-to-Trunk.patch) Ofbiz freeze Key: OFBIZ-2124 URL: https://issues.apache.org/jira/browse/OFBIZ-2124 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 4.0 Environment: JDK5 1.5.0_15-b04, Linux Reporter: Philippe Mouawad Priority: Critical Attachments: patch-Freeze-to-Trunk.patch, ThreadDumps.zip In a certain scenario the application freezes, no more AJP connector thread are available. I attach 5 Thread dump done after the freeze -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
