Re: jquey
Hi All, I am sorry if my suggestion to create a release branch has delayed somehow the merging of the great work that Jacques and Sasha have done. This was not my intention at all. The idea was just to create a release branch; this, IMO, should not have delayed the merging. The reason of the branch was to offer a place where to live to people that are now using the trunk if any issue with the jQuery should arise, until, thanks to the massive test that will start only now that we will have it in the trunk, will fix everythink. Apart of that I do not see any other issue. So please, go ahead with the merge, do not delay any further. We will handle any issue as they come (if any). Thank you, Bruno 2010/12/5 Scott Gray scott.g...@hotwaxmedia.com Hi Bruno, I guess I missed your original email but what was the reason for creating a new release branch outside of our normal schedule? Personally I don't see any reason why we can't just merge the jquery branch and carry on as normal. If people choose to develop custom projects against the trunk then good for them but I don't think we need to consider that when making decisions on moving the trunk forward. Regards Scott HotWax Media http://www.hotwaxmedia.com On 3/12/2010, at 6:59 PM, Bruno Busco wrote: Why you think that making a new release branch would create a fork? It will be managed as we manage R10.04 and R9.04 right now. Only bug fixes will be backported. -Bruno 2010/12/2 Jacques Le Roux jacques.le.r...@les7arts.com Ryan Foster wrote: What about creating a tag or branch before the merge so that users who have custom projects or applications based on the trunk have a reference point in the event that they want to freeze their applications at a particular revision? Yes, that's what I have proposed. With another option: to have a branch. But I think the later is more a fork and I prefer the 1st. Oh and +1 on merging in JQuery. I am all for consolidating/simplifying our Javascript libraries. No reason to have 3 libraries that all essentially do the same thing. In the end, Javascript is Javascript. My heart says we should have chosen Prototype as that one (as anyone who knows me would agree, I'm a big Prototype JS evangelist). But, my head says that JQuery is the right choice for the long-term growth and success of the project, as it has definitely become the drug of choice for a majority of developers and has much more wide-spread community involvement as far as development of plugins is concerned. I think we now all agree on that Jacques Ryan L. Foster 801.671.0769 cont...@ryanlfoster.com On Dec 2, 2010, at 11:18 AM, Jacques Le Roux wrote: I'm sorry for Bruno, but it seems everybody is looking forward for this merging. So hopefully I will do it soon. If you are interested you can already check https://issues.apache.org/jira/browse/OFBIZ-3814 Jacques Michael Xu (xudong) wrote: +1 Yeah, I would love such a great Xmas present :-) You're welcome +1 Would be a great Xmas present to merge all the stuff into the trunk :-) Am 02.12.2010 um 10:59 schrieb Erwan de FERRIERES erwan.de-ferrie...@nereide.fr: Le 02/12/2010 10:35, Jacques Le Roux a écrit : Looks like, apart Bruno, we are all on the same page so far Other opinions, ideas? Thanks Jacques The sooner the better ! Thanks for all your work, Jacques and Sascha -- Erwan de FERRIERES www.nereide.biz
[jira] Reopened: (OFBIZ-4037) Moving the user SignUp feature from MyPortal to the Framework
[ https://issues.apache.org/jira/browse/OFBIZ-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Busco reopened OFBIZ-4037: The commit has been reverted as suggested by Adam. The reason was that the patch adds in the framework several dependencies from the applications (mainly Party). A rework must be done. A possible solution could be to move the register stuff to the commonext component instead of common. What do you think? Moving the user SignUp feature from MyPortal to the Framework - Key: OFBIZ-4037 URL: https://issues.apache.org/jira/browse/OFBIZ-4037 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Bruno Busco Assignee: Bruno Busco Attachments: ofbiz_signup.patch Hi Devs! In the attached patch I have reworked the feature that allows a new user to SignUp for an account. This feature is actually only available when logging in at the MyPortal application. Well, IMO it should be centrally available so that the login screen is exactly the same regardless of the application. The Captcha feature is already implemented (captcha.java) partially in the framework and so this patch should be seen as a clean up also. I added full internationalization of all labels and created some labels in the CommonUiLabels.xml file. I would like some review so that I could then commit if nobody finds something wrong. By the way, there is for sure some improvement that could be done at a later stage: - Eliminate the labels that have been created in the CommonUiLabels from Party and MyPortal - Add an encription of the Captcha code so that it will not be easily broken by robots. Thank you for any comment you could provide. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: jquey
Hi Bruno, OK, then a tag should be sufficient. What about beforejQuery? Jacques From: Bruno Busco bruno.bu...@gmail.com Hi All, I am sorry if my suggestion to create a release branch has delayed somehow the merging of the great work that Jacques and Sasha have done. This was not my intention at all. The idea was just to create a release branch; this, IMO, should not have delayed the merging. The reason of the branch was to offer a place where to live to people that are now using the trunk if any issue with the jQuery should arise, until, thanks to the massive test that will start only now that we will have it in the trunk, will fix everythink. Apart of that I do not see any other issue. So please, go ahead with the merge, do not delay any further. We will handle any issue as they come (if any). Thank you, Bruno 2010/12/5 Scott Gray scott.g...@hotwaxmedia.com Hi Bruno, I guess I missed your original email but what was the reason for creating a new release branch outside of our normal schedule? Personally I don't see any reason why we can't just merge the jquery branch and carry on as normal. If people choose to develop custom projects against the trunk then good for them but I don't think we need to consider that when making decisions on moving the trunk forward. Regards Scott HotWax Media http://www.hotwaxmedia.com On 3/12/2010, at 6:59 PM, Bruno Busco wrote: Why you think that making a new release branch would create a fork? It will be managed as we manage R10.04 and R9.04 right now. Only bug fixes will be backported. -Bruno 2010/12/2 Jacques Le Roux jacques.le.r...@les7arts.com Ryan Foster wrote: What about creating a tag or branch before the merge so that users who have custom projects or applications based on the trunk have a reference point in the event that they want to freeze their applications at a particular revision? Yes, that's what I have proposed. With another option: to have a branch. But I think the later is more a fork and I prefer the 1st. Oh and +1 on merging in JQuery. I am all for consolidating/simplifying our Javascript libraries. No reason to have 3 libraries that all essentially do the same thing. In the end, Javascript is Javascript. My heart says we should have chosen Prototype as that one (as anyone who knows me would agree, I'm a big Prototype JS evangelist). But, my head says that JQuery is the right choice for the long-term growth and success of the project, as it has definitely become the drug of choice for a majority of developers and has much more wide-spread community involvement as far as development of plugins is concerned. I think we now all agree on that Jacques Ryan L. Foster 801.671.0769 cont...@ryanlfoster.com On Dec 2, 2010, at 11:18 AM, Jacques Le Roux wrote: I'm sorry for Bruno, but it seems everybody is looking forward for this merging. So hopefully I will do it soon. If you are interested you can already check https://issues.apache.org/jira/browse/OFBIZ-3814 Jacques Michael Xu (xudong) wrote: +1 Yeah, I would love such a great Xmas present :-) You're welcome +1 Would be a great Xmas present to merge all the stuff into the trunk :-) Am 02.12.2010 um 10:59 schrieb Erwan de FERRIERES erwan.de-ferrie...@nereide.fr: Le 02/12/2010 10:35, Jacques Le Roux a écrit : Looks like, apart Bruno, we are all on the same page so far Other opinions, ideas? Thanks Jacques The sooner the better ! Thanks for all your work, Jacques and Sascha -- Erwan de FERRIERES www.nereide.biz
Re: jquey
+1 ;-) 2010/12/5 Jacques Le Roux jacques.le.r...@les7arts.com Hi Bruno, OK, then a tag should be sufficient. What about beforejQuery? Jacques From: Bruno Busco bruno.bu...@gmail.com Hi All, I am sorry if my suggestion to create a release branch has delayed somehow the merging of the great work that Jacques and Sasha have done. This was not my intention at all. The idea was just to create a release branch; this, IMO, should not have delayed the merging. The reason of the branch was to offer a place where to live to people that are now using the trunk if any issue with the jQuery should arise, until, thanks to the massive test that will start only now that we will have it in the trunk, will fix everythink. Apart of that I do not see any other issue. So please, go ahead with the merge, do not delay any further. We will handle any issue as they come (if any). Thank you, Bruno 2010/12/5 Scott Gray scott.g...@hotwaxmedia.com Hi Bruno, I guess I missed your original email but what was the reason for creating a new release branch outside of our normal schedule? Personally I don't see any reason why we can't just merge the jquery branch and carry on as normal. If people choose to develop custom projects against the trunk then good for them but I don't think we need to consider that when making decisions on moving the trunk forward. Regards Scott HotWax Media http://www.hotwaxmedia.com On 3/12/2010, at 6:59 PM, Bruno Busco wrote: Why you think that making a new release branch would create a fork? It will be managed as we manage R10.04 and R9.04 right now. Only bug fixes will be backported. -Bruno 2010/12/2 Jacques Le Roux jacques.le.r...@les7arts.com Ryan Foster wrote: What about creating a tag or branch before the merge so that users who have custom projects or applications based on the trunk have a reference point in the event that they want to freeze their applications at a particular revision? Yes, that's what I have proposed. With another option: to have a branch. But I think the later is more a fork and I prefer the 1st. Oh and +1 on merging in JQuery. I am all for consolidating/simplifying our Javascript libraries. No reason to have 3 libraries that all essentially do the same thing. In the end, Javascript is Javascript. My heart says we should have chosen Prototype as that one (as anyone who knows me would agree, I'm a big Prototype JS evangelist). But, my head says that JQuery is the right choice for the long-term growth and success of the project, as it has definitely become the drug of choice for a majority of developers and has much more wide-spread community involvement as far as development of plugins is concerned. I think we now all agree on that Jacques Ryan L. Foster 801.671.0769 cont...@ryanlfoster.com On Dec 2, 2010, at 11:18 AM, Jacques Le Roux wrote: I'm sorry for Bruno, but it seems everybody is looking forward for this merging. So hopefully I will do it soon. If you are interested you can already check https://issues.apache.org/jira/browse/OFBIZ-3814 Jacques Michael Xu (xudong) wrote: +1 Yeah, I would love such a great Xmas present :-) You're welcome +1 Would be a great Xmas present to merge all the stuff into the trunk :-) Am 02.12.2010 um 10:59 schrieb Erwan de FERRIERES erwan.de-ferrie...@nereide.fr: Le 02/12/2010 10:35, Jacques Le Roux a écrit : Looks like, apart Bruno, we are all on the same page so far Other opinions, ideas? Thanks Jacques The sooner the better ! Thanks for all your work, Jacques and Sascha -- Erwan de FERRIERES www.nereide.biz
[jira] Commented: (OFBIZ-3490) Create theme build script
[ https://issues.apache.org/jira/browse/OFBIZ-3490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966924#action_12966924 ] Jacques Le Roux commented on OFBIZ-3490: Ping... Create theme build script - Key: OFBIZ-3490 URL: https://issues.apache.org/jira/browse/OFBIZ-3490 Project: OFBiz Issue Type: New Feature Affects Versions: Release Branch 09.04, SVN trunk Environment: ant build Reporter: BJ Freeman Assignee: Jacques Le Roux Priority: Minor Fix For: SVN trunk Attachments: 3490-themebutild.patch I liked the build script for a new component, so I decided to make one for themes. unfortunately I am not able to do a patch so included the script. I made it so you can pick a theme as the template and copy the files over to the new theme. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OFBIZ-3579) Tenant ecommerce effort
[ https://issues.apache.org/jira/browse/OFBIZ-3579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reassigned OFBIZ-3579: -- Assignee: Jacques Le Roux Tenant ecommerce effort --- Key: OFBIZ-3579 URL: https://issues.apache.org/jira/browse/OFBIZ-3579 Project: OFBiz Issue Type: New Feature Components: specialpurpose/ecommerce Affects Versions: Release Branch 10.04, SVN trunk Environment: SINCE version 927271 using the Tenant login. Reporter: BJ Freeman Assignee: Jacques Le Roux Fix For: Release Branch 10.04, SVN trunk Attachments: OFBIZ-3579tenantEcommerce.patch this is the basic ecommerce demo for tenants. it does not yet have all the data to work which other can contribute or I will finish as I get time. the basic work for tenatns (927271 ) does not created the tenant dbs necessary so that needs to be added as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-4042) ecommerce keyword search - Non-breaking space displayed as literal ampersand-nbsp-semicolon
[ https://issues.apache.org/jira/browse/OFBIZ-4042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-4042. -- Resolution: Fixed Fix Version/s: SVN trunk Release Branch 10.04 Release Branch 09.04 Assignee: Jacques Le Roux Thanks Paul, It was only a typo and is fixed in trunk at r1042317, R10.04 at r1042322, R9.04 at r1042323 ecommerce keyword search - Non-breaking space displayed as literal ampersand-nbsp-semicolon --- Key: OFBIZ-4042 URL: https://issues.apache.org/jira/browse/OFBIZ-4042 Project: OFBiz Issue Type: Bug Components: specialpurpose/ecommerce Affects Versions: SVN trunk Reporter: Paul Foxworthy Assignee: Jacques Le Roux Priority: Minor Fix For: Release Branch 09.04, Release Branch 10.04, SVN trunk On demo site, navigate to http://demo-trunk.ofbiz.apache.org/ecommerce/control/main. In Search Catalog box on the left, enter a keyword that isn't in the product descriptions, such as notthere, and click on Find. The results page, http://demo-trunk.ofbiz.apache.org/ecommerce/control/keywordsearch, displays a list of X buttons, which would exclude some search results if there were any. Beside each X button is a sequence of an ampersand, the letters nbsp and a semi-colon. When I do a View Source in my web browser, the sequence is the HTML ampersand entity, then nbsp, then a literal semicolon. Obviously something is HTML encoding what was originally intended to be a non-breaking space. I can see the non-breaking space entity in applications/product/webapp/catalog/find/keywordsearch.ftl . Of course it is necessary to HTML encode any untrusted data coming from the client side to guard against cross site scripting attacks. I don't see why it is necessary to HTML encode the contents of a FreeMarker template, and I don't understand why this non-breaking space is being encoded, and not every occurrence of a greater-than or a less-than in the template. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Calling selenium from the build XML was jquey
Hi BJ, sorry for the late response, but i was not at home yesterday. :-). That was more or less a POC. I tried to create a showcase to test standard Application Screens (i.e. a standard ecommerce module). Therefore i created the unit tests with the selenium firefox plugin, modifyed the tests for my purposes and used them in a little selfmade testing framework. That was very simple. It reads test data (i.e user data, orders which should be placed ...) from an excel file (Apache POI), creates a list with the neded data and called the tests class with the unit tests, from this point selenium did all the work, run the test and give me a result. That's it. Maybe a little bit uncommon but as i said it was a POC for a certain use case :-) But at the end of the day a think there is a lot of stuff / test cases which can be handled by selenium, but i also noticed that it is a lot of work creating all the tests... Hope you get an idea what i was trying to do. Have a good day Sascha 2010/12/3 BJ Freeman bjf...@free-man.net what what level were you working on? I am working on scenarios for a user, like orderentry, adding products, placing order through Ecommerce. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Sascha Rodekamp sent the following on 12/3/2010 12:11 AM: Good morning chaps Calling selenium from the build XML is a great point. I tried that a few month ago in another project once selenium is set up right it's really helpful So in my opinion we should def think of it. Cheers Sascha Am 03.12.2010 um 07:42 schrieb Adam Heathdoo...@brainfood.com: BJ Freeman wrote: Chuckle that is what I thought, and I dread more workload to just keep up. at this point I think you and I are the only ones that have invested in Selenium The solution there is to stop maintaining it outside of the normal development pipeline. Get it into trunk, make running selenium tests automatic, with a simple call in build.xml. -- Sascha Rodekamp Lynx-Consulting GmbH Johanniskirchplatz 6 D-33615 Bielefeld http://www.lynx.de
Re: Ofbiz Doc book help
not much effort to change just wanted input before I put effort into it. I have made a decision to convert the wikis to docbook and put in appropriate sections. to that end i am also looking at what in ofbiz I can use to write a top level converter from wiki markup (or rtf) to Dockbook format. so in the webtools component you drop the wiki markup (or rtf) in and specify the title and location of the dockbook file. thanks for you input = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Jacques Le Roux sent the following on 12/5/2010 1:30 AM: This seems reasonnable to me, but does it need much work? My 2cts Jacques From: BJ Freeman bjf...@free-man.net looking at the main Doc URL (cmssite/cms/APACHE_OFBIZ_HTML)for Apache OFBiz official documentation. it seems we should go up one level and have the different doc groups called out. Apache OFBiz User documentation Apache OFBiz Technical documentation. I added some tech docs from wiki so if you think this is ok will add it to the patch. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man
[jira] Commented: (OFBIZ-3490) Create theme build script
[ https://issues.apache.org/jira/browse/OFBIZ-3490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966941#action_12966941 ] BJ Freeman commented on OFBIZ-3490: --- yup. to organize my energy I have decided to use the doc books to write the help files, then do the scripts. as a change, since I am focused on the multitenant, Self service, I want to make this part of the setup so that end users can created/select themes to be installed. also need to to some work on the selection of themes so if a theme is marked as copyrighted and private, it does not show up in current theme selections. Create theme build script - Key: OFBIZ-3490 URL: https://issues.apache.org/jira/browse/OFBIZ-3490 Project: OFBiz Issue Type: New Feature Affects Versions: Release Branch 09.04, SVN trunk Environment: ant build Reporter: BJ Freeman Assignee: Jacques Le Roux Priority: Minor Fix For: SVN trunk Attachments: 3490-themebutild.patch I liked the build script for a new component, so I decided to make one for themes. unfortunately I am not able to do a patch so included the script. I made it so you can pick a theme as the template and copy the files over to the new theme. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-4022) Collapse all broken if hyperlink in pane
[ https://issues.apache.org/jira/browse/OFBIZ-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-4022. -- Resolution: Fixed Fix Version/s: SVN trunk jQuery Release Branch 10.04 Release Branch 09.04 Assignee: Jacques Le Roux Thanks Anne, Your patch is in trunk at r1042348, R10.04 at r1042358, R9.04 at r1042357, jQuery at r1042349 Please don't forget to use spaces instead of tabs in your patch, not a big deal anyway Collapse all broken if hyperlink in pane Key: OFBIZ-4022 URL: https://issues.apache.org/jira/browse/OFBIZ-4022 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Environment: Rev 1035845 Reporter: Anne Jessel Assignee: Jacques Le Roux Priority: Minor Fix For: Release Branch 09.04, Release Branch 10.04, jQuery, SVN trunk Attachments: OFBIZ-4022_collapse-all-broken.patch Original Estimate: 0.33h Remaining Estimate: 0.33h To reproduce the bug: - edit the EditProduct form in applications/product/widget/catalog/ProductForms.xml - add a new field with a hyperlink sub-element. - refer to this new field in the first, non-collapsible field-group in the sort-order - go to this page in the UI (edit a product in the catalog) - the Expand All and Collapse All buttons do not work properly The problem is caused by the javascript finding the added hyperlink field in the first field-group, and incorrectly assuming it is the expand/collapse link for the field-group. This causes the javascript to crash when it gets a null reference to an enclosing li element. It is not specific to the EditProduct form, but applies to any group of collapsible panes where one contains a hyperlink. The attached patch simply checks that the li element actually exists. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-4027) Product Store Email Setting with PARTY_EMAIL
[ https://issues.apache.org/jira/browse/OFBIZ-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-4027. -- Resolution: Fixed Assignee: Jacques Le Roux Thanks Eric, Your patch is in trunk at r1042360, and only trunk as it's not a bug but improvement Product Store Email Setting with PARTY_EMAIL Key: OFBIZ-4027 URL: https://issues.apache.org/jira/browse/OFBIZ-4027 Project: OFBiz Issue Type: Improvement Components: product, specialpurpose/ecommerce Affects Versions: SVN trunk Environment: trunk 1035845 Reporter: Eric de Maulde Assignee: Jacques Le Roux Priority: Trivial Fix For: SVN trunk Attachments: createProductStoreEmail+PARTY_EMAIL.patch Product Store Email Setting page doesn't allow to configure an email from emailType = PARTY_EMAIL So when an anonymous contact posts a message, an automated email isn't sent to the store payToPartyId -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-4027) Product Store Email Setting with PARTY_EMAIL
[ https://issues.apache.org/jira/browse/OFBIZ-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-4027: --- Component/s: product Issue Type: Improvement (was: Bug) Product Store Email Setting with PARTY_EMAIL Key: OFBIZ-4027 URL: https://issues.apache.org/jira/browse/OFBIZ-4027 Project: OFBiz Issue Type: Improvement Components: product, specialpurpose/ecommerce Affects Versions: SVN trunk Environment: trunk 1035845 Reporter: Eric de Maulde Priority: Trivial Fix For: SVN trunk Attachments: createProductStoreEmail+PARTY_EMAIL.patch Product Store Email Setting page doesn't allow to configure an email from emailType = PARTY_EMAIL So when an anonymous contact posts a message, an automated email isn't sent to the store payToPartyId -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-4043) Memory leaks in (at least) stable demo
Memory leaks in (at least) stable demo -- Key: OFBIZ-4043 URL: https://issues.apache.org/jira/browse/OFBIZ-4043 Project: OFBiz Issue Type: Bug Affects Versions: Release Branch 09.04 Environment: On OFBiz demo stable Reporter: Jacques Le Roux Using [Mat|http://www.eclipse.org/mat/] I generated these report 110 542 instances of org.apache.derby.impl.jdbc.EmbedConnection40, loaded by java.net.URLClassLoader @ 0x7f3681c111f0 occupy 415 680 440 (79,89%) bytes. These instances are referenced from one instance of java.util.WeakHashMap$Entry[], loaded by system class loader Keywords java.net.URLClassLoader @ 0x7f3681c111f0 org.apache.derby.impl.jdbc.EmbedConnection40 java.util.WeakHashMap$Entry[] It's not quite clear to me how this happends, but I'm quirte sure it happens often in stable demo and maybe in trunk also. I have also attached a screen-copy with more information -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-4043) Memory leaks in (at least) stable demo
[ https://issues.apache.org/jira/browse/OFBIZ-4043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-4043: --- Attachment: Leaks Suspect .jpg Memory leaks in (at least) stable demo -- Key: OFBIZ-4043 URL: https://issues.apache.org/jira/browse/OFBIZ-4043 Project: OFBiz Issue Type: Bug Affects Versions: Release Branch 09.04 Environment: On OFBiz demo stable Reporter: Jacques Le Roux Attachments: Leaks Suspect .jpg Using [Mat|http://www.eclipse.org/mat/] I generated these report 110 542 instances of org.apache.derby.impl.jdbc.EmbedConnection40, loaded by java.net.URLClassLoader @ 0x7f3681c111f0 occupy 415 680 440 (79,89%) bytes. These instances are referenced from one instance of java.util.WeakHashMap$Entry[], loaded by system class loader Keywords java.net.URLClassLoader @ 0x7f3681c111f0 org.apache.derby.impl.jdbc.EmbedConnection40 java.util.WeakHashMap$Entry[] It's not quite clear to me how this happends, but I'm quirte sure it happens often in stable demo and maybe in trunk also. I have also attached a screen-copy with more information -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-4043) Memory leaks in (at least) stable demo
[ https://issues.apache.org/jira/browse/OFBIZ-4043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-4043: --- Description: Using [Mat|http://www.eclipse.org/mat/] I generated these report 110 542 instances of org.apache.derby.impl.jdbc.EmbedConnection40, loaded by java.net.URLClassLoader @ 0x7f3681c111f0 occupy 415 680 440 (79,89%) bytes. These instances are referenced from one instance of java.util.WeakHashMap$Entry[], loaded by system class loader Keywords java.net.URLClassLoader @ 0x7f3681c111f0 org.apache.derby.impl.jdbc.EmbedConnection40 java.util.WeakHashMap$Entry[] It's not quite clear to me how this happends, but I'm quite sure it happens often in stable demo and maybe also in trunk. I have also attached a screen-copy with more information was: Using [Mat|http://www.eclipse.org/mat/] I generated these report 110 542 instances of org.apache.derby.impl.jdbc.EmbedConnection40, loaded by java.net.URLClassLoader @ 0x7f3681c111f0 occupy 415 680 440 (79,89%) bytes. These instances are referenced from one instance of java.util.WeakHashMap$Entry[], loaded by system class loader Keywords java.net.URLClassLoader @ 0x7f3681c111f0 org.apache.derby.impl.jdbc.EmbedConnection40 java.util.WeakHashMap$Entry[] It's not quite clear to me how this happends, but I'm quirte sure it happens often in stable demo and maybe in trunk also. I have also attached a screen-copy with more information Memory leaks in (at least) stable demo -- Key: OFBIZ-4043 URL: https://issues.apache.org/jira/browse/OFBIZ-4043 Project: OFBiz Issue Type: Bug Affects Versions: Release Branch 09.04 Environment: On OFBiz demo stable Reporter: Jacques Le Roux Attachments: Leaks Suspect .jpg Using [Mat|http://www.eclipse.org/mat/] I generated these report 110 542 instances of org.apache.derby.impl.jdbc.EmbedConnection40, loaded by java.net.URLClassLoader @ 0x7f3681c111f0 occupy 415 680 440 (79,89%) bytes. These instances are referenced from one instance of java.util.WeakHashMap$Entry[], loaded by system class loader Keywords java.net.URLClassLoader @ 0x7f3681c111f0 org.apache.derby.impl.jdbc.EmbedConnection40 java.util.WeakHashMap$Entry[] It's not quite clear to me how this happends, but I'm quite sure it happens often in stable demo and maybe also in trunk. I have also attached a screen-copy with more information -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Leaks suspect
Hi, From a heap dump automatically created at demo stable crash (using -XX:+HeapDumpOnOutOfMemoryError), I have created a Jira Memory leaks in (at least) stable demo at https://issues.apache.org/jira/browse/OFBIZ-4043 Help appreciated, thanks Jacques
Re: GenericValue.getRelatedOne/Cache
I'm quite sure Adrian and I will not be the only ones interested...
Thanks
Jacques
From: Adrian Crum adri...@hlmksw.com
+1
-Adrian
On 12/2/2010 10:39 PM, Adam Heath wrote:
A while back, I started adding more variants of
GenericDelegator.findByPrimaryKey. The outcome of that was to remove
those variants, and reduce the methods.
However, while looking at unrelated code tonight, I thought we should
do the same to the lookup methods in GenericValue. For instance, I
saw this pattern:
if (booleanValue) {
nextValue = value.getRelatedOneCache(relation);
} else {
nextValue = value.getRelatedOne(relation);
}
I think it would be better to change that to getRelatedOne(relation,
boolean).
Do others agree? What about the other methods in that class?
[jira] Closed: (OFBIZ-4029) commit r1033717 breaks authorize.net processing.
[ https://issues.apache.org/jira/browse/OFBIZ-4029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-4029. -- Close on Rohit's demand commit r1033717 breaks authorize.net processing. Key: OFBIZ-4029 URL: https://issues.apache.org/jira/browse/OFBIZ-4029 Project: OFBiz Issue Type: Bug Components: accounting Affects Versions: SVN trunk Environment: linux, postgres Reporter: Rohit Sureka Assignee: Andrew Zeneski Priority: Blocker hi, i updated my code to the latest version and the commit r1033717 breaks the authorize payment process. i am not sure if we are expected to make any changes to 'authorize dot net' config settings, but if we need to do any changes they are not mentioned in the commit. the problem that i am facing after updating my code to the commit r1033717 is as follows: 1) credit card are properly authorized, but the authorization status is not properly saved in the database. for eg. if the credit card was authorized for $10, in ofbiz is shows only 0. it happens the same for any amount used in authorization. 2) in the reference number field, instead of the of reference number, the ofbiz order number is shown. 3) in the 'Gateway Cv Result' field the reference number is showing instead to the CV result. i assume that the problem is with the storing of the response from authorize dot net into the ofbiz database. the authorization is however successful as we get a confirmation from authorize.net with the correct amount and other details. Thanks, Rohit -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-4025) Is Empty for text-find widget broken
[ https://issues.apache.org/jira/browse/OFBIZ-4025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-4025. -- Resolution: Fixed Fix Version/s: SVN trunk Release Branch 10.04 Assignee: Jacques Le Roux Thanks Anne, Your patch is in trunk at r1042396, R10.04 at r1042402, too much conflicts in R9.04 Is Empty for text-find widget broken Key: OFBIZ-4025 URL: https://issues.apache.org/jira/browse/OFBIZ-4025 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Environment: Rev 1036293 Reporter: Anne Jessel Assignee: Jacques Le Roux Priority: Minor Fix For: Release Branch 10.04, SVN trunk Attachments: OFBIZ-4025_Is-Empty-for-text-find-broken.patch To reproduce: - go to Facility, Inventory Items tab (or any form that uses text-find widget) - choose Is Empty from drop-down next to Product Id - click Find button Expected behaviour: no matching items listed, as all items have a Product Id. Observed behaviour: all items match. Problem is caused by find code assuming that there is no entity condition to be created if the text field is empty, but of course Is Empty is different to the other operators in that the text field is expected to be empty. The attached patch adds a special check for the Is Empty operator. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-4023) Wrong product displayed as associated product
[ https://issues.apache.org/jira/browse/OFBIZ-4023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-4023. -- Resolution: Fixed Fix Version/s: SVN trunk Release Branch 10.04 Release Branch 09.04 Assignee: Jacques Le Roux Thanks Anne, Your patch is in trunk at r1042411, R10.04 at r1042414, R9.04 at r1042418 Wrong product displayed as associated product - Key: OFBIZ-4023 URL: https://issues.apache.org/jira/browse/OFBIZ-4023 Project: OFBiz Issue Type: Bug Components: specialpurpose/ecommerce Affects Versions: SVN trunk Environment: Rev 1035845 Reporter: Anne Jessel Assignee: Jacques Le Roux Priority: Minor Fix For: Release Branch 09.04, Release Branch 10.04, SVN trunk Attachments: OFBIZ-4023_Wrong-product-displayed-as-assoc-product.patch To reproduce: - add two associated products to a main product, both with Complementary or Cross-Sell association type - view the main product in ecommerce Expected behaviour: the two associated products are listed near the bottom of the page Actual behaviour: two products are listed at the bottom of the page, but only one of them is an associated product. The other is the main product. The problem is caused by the value of a freemarker variable changing at a point where other freemarker code assumes the variable does not change. The execution path is complicated. I will attach a patch which does fix the problem, by saving the value of the key variable into another variable, and restoring it later. However I do wonder if there is a better solution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: GenericValue.getRelatedOne/Cache
Jacques Le Roux wrote: I'm quite sure Adrian and I will not be the only ones interested... Figured as much. I just started working on it.
[jira] Commented: (OFBIZ-4021) Adding columns filtering fields in form widget
[ https://issues.apache.org/jira/browse/OFBIZ-4021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12967037#action_12967037 ] Jacques Le Roux commented on OFBIZ-4021: Hi Bruno, Yes, but I did not get a chance to have a look yet... Adding columns filtering fields in form widget -- Key: OFBIZ-4021 URL: https://issues.apache.org/jira/browse/OFBIZ-4021 Project: OFBiz Issue Type: New Feature Components: framework Reporter: Bruno Busco Priority: Minor Attachments: column_filter_disabled.JPG, column_filter_enabled.JPG, content_list.JPG, FilterForm.patch, FilterForm.patch, img_for_tomahawk.zip This patch includes an initial implementation of a list-form column filtering feature. The aim is to add the possibility to configure a list form to show, in its header, some fields that could be used to filter the rows displayed in the form. This is a feature quite standard in many systems and could be seen into OFBiz as a quick search; the standard way of searching using a complete single-type form could be seen as an advanced search. Please find attached to this JIRA two screenshots that show you how the filtering option appears on the screen. *How the user uses this feature* The part of the screen that is normally used for the pagination controls (only the upper one) has been extended so that two icons are shown on the left. The first one (a funnel) is used to show or hide the filtering fields. The second one (a magnifing glass) is used to run the search with the filter content. *How the developer uses this feature* The filtering feature can be enabled on any list-type form specifying the filter-form-name attribute. This must be the name of a form that contains the details about how the filtering fields should be rendered. When a list form with the filter-form-name option set is rendered, any column field is searched for in the filter-form. If a field with the same name is found, its field rendering options are used to render the filter field. A new field attribute filter-field has also been added. This defaults to true but if it is set to false the filter field is not rendered for this column, even if a field with the same name is present in the filter-form. This feature allows to use as filter-form an already existent form such as a regular FindXXX form. In the patch the ListExample form has been changed to use this feature. You can check it there. Unfortunately the patch does not work yet 100% but I hope that if someone finds it interesting could help me. *What is there still to do* 1) There is a FIXME in MacroFormRenderer.java file. I cannot make it work. If I enable the code that is commented there I get an error when a search is run. 2) I cannot make the filtering fields show the actual content after a search is run. They are always rendered as empty. 3) The filter row hide/show status should be saved so that it is maintained after a pagination. I submit this patch as it is becouse I cannot easily improve it further but I hope someone could help. The img_for_tamahawk.zip file includes imgs that should be added in the tomahawk images folder to make the patch work. Thank you for any help! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
findFoo(cache=false), without modification, in a transaction, issue warning
I've noticed several places in the code that issue a findOne(or other find method), without using a cache, but then don't do any modifications to the returned value. Such call sites should really use a caching variant of the delegator. What I'd like to work on, is a feature, only used during development, that would record any value looked up that wasn't cached, and wasn't later modified, and print a warning, with an exception, to allow for a caching variant to be added. Would others find this useful? Obviously, it would need to be transaction based, and would sometimes have false-positives. Additionally, if no transaction is active, then that automatically means a caching variant should be used.
Re: findFoo(cache=false), without modification, in a transaction, issue warning
There are other reasons why you might not want to cache something. Quite a few of them, even without trying to be too creative. For example: memory use. Why cache things like contact mech or order information that isn't likely to be read a very many times, but if cached would take up memory until expired and cleared (and would only be cleared if something is cleaning up expired entries) or until it makes it to the end of the LRU queue or whatever, and the whole time requiring additional resources to keep track of and making more legitimate caching less efficient. Another example: freshness. If you want to be sure the data is good, get it from the db. If it won't cause big problems to have stale data, then the cache is okay. Am I the only one who things caching everything by default (as Marc suggested) or popping out warning messages (as Adam suggests here) is a little crazy? I haven't seen anyone else speak up, so just wondering... -David On Dec 5, 2010, at 7:45 PM, Adam Heath wrote: I've noticed several places in the code that issue a findOne(or other find method), without using a cache, but then don't do any modifications to the returned value. Such call sites should really use a caching variant of the delegator. What I'd like to work on, is a feature, only used during development, that would record any value looked up that wasn't cached, and wasn't later modified, and print a warning, with an exception, to allow for a caching variant to be added. Would others find this useful? Obviously, it would need to be transaction based, and would sometimes have false-positives. Additionally, if no transaction is active, then that automatically means a caching variant should be used.
Re: findFoo(cache=false), without modification, in a transaction, issue warning
David E Jones wrote: There are other reasons why you might not want to cache something. Quite a few of them, even without trying to be too creative. For example: memory use. Why cache things like contact mech or order information that isn't likely to be read a very many times, but if cached would take up memory until expired and cleared (and would only be cleared if something is cleaning up expired entries) or until it makes it to the end of the LRU queue or whatever, and the whole time requiring additional resources to keep track of and making more legitimate caching less efficient. Another example: freshness. If you want to be sure the data is good, get it from the db. If it won't cause big problems to have stale data, then the cache is okay. Am I the only one who things caching everything by default (as Marc suggested) or popping out warning messages (as Adam suggests here) is a little crazy? I haven't seen anyone else speak up, so just wondering... I've got a change queued that has deprecated getRelatedOne(as suggested earlier). While doing that, I also decided to go thru and fix all the remaining findByPrimaryKey, replacing with findOne. During that change, I noticed several FooWorker/FooHelper, that should really be using caching variants. A read-only fetch should be cached. A read-only web request should never hit the database. If it's a question of memory, and a particular install is throwing away cache entries too quickly, then that install needs more memory.
Re: findFoo(cache=false), without modification, in a transaction, issue warning
On Dec 5, 2010, at 8:11 PM, Adam Heath wrote: David E Jones wrote: There are other reasons why you might not want to cache something. Quite a few of them, even without trying to be too creative. For example: memory use. Why cache things like contact mech or order information that isn't likely to be read a very many times, but if cached would take up memory until expired and cleared (and would only be cleared if something is cleaning up expired entries) or until it makes it to the end of the LRU queue or whatever, and the whole time requiring additional resources to keep track of and making more legitimate caching less efficient. Another example: freshness. If you want to be sure the data is good, get it from the db. If it won't cause big problems to have stale data, then the cache is okay. Am I the only one who things caching everything by default (as Marc suggested) or popping out warning messages (as Adam suggests here) is a little crazy? I haven't seen anyone else speak up, so just wondering... I've got a change queued that has deprecated getRelatedOne(as suggested earlier). While doing that, I also decided to go thru and fix all the remaining findByPrimaryKey, replacing with findOne. During that change, I noticed several FooWorker/FooHelper, that should really be using caching variants. Yes, I don't doubt that there is code in OFBiz that could leverage caching more effectively. A read-only fetch should be cached. A read-only web request should never hit the database. Where do these rules come from? How did they become rules? If it's a question of memory, and a particular install is throwing away cache entries too quickly, then that install needs more memory. I guess my points weren't very good if that's all the rebuttal you thought was needed. How about this case: running a little ecommerce site with 100,000 customers. The typical customer visits the site around once per week, though some customers rarely visit the site, maybe a few times per year. A customer logs in, and looks their customer profile, which is 100% read-only (not data is changed as the page loads). They may look at the profile page again if they decide to edit something, but generally will not otherwise. Should all of the data on the profile be cached so that on repeated views we can follow your two rules above (read-only data cached, read-only web request never hit the database (I assume after the first hit, of course))? So, we should all of the customer's contact, order, contact/mailing list, etc information all cached? How much memory are you thinking of... something roughly the same size as the database? Or is the whole point of this to try to argue for in-memory databases... yeah... I see where you're going... And, BTW, this isn't some weird case... for most data in an ERP or ecommerce system this IS the case. In other words, it has a low reads/time-period rate, and a low read to update ratio, and therefore caching is a waste of system resources and more likely to cause issues with bad/stale data (especially across multiple app servers... unless you want to keep all caches perfectly in sync all the time and take the performance hit from that goal, especially making sure other caches are updated before you commit, ie involve the caches in the 2-phase commit so that they are all updated before the data can be committed to the db). -David
Re: findFoo(cache=false), without modification, in a transaction, issue warning
David E Jones wrote: On Dec 5, 2010, at 8:11 PM, Adam Heath wrote: David E Jones wrote: There are other reasons why you might not want to cache something. Quite a few of them, even without trying to be too creative. For example: memory use. Why cache things like contact mech or order information that isn't likely to be read a very many times, but if cached would take up memory until expired and cleared (and would only be cleared if something is cleaning up expired entries) or until it makes it to the end of the LRU queue or whatever, and the whole time requiring additional resources to keep track of and making more legitimate caching less efficient. Another example: freshness. If you want to be sure the data is good, get it from the db. If it won't cause big problems to have stale data, then the cache is okay. Am I the only one who things caching everything by default (as Marc suggested) or popping out warning messages (as Adam suggests here) is a little crazy? I haven't seen anyone else speak up, so just wondering... I've got a change queued that has deprecated getRelatedOne(as suggested earlier). While doing that, I also decided to go thru and fix all the remaining findByPrimaryKey, replacing with findOne. During that change, I noticed several FooWorker/FooHelper, that should really be using caching variants. Yes, I don't doubt that there is code in OFBiz that could leverage caching more effectively. A read-only fetch should be cached. A read-only web request should never hit the database. Where do these rules come from? How did they become rules? If it's a question of memory, and a particular install is throwing away cache entries too quickly, then that install needs more memory. I guess my points weren't very good if that's all the rebuttal you thought was needed. How about this case: running a little ecommerce site with 100,000 customers. The typical customer visits the site around once per week, though some customers rarely visit the site, maybe a few times per year. A customer logs in, and looks their customer profile, which is 100% read-only (not data is changed as the page loads). They may look at the profile page again if they decide to edit something, but generally will not otherwise. Should all of the data on the profile be cached so that on repeated views we can follow your two rules above (read-only data cached, read-only web request never hit the database (I assume after the first hit, of course))? in So, we should all of the customer's contact, order, contact/mailing list, etc information all cached? How much memory are you thinking of... something roughly the same size as the database? Or is the whole point of this to try to argue for in-memory databases... yeah... I see where you're going... And, BTW, this isn't some weird case... for most data in an ERP or ecommerce system this IS the case. In other words, it has a low reads/time-period rate, and a low read to update ratio, and therefore caching is a waste of system resources and more likely to cause issues with bad/stale data (especially across multiple app servers... unless you want to keep all caches perfectly in sync all the time and take the performance hit from that goal, especially making sure other caches are updated before you commit, ie involve the caches in the 2-phase commit so that they are all updated before the data can be committed to the db). Where in the universe does 'should' mean always? I never said all read-only things must be cached. There are definite times during a production install where parts of the system perform exceptionally slow. My suggested change would make it simpler to identify where those slow points are, finding values that are being looked up repeatedly, and changing them to be cached. We currently have a client experiencing timeouts when submitting orders(ofbiz takes more than 2 minutes to process it). Yes, we could increase the default timeout; but that has it's own problems. If we could identify the hot-points, with an easy to use tool, then everyone would benefit. Where is the harm in that? Are you suggesting that because sometimes you don't want to cache some things, that we shouldn't cache anything? segway Lately, I've gotten very bad responses to suggestions of new features(not just from you, David). Someone is wanting to do work, not asking anyone else to implement something for them. Yet, the response to such suggestions are filled with vitriol. If someone is willing to do work, to improve ofbiz, then go ahead and let them. /segway
Re: findFoo(cache=false), without modification, in a transaction, issue warning
I agree with David. An example is the advice he gave me during the development of temporal expressions. I wanted to cache the temporal expression Java structures in memory. David suggested getting the persisted expressions from the entity cache instead. Thinking about it, that made sense - temporal expressions should not change frequently so they are good candidates for entity caching. Entity data that changes frequently should not be cached - because caching it leads to concurrency issues. -Adrian --- On Sun, 12/5/10, David E Jones d...@me.com wrote: There are other reasons why you might not want to cache something. Quite a few of them, even without trying to be too creative. For example: memory use. Why cache things like contact mech or order information that isn't likely to be read a very many times, but if cached would take up memory until expired and cleared (and would only be cleared if something is cleaning up expired entries) or until it makes it to the end of the LRU queue or whatever, and the whole time requiring additional resources to keep track of and making more legitimate caching less efficient. Another example: freshness. If you want to be sure the data is good, get it from the db. If it won't cause big problems to have stale data, then the cache is okay. Am I the only one who things caching everything by default (as Marc suggested) or popping out warning messages (as Adam suggests here) is a little crazy? I haven't seen anyone else speak up, so just wondering... -David On Dec 5, 2010, at 7:45 PM, Adam Heath wrote: I've noticed several places in the code that issue a findOne(or other find method), without using a cache, but then don't do any modifications to the returned value. Such call sites should really use a caching variant of the delegator. What I'd like to work on, is a feature, only used during development, that would record any value looked up that wasn't cached, and wasn't later modified, and print a warning, with an exception, to allow for a caching variant to be added. Would others find this useful? Obviously, it would need to be transaction based, and would sometimes have false-positives. Additionally, if no transaction is active, then that automatically means a caching variant should be used.
Re: findFoo(cache=false), without modification, in a transaction, issue warning
On Dec 5, 2010, at 8:47 PM, Adam Heath wrote: David E Jones wrote: On Dec 5, 2010, at 8:11 PM, Adam Heath wrote: David E Jones wrote: There are other reasons why you might not want to cache something. Quite a few of them, even without trying to be too creative. For example: memory use. Why cache things like contact mech or order information that isn't likely to be read a very many times, but if cached would take up memory until expired and cleared (and would only be cleared if something is cleaning up expired entries) or until it makes it to the end of the LRU queue or whatever, and the whole time requiring additional resources to keep track of and making more legitimate caching less efficient. Another example: freshness. If you want to be sure the data is good, get it from the db. If it won't cause big problems to have stale data, then the cache is okay. Am I the only one who things caching everything by default (as Marc suggested) or popping out warning messages (as Adam suggests here) is a little crazy? I haven't seen anyone else speak up, so just wondering... I've got a change queued that has deprecated getRelatedOne(as suggested earlier). While doing that, I also decided to go thru and fix all the remaining findByPrimaryKey, replacing with findOne. During that change, I noticed several FooWorker/FooHelper, that should really be using caching variants. Yes, I don't doubt that there is code in OFBiz that could leverage caching more effectively. A read-only fetch should be cached. A read-only web request should never hit the database. Where do these rules come from? How did they become rules? If it's a question of memory, and a particular install is throwing away cache entries too quickly, then that install needs more memory. I guess my points weren't very good if that's all the rebuttal you thought was needed. How about this case: running a little ecommerce site with 100,000 customers. The typical customer visits the site around once per week, though some customers rarely visit the site, maybe a few times per year. A customer logs in, and looks their customer profile, which is 100% read-only (not data is changed as the page loads). They may look at the profile page again if they decide to edit something, but generally will not otherwise. Should all of the data on the profile be cached so that on repeated views we can follow your two rules above (read-only data cached, read-only web request never hit the database (I assume after the first hit, of course))? in So, we should all of the customer's contact, order, contact/mailing list, etc information all cached? How much memory are you thinking of... something roughly the same size as the database? Or is the whole point of this to try to argue for in-memory databases... yeah... I see where you're going... And, BTW, this isn't some weird case... for most data in an ERP or ecommerce system this IS the case. In other words, it has a low reads/time-period rate, and a low read to update ratio, and therefore caching is a waste of system resources and more likely to cause issues with bad/stale data (especially across multiple app servers... unless you want to keep all caches perfectly in sync all the time and take the performance hit from that goal, especially making sure other caches are updated before you commit, ie involve the caches in the 2-phase commit so that they are all updated before the data can be committed to the db). Where in the universe does 'should' mean always? I never said all read-only things must be cached. There are definite times during a production install where parts of the system perform exceptionally slow. My suggested change would make it simpler to identify where those slow points are, finding values that are being looked up repeatedly, and changing them to be cached. We currently have a client experiencing timeouts when submitting orders(ofbiz takes more than 2 minutes to process it). Yes, we could increase the default timeout; but that has it's own problems. If we could identify the hot-points, with an easy to use tool, then everyone would benefit. Where is the harm in that? If it's not really the problem, then maybe it would do more harm than good, like massively increasing log message volume without helping you get valuable information. I actually just recently worked with a client who had a big performance problem on add to cart and it turned out that the problem was caching too much stuff which resulted in less important data pushing important data out of memory as the heap memory started getting full. There's always a trade-off... Are you suggesting that because sometimes you don't want to cache some things, that we shouldn't cache anything? Is that what it sounded like I wrote, or is this just a random thought? segway Lately, I've gotten very bad responses to suggestions of
Re: findFoo(cache=false), without modification, in a transaction, issue warning
David E Jones wrote: On Dec 5, 2010, at 8:47 PM, Adam Heath wrote: David E Jones wrote: On Dec 5, 2010, at 8:11 PM, Adam Heath wrote: David E Jones wrote: There are other reasons why you might not want to cache something. Quite a few of them, even without trying to be too creative. For example: memory use. Why cache things like contact mech or order information that isn't likely to be read a very many times, but if cached would take up memory until expired and cleared (and would only be cleared if something is cleaning up expired entries) or until it makes it to the end of the LRU queue or whatever, and the whole time requiring additional resources to keep track of and making more legitimate caching less efficient. Another example: freshness. If you want to be sure the data is good, get it from the db. If it won't cause big problems to have stale data, then the cache is okay. Am I the only one who things caching everything by default (as Marc suggested) or popping out warning messages (as Adam suggests here) is a little crazy? I haven't seen anyone else speak up, so just wondering... I've got a change queued that has deprecated getRelatedOne(as suggested earlier). While doing that, I also decided to go thru and fix all the remaining findByPrimaryKey, replacing with findOne. During that change, I noticed several FooWorker/FooHelper, that should really be using caching variants. Yes, I don't doubt that there is code in OFBiz that could leverage caching more effectively. A read-only fetch should be cached. A read-only web request should never hit the database. Where do these rules come from? How did they become rules? If it's a question of memory, and a particular install is throwing away cache entries too quickly, then that install needs more memory. I guess my points weren't very good if that's all the rebuttal you thought was needed. How about this case: running a little ecommerce site with 100,000 customers. The typical customer visits the site around once per week, though some customers rarely visit the site, maybe a few times per year. A customer logs in, and looks their customer profile, which is 100% read-only (not data is changed as the page loads). They may look at the profile page again if they decide to edit something, but generally will not otherwise. Should all of the data on the profile be cached so that on repeated views we can follow your two rules above (read-only data cached, read-only web request never hit the database (I assume after the first hit, of course))? in So, we should all of the customer's contact, order, contact/mailing list, etc information all cached? How much memory are you thinking of... something roughly the same size as the database? Or is the whole point of this to try to argue for in-memory databases... yeah... I see where you're going... And, BTW, this isn't some weird case... for most data in an ERP or ecommerce system this IS the case. In other words, it has a low reads/time-period rate, and a low read to update ratio, and therefore caching is a waste of system resources and more likely to cause issues with bad/stale data (especially across multiple app servers... unless you want to keep all caches perfectly in sync all the time and take the performance hit from that goal, especially making sure other caches are updated before you commit, ie involve the caches in the 2-phase commit so that they are all updated before the data can be committed to the db). Where in the universe does 'should' mean always? I never said all read-only things must be cached. There are definite times during a production install where parts of the system perform exceptionally slow. My suggested change would make it simpler to identify where those slow points are, finding values that are being looked up repeatedly, and changing them to be cached. We currently have a client experiencing timeouts when submitting orders(ofbiz takes more than 2 minutes to process it). Yes, we could increase the default timeout; but that has it's own problems. If we could identify the hot-points, with an easy to use tool, then everyone would benefit. Where is the harm in that? If it's not really the problem, then maybe it would do more harm than good, like massively increasing log message volume without helping you get valuable information. I actually just recently worked with a client who had a big performance problem on add to cart and it turned out that the problem was caching too much stuff which resulted in less important data pushing important data out of memory as the heap memory started getting full. There's always a trade-off... Are you suggesting that because sometimes you don't want to cache some things, that we shouldn't cache anything? Is that what it sounded like I wrote, or is this just a random thought? segway Lately, I've gotten very bad responses
Re: findFoo(cache=false), without modification, in a transaction, issue warning
Adrian Crum wrote: I agree with David. An example is the advice he gave me during the development of temporal expressions. I wanted to cache the temporal expression Java structures in memory. David suggested getting the persisted expressions from the entity cache instead. Thinking about it, that made sense - temporal expressions should not change frequently so they are good candidates for entity caching. Storing them in the entity cache *is* storing them in memory. Are you iterating the entity values, building up some complex object? If so, then use Delegator.getCache().put(String, EntityCondition, String, Object). That allows you to add a complex built-up java object into the same internal cache that is storing the list of cached results from a condition lookup. Entity data that changes frequently should not be cached - because caching it leads to concurrency issues. Well, duh. This feature would be used to find values that are being looked up repeatedly, not changing, and not being cached. How else would it be used?
Re: findFoo(cache=false), without modification, in a transaction, issue warning
--- On Sun, 12/5/10, Adam Heath doo...@brainfood.com wrote: Again, why are people pushing back on this? It hurts no one, and could find cases where caching actually would help. Really, what is the harm? I can only speak for myself. I push back on entity caching stuff because I feel it is redundant. Database systems cache data. Those database systems run on top of operating systems that cache data. It seems to me that it's redundant to cache data entity data at the application level. I'm not an expert on the subject, I'm just suggesting that caching optimization should be done at a lower level. Entity caching seems to me to be a form of premature optimization. -Adrian
Re: findFoo(cache=false), without modification, in a transaction, issue warning
--- On Sun, 12/5/10, Adam Heath doo...@brainfood.com wrote: Adrian Crum wrote: I agree with David. An example is the advice he gave me during the development of temporal expressions. I wanted to cache the temporal expression Java structures in memory. David suggested getting the persisted expressions from the entity cache instead. Thinking about it, that made sense - temporal expressions should not change frequently so they are good candidates for entity caching. Storing them in the entity cache *is* storing them in memory. Are you iterating the entity values, building up some complex object? If so, then use Delegator.getCache().put(String, EntityCondition, String, Object). That allows you to add a complex built-up java object into the same internal cache that is storing the list of cached results from a condition lookup. Entity data that changes frequently should not be cached - because caching it leads to concurrency issues. Well, duh. This feature would be used to find values that are being looked up repeatedly, not changing, and not being cached. How else would it be used? I admit, I confused this thread with another and went off on a tangent. Some kind of performance metric attached to the entity caching mechanism would be worthwhile - so one could use the entity cache only where needed. -Adrian
Re: findFoo(cache=false), without modification, in a transaction, issue warning
On Dec 5, 2010, at 9:26 PM, Adrian Crum wrote: --- On Sun, 12/5/10, Adam Heath doo...@brainfood.com wrote: Again, why are people pushing back on this? It hurts no one, and could find cases where caching actually would help. Really, what is the harm? I can only speak for myself. I push back on entity caching stuff because I feel it is redundant. Database systems cache data. Those database systems run on top of operating systems that cache data. It seems to me that it's redundant to cache data entity data at the application level. I'm not an expert on the subject, I'm just suggesting that caching optimization should be done at a lower level. Entity caching seems to me to be a form of premature optimization. There is a lot of value of caching on the app server for frequently used or performance sensitive data where stale data isn't such a concern. For most caches the whole point of the cache is to keep the data as close to where it is used as possible so that it is cheaper/faster to get. For example caches built into hard disks don't make much sense from that perspective. However, really caches built into hard disks serve a different purpose such as read-ahead buffering and such as opposed to caching data that has already been read just in case it is read again (which operating systems do for certain things, databases for other things, and app servers for others, as they should... and hard disk caches shouldn't). -David
Re: findFoo(cache=false), without modification, in a transaction, issue warning
On 6/12/2010, at 6:21 PM, Adam Heath wrote: Adrian Crum wrote: I agree with David. An example is the advice he gave me during the development of temporal expressions. I wanted to cache the temporal expression Java structures in memory. David suggested getting the persisted expressions from the entity cache instead. Thinking about it, that made sense - temporal expressions should not change frequently so they are good candidates for entity caching. Storing them in the entity cache *is* storing them in memory. Are you iterating the entity values, building up some complex object? If so, then use Delegator.getCache().put(String, EntityCondition, String, Object). That allows you to add a complex built-up java object into the same internal cache that is storing the list of cached results from a condition lookup. Thanks for pointing this out, I wasn't aware of it and I can think of a fair few places where something like this could be put to use. Using it in place of some of the recent fixes to caching of freemarker template objects originating from Content records is the first that comes to mind. Regards Scott smime.p7s Description: S/MIME cryptographic signature
Re: findFoo(cache=false), without modification, in a transaction, issue warning
Scott Gray wrote: On 6/12/2010, at 6:21 PM, Adam Heath wrote: Adrian Crum wrote: I agree with David. An example is the advice he gave me during the development of temporal expressions. I wanted to cache the temporal expression Java structures in memory. David suggested getting the persisted expressions from the entity cache instead. Thinking about it, that made sense - temporal expressions should not change frequently so they are good candidates for entity caching. Storing them in the entity cache *is* storing them in memory. Are you iterating the entity values, building up some complex object? If so, then use Delegator.getCache().put(String, EntityCondition, String, Object). That allows you to add a complex built-up java object into the same internal cache that is storing the list of cached results from a condition lookup. Thanks for pointing this out, I wasn't aware of it and I can think of a fair few places where something like this could be put to use. Using it in place of some of the recent fixes to caching of freemarker template objects originating from Content records is the first that comes to mind. I'm the one who wrote this feature years and years ago. However, there is a race condition. It's possible that between the time you fetch the list of generic values, and get around to storing the complex object graph, the original list of values has been cleared. The fix is to add some kind of concurrent api, putIfAbsent or some such. I haven't thought in detail about the fix, I just know the problem could happen in theory.
Re: Calling selenium from the build XML was jquey
Le 05/12/2010 13:02, Sascha Rodekamp a écrit : Hi BJ, sorry for the late response, but i was not at home yesterday. :-). That was more or less a POC. I tried to create a showcase to test standard Application Screens (i.e. a standard ecommerce module). Therefore i created the unit tests with the selenium firefox plugin, modifyed the tests for my purposes and used them in a little selfmade testing framework. That was very simple. It reads test data (i.e user data, orders which should be placed ...) from an excel file (Apache POI), creates a list with the neded data and called the tests class with the unit tests, from this point selenium did all the work, run the test and give me a result. That's it. Maybe a little bit uncommon but as i said it was a POC for a certain use case :-) But at the end of the day a think there is a lot of stuff / test cases which can be handled by selenium, but i also noticed that it is a lot of work creating all the tests... Hope you get an idea what i was trying to do. Have a good day Sascha Hi Sascha, would it be possible to put all of this in a JIRA issue ? I may need some of this, and I may also need it to clarify what I want from Selenium in OFBiz (and work on it later...). Cheers, -- Erwan de FERRIERES www.nereide.biz
Re: Calling selenium from the build XML was jquey
Le 05/12/2010 13:02, Sascha Rodekamp a écrit : Hi BJ, sorry for the late response, but i was not at home yesterday. :-). That was more or less a POC. I tried to create a showcase to test standard Application Screens (i.e. a standard ecommerce module). Therefore i created the unit tests with the selenium firefox plugin, modifyed the tests for my purposes and used them in a little selfmade testing framework. That was very simple. It reads test data (i.e user data, orders which should be placed ...) from an excel file (Apache POI), creates a list with the neded data and called the tests class with the unit tests, from this point selenium did all the work, run the test and give me a result. That's it. Maybe a little bit uncommon but as i said it was a POC for a certain use case :-) But at the end of the day a think there is a lot of stuff / test cases which can be handled by selenium, but i also noticed that it is a lot of work creating all the tests... Hope you get an idea what i was trying to do. Have a good day Sascha Hi Sascha, would it be possible to put all of this in a JIRA issue ? I may need some of this, and I may also need it to clarify what I want from Selenium in OFBiz (and work on it later...). Cheers, -- Erwan de FERRIERES www.nereide.biz
