Struts 2
  1. Struts 2
  2. WW-3580

Critical performance issue in production environment as thread dumps are leading to OGNL 3.0 thread blocking! Website could be backed out!

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.3.1
    • Component/s: None
    • Labels:
      None
    • Environment:

      Struts 2.2.1

      Description

      My web application based on Struts 2.2.1 is using OGNL 3.0. This web application is rolled into production; however, due to serious performance considerations the website is in danger of being rolled back. The thread dumps indicate 'BLOCKING' at ognl.OgnlRuntime.invokeMethod(OgnlRuntime.java:804).

      The thread trace is as:
      "httpSSLWorkerThread-6357-6" daemon prio=3 tid=0x01a07000 nid=0xa6 waiting for monitor entry [0xb6d79000..0xb6d7faf0]
      java.lang.Thread.State: BLOCKED (on object monitor)
      at ognl.OgnlRuntime.invokeMethod(OgnlRuntime.java:804)

      • waiting to lock <0xcca6d328> (a java.lang.reflect.Method)
        at ognl.OgnlRuntime.getMethodValue(OgnlRuntime.java:1434)
        at ognl.ObjectPropertyAccessor.getPossibleProperty(ObjectPropertyAccessor.java:60)
        at ognl.ObjectPropertyAccessor.getProperty(ObjectPropertyAccessor.java:147)
        at com.opensymphony.xwork2.ognl.accessor.ObjectAccessor.getProperty(ObjectAccessor.java:17)
        at ognl.OgnlRuntime.getProperty(OgnlRuntime.java:2230)
        at com.opensymphony.xwork2.ognl.accessor.CompoundRootAccessor.getProperty(CompoundRootAccessor.java:137)
        at ognl.OgnlRuntime.getProperty(OgnlRuntime.java:2230)
        at ognl.ASTProperty.getValueBody(ASTProperty.java:114)
        at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:212)
        at ognl.SimpleNode.getValue(SimpleNode.java:258)
        at ognl.Ognl.getValue(Ognl.java:494)
        at ognl.Ognl.getValue(Ognl.java:458)
        at com.opensymphony.xwork2.ognl.OgnlUtil.getValue(OgnlUtil.java:213)
        at com.opensymphony.xwork2.ognl.OgnlValueStack.getValueUsingOgnl(OgnlValueStack.java:277)
        at com.opensymphony.xwork2.ognl.OgnlValueStack.tryFindValue(OgnlValueStack.java:260)
        at com.opensymphony.xwork2.ognl.OgnlValueStack.tryFindValueWhenExpressionIsNotNull(OgnlValueStack.java:242)
        at com.opensymphony.xwork2.ognl.OgnlValueStack.findValue(OgnlValueStack.java:222)
        at com.opensymphony.xwork2.ognl.OgnlValueStack.findValue(OgnlValueStack.java:284)
        at sun.reflect.GeneratedMethodAccessor111.invoke(Unknown Source)
        ....

      quot;httpSSLWorkerThread-6357-4" daemon prio=3 tid=0x01a56800 nid=0xa4 runnable [0xb6f79000..0xb6f7fbf0]
      java.lang.Thread.State: RUNNABLE
      at java.security.AccessController.$$YJP$$doPrivileged(Native Method)
      at java.security.AccessController.doPrivileged(AccessController.java)
      at com.sun.enterprise.security.provider.PolicyFile.addPermissions(PolicyFile.java:1333)
      at com.sun.enterprise.security.provider.PolicyFile.getPermissions(PolicyFile.java:1290)
      at com.sun.enterprise.security.provider.PolicyFile.getPermissions(PolicyFile.java:1256)
      at com.sun.enterprise.security.provider.PolicyFile.getPermissions(PolicyFile.java:1198)
      at com.sun.enterprise.security.provider.PolicyFile.implies(PolicyFile.java:1153)
      at com.sun.enterprise.security.provider.BasePolicyWrapper.doImplies(BasePolicyWrapper.java:383)
      at com.sun.enterprise.security.provider.BasePolicyWrapper.implies(BasePolicyWrapper.java:237)
      at java.security.ProtectionDomain.implies(ProtectionDomain.java:213)
      at java.security.AccessControlContext.checkPermission(AccessControlContext.java:301)
      at java.security.AccessController.checkPermission(AccessController.java:546)
      at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
      at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:107)
      at ognl.OgnlRuntime.invokeMethod(OgnlRuntime.java:839)

      • locked <0xcca6d328> (a java.lang.reflect.Method)
        at ognl.OgnlRuntime.getMethodValue(OgnlRuntime.java:1434)
        at ognl.ObjectPropertyAccessor.getPossibleProperty(ObjectPropertyAccessor.java:60)
      1. OGNLIssue.zip
        5 kB
        Shishir Saxena
      2. ognl-synchronization.diff
        35 kB
        Alessio Cicioni
      3. Small_bugfix_on_the_performance_patch_provided_in_WW-3580_.patch
        36 kB
        Philip Luppens
      4. stacktrace_ognl_issue.txt
        27 kB
        Shishir Saxena

        Issue Links

          Activity

          Hide
          Lukasz Lenart added a comment -

          Did you try to ask on the User Group ?
          Could you post the whole stack trace ?
          Did you measure your application with profiler or so ?
          Maybe it's something in the application ?

          (my magic ball is broken )

          Show
          Lukasz Lenart added a comment - Did you try to ask on the User Group ? Could you post the whole stack trace ? Did you measure your application with profiler or so ? Maybe it's something in the application ? (my magic ball is broken )
          Hide
          Shishir Saxena added a comment -

          My replies:
          <Did you try to ask on the User Group ?> Yes!

          <Could you post the whole stack trace ?> Attached!

          <Did you measure your application with profiler or so ?> Yes, I have profiled my application; removed some unnecessary interceptors. Now, I do not see any eye poping issue there. However, I will like to add here that I have taken out Struts components out of scope for profiling. Hope, thats alright?!!

          <Maybe it's something in the application ?> We are looking at application aspects as well as infrastructure aspect.

          There was a similar issue created in OGNL JIRA (http://jira.opensymphony.com/browse/OGNL-141) as well regarding scalability and as per the issue updates, it has been resolved in OGNL 3.0. I hope that is the case [anyways, I have updated that JIRA page as well :-) ]

          Show
          Shishir Saxena added a comment - My replies: <Did you try to ask on the User Group ?> Yes! <Could you post the whole stack trace ?> Attached! <Did you measure your application with profiler or so ?> Yes, I have profiled my application; removed some unnecessary interceptors. Now, I do not see any eye poping issue there. However, I will like to add here that I have taken out Struts components out of scope for profiling. Hope, thats alright?!! <Maybe it's something in the application ?> We are looking at application aspects as well as infrastructure aspect. There was a similar issue created in OGNL JIRA ( http://jira.opensymphony.com/browse/OGNL-141 ) as well regarding scalability and as per the issue updates, it has been resolved in OGNL 3.0. I hope that is the case [anyways, I have updated that JIRA page as well :-) ]
          Hide
          Shishir Saxena added a comment -

          This contains MainAppLogin.jsp and StartMainApp which are causing thread dumps. This would help for further analysis.

          Show
          Shishir Saxena added a comment - This contains MainAppLogin.jsp and StartMainApp which are causing thread dumps. This would help for further analysis.
          Hide
          Shishir Saxena added a comment -

          In my above comment, 'This' means attachment OGNLIssue.zip.

          Show
          Shishir Saxena added a comment - In my above comment, 'This' means attachment OGNLIssue.zip.
          Hide
          Alessio Cicioni added a comment -

          Is someone working on this?
          We are facing the same problem with Struts 2 (2.1.8.1) in a production environment with heavy load (thousands of contemporary users).
          We changed the OGNL library (using OGNL 3.0) in the STRUTS distribution. The performance are better, but the problem is still there when there are more than 300 contemporary users.
          Is there a plan to resolve this issue? In which version and when such version is planned to be released?
          Thanks

          Show
          Alessio Cicioni added a comment - Is someone working on this? We are facing the same problem with Struts 2 (2.1.8.1) in a production environment with heavy load (thousands of contemporary users). We changed the OGNL library (using OGNL 3.0) in the STRUTS distribution. The performance are better, but the problem is still there when there are more than 300 contemporary users. Is there a plan to resolve this issue? In which version and when such version is planned to be released? Thanks
          Hide
          Maurizio Cucchiara added a comment -

          Ciao Alessio,
          we (the OGNL team) are going to work on this.
          It would be very useful for me to know if you guys are able to systematically reproduce the issue or alternatively whether there are particular conditions under which the deadlock occurrs.

          Show
          Maurizio Cucchiara added a comment - Ciao Alessio, we (the OGNL team) are going to work on this. It would be very useful for me to know if you guys are able to systematically reproduce the issue or alternatively whether there are particular conditions under which the deadlock occurrs.
          Hide
          Alessio Cicioni added a comment -

          Ciao Maurizio,
          we're able to systematically reproduce the issue through our tests.
          While waiting for your (Struts or OGNL team) response, we have tried to solve the issue.

          We found that the problem was already been discovered (see http://jira.opensymphony.com/browse/OGNL-101).
          So we have tried to apply the attached patch (with some changes because this patch was for the 2.7 version) to the 3.0 source code.

          With this patched OGNL 3.0 library the problem has gone!
          If you think useful we can send you the patch.

          Here are the results for our application using a test scenario with 700 concurrent users...

          With STRUTS 2.1.8.1 official release --> mean time per request = 6,5 seconds ---> threads blocking
          With STRUTS 2.1.8.1 with OGNL 3.0 library --> mean time per request = 2 seconds ----> some threads still blocking
          With STRUTS 2.1.8.1 with OGNL 3.0 library + patch --> mean time per request = 0,2 seconds ---> no threads blocking

          As you can see the improvement is astonishing.

          Show
          Alessio Cicioni added a comment - Ciao Maurizio, we're able to systematically reproduce the issue through our tests. While waiting for your (Struts or OGNL team) response, we have tried to solve the issue. We found that the problem was already been discovered (see http://jira.opensymphony.com/browse/OGNL-101 ). So we have tried to apply the attached patch (with some changes because this patch was for the 2.7 version) to the 3.0 source code. With this patched OGNL 3.0 library the problem has gone! If you think useful we can send you the patch. Here are the results for our application using a test scenario with 700 concurrent users... With STRUTS 2.1.8.1 official release --> mean time per request = 6,5 seconds ---> threads blocking With STRUTS 2.1.8.1 with OGNL 3.0 library --> mean time per request = 2 seconds ----> some threads still blocking With STRUTS 2.1.8.1 with OGNL 3.0 library + patch --> mean time per request = 0,2 seconds ---> no threads blocking As you can see the improvement is astonishing.
          Hide
          Maurizio Cucchiara added a comment -

          It is great to hear it from you.
          Please, be aware that we are working on the 4.x version of OGNL.
          Anyway, it should not be difficult to apply your patch against it.
          It looks like your test is an application-specific test, hence we cannot run without your app. Can you confirm, please?
          Needless to say that every kind of contribution will be welcome.
          TIA.

          Show
          Maurizio Cucchiara added a comment - It is great to hear it from you. Please, be aware that we are working on the 4.x version of OGNL. Anyway, it should not be difficult to apply your patch against it. It looks like your test is an application-specific test, hence we cannot run without your app. Can you confirm, please? Needless to say that every kind of contribution will be welcome. TIA.
          Hide
          Alessio Cicioni added a comment -

          We found the code for the 3.x branch on https://github.com/jkuhnert/ognl
          So we used that code.

          Even if the problem is solved I think that Struts is not usable in heavy load sites if you/we do not solve this issue in OGNL and then don't release a new version of STRUTS including this new version of OGNL.

          I don't know your release plans for the release of the 4.x version, but (for us and for everyone using STRUTS in production environment) a 3.0.x maintenance release of OGNL with this fix and a maintenance release of STRUTS would be highly useful and reccomended.

          To answer your question...
          Yes, our test is application-specific, we use an ad-hoc appliance to test our app, but we can support you we some test if needed.

          Show
          Alessio Cicioni added a comment - We found the code for the 3.x branch on https://github.com/jkuhnert/ognl So we used that code. Even if the problem is solved I think that Struts is not usable in heavy load sites if you/we do not solve this issue in OGNL and then don't release a new version of STRUTS including this new version of OGNL. I don't know your release plans for the release of the 4.x version, but (for us and for everyone using STRUTS in production environment) a 3.0.x maintenance release of OGNL with this fix and a maintenance release of STRUTS would be highly useful and reccomended. To answer your question... Yes, our test is application-specific, we use an ad-hoc appliance to test our app, but we can support you we some test if needed.
          Hide
          Alessio Cicioni added a comment -

          This is the patch we have applied to the OGNL 3.x source code.

          Show
          Alessio Cicioni added a comment - This is the patch we have applied to the OGNL 3.x source code.
          Hide
          Adam Ruggles added a comment -

          @Alessio

          Do you know where I can get a snapshot of OGNL 3.x with that patch applied?

          Show
          Adam Ruggles added a comment - @Alessio Do you know where I can get a snapshot of OGNL 3.x with that patch applied?
          Hide
          Maurizio Cucchiara added a comment -

          Adam,
          as far as I know there is no place where you can get the patched version of the OGNL 3.x.
          You can get the 3.X version from here and apply the patch by yourself.
          Be aware that:

          1. we (both the OGNL and Struts team) are working to ship the 4.X version
          2. Actually, applying the patch breaks about 10 test, if I recall correctly.
          Show
          Maurizio Cucchiara added a comment - Adam, as far as I know there is no place where you can get the patched version of the OGNL 3.x. You can get the 3.X version from here and apply the patch by yourself. Be aware that: we (both the OGNL and Struts team) are working to ship the 4.X version Actually, applying the patch breaks about 10 test, if I recall correctly.
          Hide
          Alessio Cicioni added a comment -

          @Adam
          Maurizio is right. We downloaded it from github and then applied our patch.

          @Maurizio,
          from what you say I suppose that you (OGNL and STRUTS team) are not going to release a manteinance release for the current version, but resolve this issue in the trunk. Correct?

          If so, when do you think you will able to release this version?
          Thanks.

          Show
          Alessio Cicioni added a comment - @Adam Maurizio is right. We downloaded it from github and then applied our patch. @Maurizio, from what you say I suppose that you (OGNL and STRUTS team) are not going to release a manteinance release for the current version, but resolve this issue in the trunk. Correct? If so, when do you think you will able to release this version? Thanks.
          Hide
          Maurizio Cucchiara added a comment -

          Ciao Alessio,
          I don't know what the release plans for S2 and OGNL are at the moment.
          Three things I can tell you are so far:

          1. we are working on OGNL to solve the issue (there is already a patch, see OGNL-20) and we are also considering your contribute.
          2. there is a strong enthusiasm to release the first version of the OGNL under the commons guidance.
          3. There is a shade profile (see OGNL-16) which allows to replace the old version of OGNL on the current release of S2, without changing a single line of the code (just replacing the generated library along the classpath).
          Show
          Maurizio Cucchiara added a comment - Ciao Alessio, I don't know what the release plans for S2 and OGNL are at the moment. Three things I can tell you are so far: we are working on OGNL to solve the issue (there is already a patch, see OGNL-20 ) and we are also considering your contribute. there is a strong enthusiasm to release the first version of the OGNL under the commons guidance. There is a shade profile (see OGNL-16 ) which allows to replace the old version of OGNL on the current release of S2, without changing a single line of the code (just replacing the generated library along the classpath).
          Hide
          Lukasz Lenart added a comment -

          I can release a new 3.0.3 version with the patch applied, but all the tests have to be fixed as well.

          Show
          Lukasz Lenart added a comment - I can release a new 3.0.3 version with the patch applied, but all the tests have to be fixed as well.
          Hide
          Philip Luppens added a comment - - edited

          I spotted the bug in the performance patch that solves the problem with the failing tests. It was a simple matter of not setting the return value after a Field was found.

          I've attached the performance patch + fix for the tests. I really, really hope we can get this released quickly. Sorry for not putting it on Github, but I don't have access from work.

          Show
          Philip Luppens added a comment - - edited I spotted the bug in the performance patch that solves the problem with the failing tests. It was a simple matter of not setting the return value after a Field was found. I've attached the performance patch + fix for the tests. I really, really hope we can get this released quickly. Sorry for not putting it on Github, but I don't have access from work.
          Hide
          Lukasz Lenart added a comment -

          3.0.3-SNAPSHOT is ready [1], could anyone to test it before I will release ?

          https://oss.sonatype.org/content/repositories/snapshots/ognl/ognl/

          Show
          Lukasz Lenart added a comment - 3.0.3-SNAPSHOT is ready [1] , could anyone to test it before I will release ? https://oss.sonatype.org/content/repositories/snapshots/ognl/ognl/
          Hide
          Lukasz Lenart added a comment -

          Struts 2 build passed without exception but a test on a real heavy loaded applications would be better

          Show
          Lukasz Lenart added a comment - Struts 2 build passed without exception but a test on a real heavy loaded applications would be better
          Hide
          Philip Luppens added a comment - - edited

          Just for reference (and anyone that might visit this thread before a new stable build is released): can you give the link to download that Struts2 build? We've got a setup to do some quick loadtesting, so we might schedule a run on Wednesday. But our initial tests are looking very good.

          Show
          Philip Luppens added a comment - - edited Just for reference (and anyone that might visit this thread before a new stable build is released): can you give the link to download that Struts2 build? We've got a setup to do some quick loadtesting, so we might schedule a run on Wednesday. But our initial tests are looking very good.
          Hide
          Maurizio Cucchiara added a comment -

          I thinks there is not yet (Lukasz correct me if I am wrong) a S2 version shipped with ognl snapshot, but you can simply:

          replace your ognl along your classpath
          adjust your maven setting

          Show
          Maurizio Cucchiara added a comment - I thinks there is not yet (Lukasz correct me if I am wrong) a S2 version shipped with ognl snapshot, but you can simply: replace your ognl along your classpath adjust your maven setting
          Hide
          Philip Luppens added a comment -

          That's what we did right now, but it might be a good idea to get a build out so more people can test it easily. I doubt our case alone will be sufficient.

          Show
          Philip Luppens added a comment - That's what we did right now, but it might be a good idea to get a build out so more people can test it easily. I doubt our case alone will be sufficient.
          Hide
          Lukasz Lenart added a comment -

          Ok, I'll push OGNL 3.0.3 to Central and then change the version in Struts2

          Show
          Lukasz Lenart added a comment - Ok, I'll push OGNL 3.0.3 to Central and then change the version in Struts2
          Hide
          Philip Luppens added a comment -

          Thank you, Lukasz.

          Show
          Philip Luppens added a comment - Thank you, Lukasz.
          Hide
          Alessio Cicioni added a comment -

          Thank you all, we will replace ognl 3.0.0 + our patch with OGNL 3.0.3 in our Struts 2.1.8.1 distribution.
          We will test it with our test appliance in the same scenario and let you know...

          Show
          Alessio Cicioni added a comment - Thank you all, we will replace ognl 3.0.0 + our patch with OGNL 3.0.3 in our Struts 2.1.8.1 distribution. We will test it with our test appliance in the same scenario and let you know...
          Hide
          Hudson added a comment -

          Integrated in Struts2 #360 (See https://builds.apache.org/job/Struts2/360/)
          WW-3580 - upgrades OGNL to version 3.0.3 to improve performance

          lukaszlenart :
          Files :

          • /struts/struts2/trunk/pom.xml
          Show
          Hudson added a comment - Integrated in Struts2 #360 (See https://builds.apache.org/job/Struts2/360/ ) WW-3580 - upgrades OGNL to version 3.0.3 to improve performance lukaszlenart : Files : /struts/struts2/trunk/pom.xml
          Hide
          Shishir Saxena added a comment -

          Thanks Alessio for the help.

          Regards
          Shishir Bhasker Saxena
          Tata Consultancy Services
          Gateway Park, Road No.13
          MIDC, Andheri (E)
          Mumbai - 400093,Maharashtra
          India
          Mailto: shishir.saxena@tcs.com
          Website: http://www.tcs.com

          Show
          Shishir Saxena added a comment - Thanks Alessio for the help. Regards Shishir Bhasker Saxena Tata Consultancy Services Gateway Park, Road No.13 MIDC, Andheri (E) Mumbai - 400093,Maharashtra India Mailto: shishir.saxena@tcs.com Website: http://www.tcs.com
          Hide
          Lukasz Lenart added a comment -

          Done, OGNL 3.0.3 is in Central and you try it out with Struts 2.3.1-SNAPSHOT

          Show
          Lukasz Lenart added a comment - Done, OGNL 3.0.3 is in Central and you try it out with Struts 2.3.1-SNAPSHOT
          Hide
          Alessio Cicioni added a comment -

          Just to say that our tests has been successful (Struts 2.1.8.1 + OGNL 3.0.3) with 700 concurrent users.
          Do you think we will have an official 2.1.8.x manteinance release?

          Thanks
          Alessio

          Show
          Alessio Cicioni added a comment - Just to say that our tests has been successful (Struts 2.1.8.1 + OGNL 3.0.3) with 700 concurrent users. Do you think we will have an official 2.1.8.x manteinance release? Thanks Alessio
          Hide
          Maurizio Cucchiara added a comment -

          Alessio,
          I don't see any problems to release a new version based on 2.1.8.x branch, but, for the sake of curiosity, may I ask you why don't you use the latest S2 version?
          is it a corporate policy?

          Show
          Maurizio Cucchiara added a comment - Alessio, I don't see any problems to release a new version based on 2.1.8.x branch, but, for the sake of curiosity, may I ask you why don't you use the latest S2 version? is it a corporate policy?
          Hide
          Lukasz Lenart added a comment -

          Alessio
          Why should we do this ? Just to have a bundle with OGNL 3.0.3 ?

          Show
          Lukasz Lenart added a comment - Alessio Why should we do this ? Just to have a bundle with OGNL 3.0.3 ?
          Hide
          Lukasz Lenart added a comment -

          to follow up, Struts 2 didn't change at all ...

          Show
          Lukasz Lenart added a comment - to follow up, Struts 2 didn't change at all ...
          Hide
          Alessio Cicioni added a comment -

          Hi all,
          first of all thanks for your support....

          @Maurizio: our environment is very critical (thousands of concurrent users) and the system is already on-line. Each change in a component or library must be authorized by the customer and obviously must pass lots of functional and stress tests. So changing the Struts version requires some development and lots of tests. We had to solve the problem in production environment and then start evolving towards Struts 2.3.x.

          @Lukasz: Yes, it would be an official Struts release resolving this performance problem for everyone using Struts 2.1.8.1 in a production environment with hundreds/thousands of concurrent users. So they can avoid searching JIRA and changing the OGNL library to resolve this issue...

          Just another thing we found yesterday....(so maybe it's better to wait to release an "official" Struts release)
          Pushing the stress tests above 700 concurrent users (around 1000 concurrent users) we found a similar problem with the Freemarker library...
          We have updated Freemarker to the 2.3.18 version and applied a patch to the freemarker.ext.beans.BeansWrapper class.
          We will let you know if the tests are successful and the problem is solved...

          Show
          Alessio Cicioni added a comment - Hi all, first of all thanks for your support.... @Maurizio: our environment is very critical (thousands of concurrent users) and the system is already on-line. Each change in a component or library must be authorized by the customer and obviously must pass lots of functional and stress tests. So changing the Struts version requires some development and lots of tests. We had to solve the problem in production environment and then start evolving towards Struts 2.3.x. @Lukasz: Yes, it would be an official Struts release resolving this performance problem for everyone using Struts 2.1.8.1 in a production environment with hundreds/thousands of concurrent users. So they can avoid searching JIRA and changing the OGNL library to resolve this issue... Just another thing we found yesterday....(so maybe it's better to wait to release an "official" Struts release) Pushing the stress tests above 700 concurrent users (around 1000 concurrent users) we found a similar problem with the Freemarker library... We have updated Freemarker to the 2.3.18 version and applied a patch to the freemarker.ext.beans.BeansWrapper class. We will let you know if the tests are successful and the problem is solved...
          Hide
          Maurizio Cucchiara added a comment -

          Sorry, but in this specific case I don't see the usefulness of a new release. You can just replace OGNL dependency as Lukasz pointed out before.
          Also I have taken a look at freemarker release note and I did not see any issue related to performance/concurrency topic.
          With that saying I am going to update fm version.

          Show
          Maurizio Cucchiara added a comment - Sorry, but in this specific case I don't see the usefulness of a new release. You can just replace OGNL dependency as Lukasz pointed out before. Also I have taken a look at freemarker release note and I did not see any issue related to performance/concurrency topic. With that saying I am going to update fm version.
          Hide
          Alessio Cicioni added a comment -

          OK Maurizio, no problem for us...it was just for the community...

          Show
          Alessio Cicioni added a comment - OK Maurizio, no problem for us...it was just for the community...
          Hide
          Rene Gielen added a comment -

          Maurizio, I'm not as sure as you that a release would not make sense, given that we have other fixes in place and even a new plugin. And having a release note talking about significant performance improvements, which is what we see here, would not be too shabby
          We had similar policies for other closely related third-party libraries such as OS XWork before it was moved to Struts.
          Usually dropping an info in the user list that manually replacing the lib makes sense has much less effect that having a new release.
          That said, releasing depends on people having spare time - which is another story as just usefulness.

          Show
          Rene Gielen added a comment - Maurizio, I'm not as sure as you that a release would not make sense, given that we have other fixes in place and even a new plugin. And having a release note talking about significant performance improvements, which is what we see here, would not be too shabby We had similar policies for other closely related third-party libraries such as OS XWork before it was moved to Struts. Usually dropping an info in the user list that manually replacing the lib makes sense has much less effect that having a new release. That said, releasing depends on people having spare time - which is another story as just usefulness.
          Hide
          Rene Gielen added a comment -

          Just to clarify, what I meant was related to releasing off trunk, not in the 2.1.x branch. Sorry that I seem to have mixed up your points, since I of course would not release off 2.1.x for a change in OGNL. That said, we should put 2.1.x into deprecated mode soon...

          Show
          Rene Gielen added a comment - Just to clarify, what I meant was related to releasing off trunk, not in the 2.1.x branch. Sorry that I seem to have mixed up your points, since I of course would not release off 2.1.x for a change in OGNL. That said, we should put 2.1.x into deprecated mode soon...
          Hide
          Maurizio Cucchiara added a comment -

          Hi René,
          if I understand correctly, we are saying the same thing, I myself am for release the 2.3 version.
          My original concern was about releasing a 2.1.8.x version.
          I asked to Alessio if he would had specific policies inside his corporation (you know better than me there are some company which allow only certified versions and seems that 2.1.8.1 version is that with the major consensus).

          Don't you agree, René?

          I think it's time to switch to dev ML.

          Show
          Maurizio Cucchiara added a comment - Hi René, if I understand correctly, we are saying the same thing, I myself am for release the 2.3 version. My original concern was about releasing a 2.1.8.x version. I asked to Alessio if he would had specific policies inside his corporation (you know better than me there are some company which allow only certified versions and seems that 2.1.8.1 version is that with the major consensus). Don't you agree, René? I think it's time to switch to dev ML.
          Hide
          Rene Gielen added a comment -

          Yes, we're saying the same.

          If a company has a version like 2.1.8.1 tagged as certified, I would have other concerns - the latest security fixes were not applied afaik, basically it has reached EOL. We should make this clear to our users, unless someone wants to jump in supporting older branches.

          +1 for moving discussion to dev@

          Show
          Rene Gielen added a comment - Yes, we're saying the same. If a company has a version like 2.1.8.1 tagged as certified, I would have other concerns - the latest security fixes were not applied afaik, basically it has reached EOL. We should make this clear to our users, unless someone wants to jump in supporting older branches. +1 for moving discussion to dev@
          Hide
          Falko Modler added a comment -

          It seems impossible to find detailed changelogs/release notes for ognl versions since 3.0.
          We are on Struts2 2.2.3.1 which uses ognl 3.0.1. So before switching to 3.0.3, I'd like to know what has been changed since 3.0.1 (except this performance issue).

          These are the most recent release notes I could find:
          http://jira.opensymphony.com/secure/ReleaseNote.jspa?version=21770&styleName=Text&projectId=10090&Create=Create
          But this is just 3.0.

          The incubator JIRA does not contain versions and only seems to target 4.0 and upwards:
          https://issues.apache.org/jira/browse/OGNL

          Very confusing...

          Show
          Falko Modler added a comment - It seems impossible to find detailed changelogs/release notes for ognl versions since 3.0. We are on Struts2 2.2.3.1 which uses ognl 3.0.1. So before switching to 3.0.3, I'd like to know what has been changed since 3.0.1 (except this performance issue). These are the most recent release notes I could find: http://jira.opensymphony.com/secure/ReleaseNote.jspa?version=21770&styleName=Text&projectId=10090&Create=Create But this is just 3.0. The incubator JIRA does not contain versions and only seems to target 4.0 and upwards: https://issues.apache.org/jira/browse/OGNL Very confusing...
          Hide
          Maurizio Cucchiara added a comment -

          Have you already took a look at github?
          The project has been hosted there up until recently.
          The new version will be release ASAP under the commons umbrella.
          Anyway, nothing special happened to OGNL so far, IIRC, there were 3 minor issue solved (You can take a look at github history).

          Show
          Maurizio Cucchiara added a comment - Have you already took a look at github ? The project has been hosted there up until recently. The new version will be release ASAP under the commons umbrella. Anyway, nothing special happened to OGNL so far, IIRC, there were 3 minor issue solved (You can take a look at github history).
          Hide
          Lukasz Lenart added a comment -

          Take a look on commits > https://github.com/jkuhnert/ognl/commits/master

          • 3.0.1 - Javassist added back as a dependency
          • 3.0.2 - small fix to solve a problem with compiling under JDK5
          • 3.0.3 - small fix to improve performance (this one)
          Show
          Lukasz Lenart added a comment - Take a look on commits > https://github.com/jkuhnert/ognl/commits/master 3.0.1 - Javassist added back as a dependency 3.0.2 - small fix to solve a problem with compiling under JDK5 3.0.3 - small fix to improve performance (this one)
          Hide
          Lukasz Lenart added a comment -
          Show
          Lukasz Lenart added a comment - Official release notes https://github.com/jkuhnert/ognl/blob/master/README.md
          Hide
          Falko Modler added a comment -

          Thanks a lot!

          Show
          Falko Modler added a comment - Thanks a lot!
          Hide
          Philip Luppens added a comment -

          I can also report that our performance issues are gone - no more blocking threads.

          Show
          Philip Luppens added a comment - I can also report that our performance issues are gone - no more blocking threads.
          Hide
          Lukasz Lenart added a comment -

          That nice

          Show
          Lukasz Lenart added a comment - That nice
          Hide
          Maurizio Cucchiara added a comment -

          Hi guys,
          almost done with the new OGNL cache implementation.
          I put in my Apache home the new version 4.0-SNAPSHOT (based on this branch).
          Be aware that this is not yet ready for production and the integration with Struts2 is not yet fully implemented (though it should work smoothly).
          Since many of you has already a performance environment ready, could you please check this library against your code?
          Thanks in advance for your precious contribution.

          Show
          Maurizio Cucchiara added a comment - Hi guys, almost done with the new OGNL cache implementation. I put in my Apache home the new version 4.0-SNAPSHOT (based on this branch ). Be aware that this is not yet ready for production and the integration with Struts2 is not yet fully implemented (though it should work smoothly). Since many of you has already a performance environment ready, could you please check this library against your code? Thanks in advance for your precious contribution.

            People

            • Assignee:
              Lukasz Lenart
              Reporter:
              Shishir Saxena
            • Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development