Hi, Am Mittwoch, den 09.02.2011, 09:07 +0000 schrieb Markus Joschko: > Hi Carsten, > that's what I found out yesterday evening as well. JSP samples from > sling didn't show the errors. > I converted one of our esp to jsp today and tested it again and can > confirm that the JSP works fine where the equivalent ESP fails big > time. > > Obviously nobody has used esps in production until now? That should be > mentioned on the webpage clearly. So far I had the impression that esp > are somewhat the preferred template language.
Well, depends ;-) I would say everyone has his/her own preference, Sling does not have a preference ;-) But in our Day job some if not most of use mostly care for JSP, true. > Do you have a reference to the bug in the felix javascript implementation? I am working on this as we speak. Regards Felix > > Regards, > Markus > > > On Wed, Feb 9, 2011 at 8:13 AM, Carsten Ziegeler <[email protected]> wrote: > > Hi, > > > > Sling and Jackrabbit by itself don't have concurrency issues (at least > > we're not aware of them). We're using both in huge production systems > > with a lot of load without any problems. > > > > I see two potential causes: the orders.esp script or maybe the script > > engine implementation. Felix recently found a concurrency problem in the > > javascript scripting . The esp script engine could be affected as well. > > > > Please try a different test where a jsp is targeted to rule out the > > above scenarios. > > > > Regards > > Carsten > > > > Markus Joschko wrote > >> Hi, > >> we run a simple performance test on our sling prototype and face > >> severe problems: About 50% of the requests failed with a status > >> message 500. > >> The exceptions differ a lot but it seems that the "sling include" > >> somehow fails when accessed concurrently. > >> > >> Our tests were run with JMeter (and failed). To make it easier to > >> reproduce the problem we wrote a small bashscript using curl and run > >> it against the slingbuck example: > >> > >> #!/bin/bash > >> for i in {1..10} > >> do > >> curl http://localhost:8080/content/slingbucks/public/orders.html > >>> out$i.log & > >> done > >> > >> > >> It simply calls the same URL 10 times in parallel. When grepping > >> through the outX.log files we found a lot of exceptions/partial page > >> renderings, wrongly assembled pages etc. > >> > >> A short excerpt: > >> > >> - NPE exception and TypeError: Cannot read property "jcr:title" from > >> undefined error. > >> - javax.jcr.PathNotFoundException: test:name > >> - TypeError: Cannot call method "XXX" of undefined > >> - Wrapped javax.jcr.InvalidItemStateException: > >> 0a1cf798-1ada-48cc-a65b-f9ba17904467: the item does not exist anymore > >> - Wrapped javax.jcr.RepositoryException: this session has been closed > >> - 404 No Servlet to handle request > >> - Resource resolver is already closed > >> > >> I am really concerned. I can't imagine that sling has such a huge > >> problem but I can't explain the exceptions we see either. > >> > >> Any ideas? > >> > >> Markus > >> > > > > > > -- > > Carsten Ziegeler > > [email protected] > >
