[jira] [Commented] (OFBIZ-10592) OutOfMemory and stucked JobPoller issue
[ https://issues.apache.org/jira/browse/OFBIZ-10592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822288#comment-16822288 ] Giulio Speri commented on OFBIZ-10592: -- Hi everyonem I'm testing a rework on service autoDeleteAutoSaveShoppingList: as is the service retrieves the complete list of ShoppingList records and then check what to delete.My rework is about retrieve a partial list of ShoppingList (test: 1000 records at a time), work and delete that list, then if there are more records, retrieve other partial lists. For this test, I am working on a ShoppingList table of about 1,5M records on my local installation of ofbiz (HP Laptop with 8GB of RAM) and monitoring the whole process with Oracle VisualVM. To try the rework with the minimum jvm resources I set back the default values for Xms and XMx jvm args: 128M and 512M. Until now the test is running well, the heap stays small in size and records are deleted from the table (right now I count 1013582 records; the starting count was 1058968), Obviously performances of navigation (backoffice and ecommerce) during this operation are bit poor, but I can understand it. I leave the service running and I'll come back soon with the global results. Meanwhile I attach a screenshot of Oracle VisualVM Heap Space usage graph. !Screenshot from 2019-04-20 02-32-37.png! > OutOfMemory and stucked JobPoller issue > --- > > Key: OFBIZ-10592 > URL: https://issues.apache.org/jira/browse/OFBIZ-10592 > Project: OFBiz > Issue Type: Bug > Components: ALL APPLICATIONS >Affects Versions: Release Branch 13.07 > Environment: Two instances Ofbiz installation on two machines, > connected to an Apache HTTPD instance which acts as a proxy. > Request to ofbiz instances are handled and load balanced. > OFBiz version : 13.07.03 with Multitenant enabled > OS: Ubuntu Linux 16.04 LTS > RDBMS: MariaDB v10.1.24 >Reporter: Giulio Speri >Assignee: Giulio Speri >Priority: Critical > Attachments: Screenshot from 2019-04-20 02-32-37.png, > alloc_tree_600k_12102018.png, jvm_ofbiz1_profi_telem.png, > jvm_prof_ofbiz1_telem2.png, ofbiz1_jvm_profil_nojobpoller.png, > recorder_object_600k_12102018.png, telemetry_ovrl_600k_12102018.png > > > > This installation is composed by two instances of OFBiz (v13.07.03), served > via an Apache Tomcat webserver, along with a load balancer. > The database server is MariaDB. > > We had the first problems, about 3 weeks ago, when suddenly, the front1 > (ofbiz instance 1), stopped serving web requests; front2, instead, was still > working correctly. > > Obviously we checked the log files, and we saw that async services were > failing; the failure was accompanied by this error line: > > *_Thread "AsyncAppender-async" java.lang.OutOfMemoryError: GC overhead limit > exceeded_* > > We analyzed the situation with our system specialists, and they told us that > the application was highly stressing machine resources (cpu always at or near > 100%, RAM usage rapidly increasing), until the jvm run out of memory. > This "resource-high-consumption situation", occurred only when ofbiz1 > instance was started with the JobPoller enabled; if the JobPoller was not > enabled, ofbiz run with low resource usage. > > We then focused on the db, to check first of all the dimensions; the result > was disconcerting; 45GB, mainly divided on four tables: SERVER_HIT (about 18 > GB), VISIT (about 15 GB), ENTITY_SYNC_REMOVE (about 8 GB), VISITOR (about 2 > GB). > All the other tables had a size in the order of few MB each. > > The first thing we did, was to clear all those tables, reducing considerably > the db size. > After the cleaning, we tried to start ofbiz1 again, with the JobPoller > component enabled; this caused a lot of old scheduled/queued jobs, to execute. > Except than for the start-up time, the resource usage of the machine, > stabilized around normal to low values (cpu 1-10%). > Ofbiz seemed to work (web request was served), but we noticed that the > JobPoller did not schedule or run jobs, anymore. > The number of job in "Pending" state in the JobSandbox entity was small > (about 20); no Queued, no Failed, no jobs in other states. > In addition to this, unfortunately, after few hours, jvm run out of memory > again. > > Our jvm has an heap maximum size of 20GB ( we have 32GB on the machine), so > it's not so small, I think. > The next step we're going to do is set-up locally the application over the > same production db to see what happens. > > Now that I explained the situation, I am going to ask if, in your > opinion/experience: > > Could the JobPoller component be the root (and only) cause of the OutOfMemory > of the jvm? > > Could this issue be related to OFBIZ-5710? > >
[jira] [Updated] (OFBIZ-10592) OutOfMemory and stucked JobPoller issue
[ https://issues.apache.org/jira/browse/OFBIZ-10592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Giulio Speri updated OFBIZ-10592: - Attachment: Screenshot from 2019-04-20 02-32-37.png > OutOfMemory and stucked JobPoller issue > --- > > Key: OFBIZ-10592 > URL: https://issues.apache.org/jira/browse/OFBIZ-10592 > Project: OFBiz > Issue Type: Bug > Components: ALL APPLICATIONS >Affects Versions: Release Branch 13.07 > Environment: Two instances Ofbiz installation on two machines, > connected to an Apache HTTPD instance which acts as a proxy. > Request to ofbiz instances are handled and load balanced. > OFBiz version : 13.07.03 with Multitenant enabled > OS: Ubuntu Linux 16.04 LTS > RDBMS: MariaDB v10.1.24 >Reporter: Giulio Speri >Assignee: Giulio Speri >Priority: Critical > Attachments: Screenshot from 2019-04-20 02-32-37.png, > alloc_tree_600k_12102018.png, jvm_ofbiz1_profi_telem.png, > jvm_prof_ofbiz1_telem2.png, ofbiz1_jvm_profil_nojobpoller.png, > recorder_object_600k_12102018.png, telemetry_ovrl_600k_12102018.png > > > > This installation is composed by two instances of OFBiz (v13.07.03), served > via an Apache Tomcat webserver, along with a load balancer. > The database server is MariaDB. > > We had the first problems, about 3 weeks ago, when suddenly, the front1 > (ofbiz instance 1), stopped serving web requests; front2, instead, was still > working correctly. > > Obviously we checked the log files, and we saw that async services were > failing; the failure was accompanied by this error line: > > *_Thread "AsyncAppender-async" java.lang.OutOfMemoryError: GC overhead limit > exceeded_* > > We analyzed the situation with our system specialists, and they told us that > the application was highly stressing machine resources (cpu always at or near > 100%, RAM usage rapidly increasing), until the jvm run out of memory. > This "resource-high-consumption situation", occurred only when ofbiz1 > instance was started with the JobPoller enabled; if the JobPoller was not > enabled, ofbiz run with low resource usage. > > We then focused on the db, to check first of all the dimensions; the result > was disconcerting; 45GB, mainly divided on four tables: SERVER_HIT (about 18 > GB), VISIT (about 15 GB), ENTITY_SYNC_REMOVE (about 8 GB), VISITOR (about 2 > GB). > All the other tables had a size in the order of few MB each. > > The first thing we did, was to clear all those tables, reducing considerably > the db size. > After the cleaning, we tried to start ofbiz1 again, with the JobPoller > component enabled; this caused a lot of old scheduled/queued jobs, to execute. > Except than for the start-up time, the resource usage of the machine, > stabilized around normal to low values (cpu 1-10%). > Ofbiz seemed to work (web request was served), but we noticed that the > JobPoller did not schedule or run jobs, anymore. > The number of job in "Pending" state in the JobSandbox entity was small > (about 20); no Queued, no Failed, no jobs in other states. > In addition to this, unfortunately, after few hours, jvm run out of memory > again. > > Our jvm has an heap maximum size of 20GB ( we have 32GB on the machine), so > it's not so small, I think. > The next step we're going to do is set-up locally the application over the > same production db to see what happens. > > Now that I explained the situation, I am going to ask if, in your > opinion/experience: > > Could the JobPoller component be the root (and only) cause of the OutOfMemory > of the jvm? > > Could this issue be related to OFBIZ-5710? > > Dumping and analyzing the heap of the jvm could help in some way to > understand what or who fills the memory or is this operation a waste of time? > > Is there something that we did not considered or missed during the whole > process of problem analysis? > > > I really thank you all for your attention and your help; any suggestion or > advice would really be greatly appreciated. > > Kind regards, > Giulio -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10934) Performance Increase: Using replace() instead of replaceAll() when a regex is not used increases performance
[
https://issues.apache.org/jira/browse/OFBIZ-10934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822194#comment-16822194
]
Mathieu Lirzin commented on OFBIZ-10934:
Hello,
while I agree that {{String#replace}} should be used in place of
{{String#replaceAll}} when a simple string replacement is made because it is
more specific and minimal, I am not comfortable with any performance claim that
is not backed by some measurements. :-)
Are the fixes made by [^OFBIZ-10934.patch] exhaustive, or is it just a random
sample ? Both cases are fine in my opinion, I just want to understand how far
you have investigated to know If it worths more investigation on my side.
Thanks for you patch.
> Performance Increase: Using replace() instead of replaceAll() when a regex is
> not used increases performance
>
>
> Key: OFBIZ-10934
> URL: https://issues.apache.org/jira/browse/OFBIZ-10934
> Project: OFBiz
> Issue Type: Bug
>Reporter: bd2019us
>Priority: Major
> Labels: pull-request-available
> Attachments: OFBIZ-10934.patch
>
>
> Affected files:
> # framework/base/src/main/java/org/apache/ofbiz/base/util/UtilHttp.java
> #
> framework/widget/src/main/java/org/apache/ofbiz/widget/renderer/macro/MacroFormRenderer.java
> When replaceAll() is utilized and no regex is used, replaceAll() can be
> replaced with replace() for better performance
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OFBIZ-10934) Performance Increase: Using replace() instead of replaceAll() when a regex is not used increases performance
[ https://issues.apache.org/jira/browse/OFBIZ-10934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bd2019us updated OFBIZ-10934: - Labels: pull-request-available (was: ) > Performance Increase: Using replace() instead of replaceAll() when a regex is > not used increases performance > > > Key: OFBIZ-10934 > URL: https://issues.apache.org/jira/browse/OFBIZ-10934 > Project: OFBiz > Issue Type: Bug >Reporter: bd2019us >Priority: Major > Labels: pull-request-available > Attachments: OFBIZ-10934.patch > > > Affected files: > # framework/base/src/main/java/org/apache/ofbiz/base/util/UtilHttp.java > # > framework/widget/src/main/java/org/apache/ofbiz/widget/renderer/macro/MacroFormRenderer.java > When replaceAll() is utilized and no regex is used, replaceAll() can be > replaced with replace() for better performance -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-10934) Performance Increase: Using replace() instead of replaceAll() when a regex is not used increases performance
[ https://issues.apache.org/jira/browse/OFBIZ-10934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bd2019us updated OFBIZ-10934: - Description: Affected files: # framework/base/src/main/java/org/apache/ofbiz/base/util/UtilHttp.java # framework/widget/src/main/java/org/apache/ofbiz/widget/renderer/macro/MacroFormRenderer.java When replaceAll() is utilized and no regex is used, replaceAll() can be replaced with replace() for better performance was: Affected files: # framework/base/src/main/java/org/apache/ofbiz/base/util/UtilHttp.java # framework/widget/src/main/java/org/apache/ofbiz/widget/renderer/macro/MacroFormRenderer.java > Performance Increase: Using replace() instead of replaceAll() when a regex is > not used increases performance > > > Key: OFBIZ-10934 > URL: https://issues.apache.org/jira/browse/OFBIZ-10934 > Project: OFBiz > Issue Type: Bug >Reporter: bd2019us >Priority: Major > Attachments: OFBIZ-10934.patch > > > Affected files: > # framework/base/src/main/java/org/apache/ofbiz/base/util/UtilHttp.java > # > framework/widget/src/main/java/org/apache/ofbiz/widget/renderer/macro/MacroFormRenderer.java > When replaceAll() is utilized and no regex is used, replaceAll() can be > replaced with replace() for better performance -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-10934) Performance Increase: Using replace() instead of replaceAll() when a regex is not used increases performance
[ https://issues.apache.org/jira/browse/OFBIZ-10934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bd2019us updated OFBIZ-10934: - Attachment: OFBIZ-10934.patch > Performance Increase: Using replace() instead of replaceAll() when a regex is > not used increases performance > > > Key: OFBIZ-10934 > URL: https://issues.apache.org/jira/browse/OFBIZ-10934 > Project: OFBiz > Issue Type: Bug >Reporter: bd2019us >Priority: Major > Attachments: OFBIZ-10934.patch > > > Affected files: > # framework/base/src/main/java/org/apache/ofbiz/base/util/UtilHttp.java > # > framework/widget/src/main/java/org/apache/ofbiz/widget/renderer/macro/MacroFormRenderer.java -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-10934) Performance Increase: Using replace() instead of replaceAll() when a regex is not used increases performance
[ https://issues.apache.org/jira/browse/OFBIZ-10934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bd2019us updated OFBIZ-10934: - Attachment: (was: OFBIZ-10934.patch) > Performance Increase: Using replace() instead of replaceAll() when a regex is > not used increases performance > > > Key: OFBIZ-10934 > URL: https://issues.apache.org/jira/browse/OFBIZ-10934 > Project: OFBiz > Issue Type: Bug >Reporter: bd2019us >Priority: Major > > Affected files: > # framework/base/src/main/java/org/apache/ofbiz/base/util/UtilHttp.java > # > framework/widget/src/main/java/org/apache/ofbiz/widget/renderer/macro/MacroFormRenderer.java -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-10934) Performance Increase: Using replace() instead of replaceAll() when a regex is not used increases performance
[ https://issues.apache.org/jira/browse/OFBIZ-10934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bd2019us updated OFBIZ-10934: - Attachment: OFBIZ-10934.patch > Performance Increase: Using replace() instead of replaceAll() when a regex is > not used increases performance > > > Key: OFBIZ-10934 > URL: https://issues.apache.org/jira/browse/OFBIZ-10934 > Project: OFBiz > Issue Type: Bug >Reporter: bd2019us >Priority: Major > Attachments: OFBIZ-10934.patch > > > Affected files: > # framework/base/src/main/java/org/apache/ofbiz/base/util/UtilHttp.java > # > framework/widget/src/main/java/org/apache/ofbiz/widget/renderer/macro/MacroFormRenderer.java -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OFBIZ-10934) Performance Increase: Using replace() instead of replaceAll() when a regex is not used increases performance
bd2019us created OFBIZ-10934: Summary: Performance Increase: Using replace() instead of replaceAll() when a regex is not used increases performance Key: OFBIZ-10934 URL: https://issues.apache.org/jira/browse/OFBIZ-10934 Project: OFBiz Issue Type: Bug Reporter: bd2019us Affected files: # framework/base/src/main/java/org/apache/ofbiz/base/util/UtilHttp.java # framework/widget/src/main/java/org/apache/ofbiz/widget/renderer/macro/MacroFormRenderer.java -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-10933) Insertion order of ‘LinkedHashMap’ is not preserved by ‘MapContext’
[ https://issues.apache.org/jira/browse/OFBIZ-10933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lirzin updated OFBIZ-10933: --- Fix Version/s: (was: Upcoming Branch) Trunk Release Branch 18.12 > Insertion order of ‘LinkedHashMap’ is not preserved by ‘MapContext’ > --- > > Key: OFBIZ-10933 > URL: https://issues.apache.org/jira/browse/OFBIZ-10933 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Release Branch 18.12 >Reporter: Mathieu Lirzin >Assignee: Mathieu Lirzin >Priority: Major > Fix For: Trunk, Release Branch 18.12 > > Attachments: > OFBIZ-10933_0001-Improved-Add-UtilMisc-toMap-Supplier-Map-K-V-Object.patch, > OFBIZ-10933_0002-Fixed-Ensure-that-MapContext-preserves-insertion-ord.patch > > > Since revision 1837462, when pushing a ‘LinkedHashMap’ inside a ‘MapContext’, > the iteration order of the ‘MapContext’ values is not corresponding to the > insertion order of the embedded ‘LinkedHashMap’ which is important in the > ‘ControllerConfig’ case where configuration elements are stored in > ‘LinkedHashMap’ objects and the ‘include’ mechanism relies on ‘MapContext’. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OFBIZ-10933) Insertion order of ‘LinkedHashMap’ is not preserved by ‘MapContext’
[ https://issues.apache.org/jira/browse/OFBIZ-10933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lirzin resolved OFBIZ-10933. Resolution: Fixed Committed in revisions 1857817 and 1857818 on trunk. Committed in revisions 1857819 and 1857820 on release18.12 The bug is hopefully not present on older releases. > Insertion order of ‘LinkedHashMap’ is not preserved by ‘MapContext’ > --- > > Key: OFBIZ-10933 > URL: https://issues.apache.org/jira/browse/OFBIZ-10933 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Release Branch 18.12 >Reporter: Mathieu Lirzin >Assignee: Mathieu Lirzin >Priority: Major > Fix For: Upcoming Branch > > Attachments: > OFBIZ-10933_0001-Improved-Add-UtilMisc-toMap-Supplier-Map-K-V-Object.patch, > OFBIZ-10933_0002-Fixed-Ensure-that-MapContext-preserves-insertion-ord.patch > > > Since revision 1837462, when pushing a ‘LinkedHashMap’ inside a ‘MapContext’, > the iteration order of the ‘MapContext’ values is not corresponding to the > insertion order of the embedded ‘LinkedHashMap’ which is important in the > ‘ControllerConfig’ case where configuration elements are stored in > ‘LinkedHashMap’ objects and the ‘include’ mechanism relies on ‘MapContext’. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-4690) If Picklist is Cancelled than all the PicklistItem related to that PicklistId should also get Cancel.
[ https://issues.apache.org/jira/browse/OFBIZ-4690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821944#comment-16821944 ] Swapnil M Mane commented on OFBIZ-4690: --- The change of calling 'cancelPicklistAndItems' action service in sync mode is committed in trunk at rev 1857813 release18.12 at rev 1857814 release17.12 at rev 1857815 release16.11 at rev 1857816 Thanks! > If Picklist is Cancelled than all the PicklistItem related to that PicklistId > should also get Cancel. > -- > > Key: OFBIZ-4690 > URL: https://issues.apache.org/jira/browse/OFBIZ-4690 > Project: OFBiz > Issue Type: Improvement >Affects Versions: Release 10.04, Release Branch 11.04, Trunk >Reporter: Ankit Jain >Assignee: Jacques Le Roux >Priority: Minor > Fix For: Trunk > > Attachments: OFBIZ-4690.patch > > > If Picklist is Cancelled than all the PicklistItem related to that PicklistId > should also get Cancel. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-10933) Insertion order of ‘LinkedHashMap’ is not preserved by ‘MapContext’
[ https://issues.apache.org/jira/browse/OFBIZ-10933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lirzin updated OFBIZ-10933: --- Attachment: OFBIZ-10933_0001-Improved-Add-UtilMisc-toMap-Supplier-Map-K-V-Object.patch OFBIZ-10933_0002-Fixed-Ensure-that-MapContext-preserves-insertion-ord.patch > Insertion order of ‘LinkedHashMap’ is not preserved by ‘MapContext’ > --- > > Key: OFBIZ-10933 > URL: https://issues.apache.org/jira/browse/OFBIZ-10933 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Release Branch 18.12 >Reporter: Mathieu Lirzin >Assignee: Mathieu Lirzin >Priority: Major > Fix For: Upcoming Branch > > Attachments: > OFBIZ-10933_0001-Improved-Add-UtilMisc-toMap-Supplier-Map-K-V-Object.patch, > OFBIZ-10933_0002-Fixed-Ensure-that-MapContext-preserves-insertion-ord.patch > > > Since revision 1837462, when pushing a ‘LinkedHashMap’ inside a ‘MapContext’, > the iteration order of the ‘MapContext’ values is not corresponding to the > insertion order of the embedded ‘LinkedHashMap’ which is important in the > ‘ControllerConfig’ case where configuration elements are stored in > ‘LinkedHashMap’ objects and the ‘include’ mechanism relies on ‘MapContext’. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-4690) If Picklist is Cancelled than all the PicklistItem related to that PicklistId should also get Cancel.
[ https://issues.apache.org/jira/browse/OFBIZ-4690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821919#comment-16821919 ] Swapnil M Mane commented on OFBIZ-4690: --- Thank you [~jacques.le.roux] ! > If Picklist is Cancelled than all the PicklistItem related to that PicklistId > should also get Cancel. > -- > > Key: OFBIZ-4690 > URL: https://issues.apache.org/jira/browse/OFBIZ-4690 > Project: OFBiz > Issue Type: Improvement >Affects Versions: Release 10.04, Release Branch 11.04, Trunk >Reporter: Ankit Jain >Assignee: Jacques Le Roux >Priority: Minor > Fix For: Trunk > > Attachments: OFBIZ-4690.patch > > > If Picklist is Cancelled than all the PicklistItem related to that PicklistId > should also get Cancel. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-4690) If Picklist is Cancelled than all the PicklistItem related to that PicklistId should also get Cancel.
[ https://issues.apache.org/jira/browse/OFBIZ-4690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821915#comment-16821915 ] Jacques Le Roux commented on OFBIZ-4690: Hi Swapnil, Yes please proceed, we are in CTR (Commit Then Review) mode, so if somebody see a problem with that we will still be able to amend it, thanks! > If Picklist is Cancelled than all the PicklistItem related to that PicklistId > should also get Cancel. > -- > > Key: OFBIZ-4690 > URL: https://issues.apache.org/jira/browse/OFBIZ-4690 > Project: OFBiz > Issue Type: Improvement >Affects Versions: Release 10.04, Release Branch 11.04, Trunk >Reporter: Ankit Jain >Assignee: Jacques Le Roux >Priority: Minor > Fix For: Trunk > > Attachments: OFBIZ-4690.patch > > > If Picklist is Cancelled than all the PicklistItem related to that PicklistId > should also get Cancel. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OFBIZ-10933) Insertion order of ‘LinkedHashMap’ is not preserved by ‘MapContext’
Mathieu Lirzin created OFBIZ-10933: -- Summary: Insertion order of ‘LinkedHashMap’ is not preserved by ‘MapContext’ Key: OFBIZ-10933 URL: https://issues.apache.org/jira/browse/OFBIZ-10933 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 18.12 Reporter: Mathieu Lirzin Assignee: Mathieu Lirzin Fix For: Upcoming Branch Since revision 1837462, when pushing a ‘LinkedHashMap’ inside a ‘MapContext’, the iteration order of the ‘MapContext’ values is not corresponding to the insertion order of the embedded ‘LinkedHashMap’ which is important in the ‘ControllerConfig’ case where configuration elements are stored in ‘LinkedHashMap’ objects and the ‘include’ mechanism relies on ‘MapContext’. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-4690) If Picklist is Cancelled than all the PicklistItem related to that PicklistId should also get Cancel.
[ https://issues.apache.org/jira/browse/OFBIZ-4690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821809#comment-16821809 ] Swapnil M Mane commented on OFBIZ-4690: --- Dear [~jacques.le.roux], Thanks for your comment. Should I proceed to change the calling of 'cancelPicklistAndItems' action service in sync mode. Thanks! > If Picklist is Cancelled than all the PicklistItem related to that PicklistId > should also get Cancel. > -- > > Key: OFBIZ-4690 > URL: https://issues.apache.org/jira/browse/OFBIZ-4690 > Project: OFBiz > Issue Type: Improvement >Affects Versions: Release 10.04, Release Branch 11.04, Trunk >Reporter: Ankit Jain >Assignee: Jacques Le Roux >Priority: Minor > Fix For: Trunk > > Attachments: OFBIZ-4690.patch > > > If Picklist is Cancelled than all the PicklistItem related to that PicklistId > should also get Cancel. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
