Solr
  1. Solr
  2. SOLR-2694

LogUpdateProcessor not thread safe

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Cannot Reproduce
    • Affects Version/s: 1.4.1, 3.1, 3.2, 3.3, 4.0-ALPHA
    • Fix Version/s: None
    • Component/s: update
    • Labels:
      None

      Description

      Using the LogUpdateProcessor while feeding in multiple parallell threads does not work, as LogUpdateProcessor is not threadsafe.

        Issue Links

          Activity

          Hide
          Mikhail Khludnev added a comment -

          Ethan,

          1. that patch (dated 1/1/12) has absolutely no sense, I tell you as an author: UpdateProcessors are thread unaware prototypes, not singletons;
          2. the later patch from SOLR-2804 make sense for DIH with "threads", which is not supported further;
          3. your core problem is "The update chain we defined is enforced with singleton", I suggest instantiate the necessary logic in UpdateProcessorFactory and provide it for concurrent access from thread unaware UpdateProcessors.
          Show
          Mikhail Khludnev added a comment - Ethan, that patch (dated 1/1/12) has absolutely no sense, I tell you as an author: UpdateProcessors are thread unaware prototypes, not singletons; the later patch from SOLR-2804 make sense for DIH with "threads", which is not supported further; your core problem is "The update chain we defined is enforced with singleton", I suggest instantiate the necessary logic in UpdateProcessorFactory and provide it for concurrent access from thread unaware UpdateProcessors.
          Hide
          Ethan Tao added a comment -

          We've decided to manually apply the patch from Solr-2804 dated 1/1/12 to current Snapshot.
          If this patch won't become official, at least there should be a new class "ConcurrentLogUpdateProcessorFactory" to handle the thread safe issue. We'll file a new bug for it.
          Thanks.

          Show
          Ethan Tao added a comment - We've decided to manually apply the patch from Solr-2804 dated 1/1/12 to current Snapshot. If this patch won't become official, at least there should be a new class "ConcurrentLogUpdateProcessorFactory" to handle the thread safe issue. We'll file a new bug for it. Thanks.
          Hide
          Ethan Tao added a comment -

          Hoss: The issue described in Solr-2804 also helps to some extend.
          We are building document indexing pipeline. The update chain we defined is enforced with singleton, thus the LogUpdateProcessor is shared among concurrent threads. We didn't realize the class is thread unsafe till now.

          We'll try the workaround to reduce its log level below INFO and see if it's acceptable. We'll create a new bug if necessary.
          Thanks a lot.

          -Ethan

          Show
          Ethan Tao added a comment - Hoss: The issue described in Solr-2804 also helps to some extend. We are building document indexing pipeline. The update chain we defined is enforced with singleton, thus the LogUpdateProcessor is shared among concurrent threads. We didn't realize the class is thread unsafe till now. We'll try the workaround to reduce its log level below INFO and see if it's acceptable. We'll create a new bug if necessary. Thanks a lot. -Ethan
          Hide
          Hoss Man added a comment -

          Ethan: please note yonik's comment earlier in this thread...

          A new update processor is built for every request, and hence they are not thread safe by design.
          How is this log processor getting shared between multiple threads?

          please also not the comments in SOLR-2804 which i've linked, in particular...

          That should not be the case at all for SOlrJ users and people using DIH in single threaded mode – every UpdateProcessorFactory (including the LogUpdateprocessorFactory) creates new UpdateProcessor instances for every update request – so no concurrency protection should be required for multiple threads processing concurrent requests individually. A simple NamedList to collect the results to be logged for each request should be completely sufficient.

          Based on the comments so far, it sounds like the bug is multiple threads in DIH attempting to update the same NamedList concurrently – which is most certainly not safe for DIH to do (NamedList has never been, nor been documented to suggest it might be, thread safe)

          Changing LogUpdateprocessorFactory to add concurrency boundaries to something that is already suppose to only be single thread access seems like it will only slow down all the use cases that are already doing the right thing and working fine – let's fix the concurrency issue in the place where there is concurrency code: figure out when/why/where DIH is letting multiple threads manipulate the toLog NamedList and fix that.

          if you are seeing a manifestation of this error using DIH with the multi-trheaded option, then please note all the comments in SOLR-2804 and the linked issues.

          if you are seeing a manifestation of this error using some other mechanism of processing updates, then please file a new bug.

          Show
          Hoss Man added a comment - Ethan: please note yonik's comment earlier in this thread... A new update processor is built for every request, and hence they are not thread safe by design. How is this log processor getting shared between multiple threads? please also not the comments in SOLR-2804 which i've linked, in particular... That should not be the case at all for SOlrJ users and people using DIH in single threaded mode – every UpdateProcessorFactory (including the LogUpdateprocessorFactory) creates new UpdateProcessor instances for every update request – so no concurrency protection should be required for multiple threads processing concurrent requests individually. A simple NamedList to collect the results to be logged for each request should be completely sufficient. Based on the comments so far, it sounds like the bug is multiple threads in DIH attempting to update the same NamedList concurrently – which is most certainly not safe for DIH to do (NamedList has never been, nor been documented to suggest it might be, thread safe) Changing LogUpdateprocessorFactory to add concurrency boundaries to something that is already suppose to only be single thread access seems like it will only slow down all the use cases that are already doing the right thing and working fine – let's fix the concurrency issue in the place where there is concurrency code: figure out when/why/where DIH is letting multiple threads manipulate the toLog NamedList and fix that. if you are seeing a manifestation of this error using DIH with the multi-trheaded option, then please note all the comments in SOLR-2804 and the linked issues. if you are seeing a manifestation of this error using some other mechanism of processing updates, then please file a new bug.
          Hide
          Ethan Tao added a comment -

          Hi, we are having the same issue with latest snapshot.
          When updating the same set of docs repeatedly, we can easily reproduce it. We also have 10 secs commit in our env.
          I checked the code with LogUpdateProcessor, the code is not thread safe with "toLog" object as concurrent threads may be calling other methods when finish() is called. The problem is when "sb.append(toLog)" is called, StringBuilder starts to use namedlist to build the string object. If other methods are called to modify the objects reside within "toLog", the exception will be triggered. These objects include deletes, adds, etc. Also, the keys to these object have 7 different types (commit/rollback, ..etc.), any size change to the SimpleOrderedMap (i.e., toLog) object may also trigger the issue during the call to "sb.append(toLog)" in finish().
          We did quick experiment by modifying the LogUpdateProcessorFactory file to synchronize on toLog in all methods. Then change our chain definition in solrconfig.xml to call our own LogUpdateProcessor instead. The issue went away. I am attaching the custom code below for your reference.

          Can someone please re-open and fix the issue?
          Thanks.

          -Ethan

          class LogUpdateProcessor extends UpdateRequestProcessor {

          ...

          @Override
          public void processAdd(AddUpdateCommand cmd) throws IOException {
          if (logDebug)

          { log.debug("PRE_UPDATE " + cmd.toString()); }

          // call delegate first so we can log things like the version that get set later
          if (next != null) next.processAdd(cmd);

          synchronized (toLog) {

          // Add a list of added id's to the response
          if (adds == null) { adds = new ArrayList<String>(); toLog.add("add",adds); }

          if (adds.size() < maxNumToLog) { long version = cmd.getVersion(); String msg = cmd.getPrintableId(); if (version != 0) msg = msg + " (" + version + ')'; adds.add(msg); }


          numAdds++;

          }
          }

          @Override
          public void processDelete( DeleteUpdateCommand cmd ) throws IOException {
          if (logDebug) { log.debug("PRE_UPDATE " + cmd.toString()); }

          if (next != null) next.processDelete(cmd);

          synchronized (toLog) {
          if (cmd.isDeleteById()) {
          if (deletes == null)

          { deletes = new ArrayList<String>(); toLog.add("delete",deletes); }

          if (deletes.size() < maxNumToLog)

          { long version = cmd.getVersion(); String msg = cmd.getId(); if (version != 0) msg = msg + " (" + version + ')'; deletes.add(msg); }

          } else {
          if (toLog.size() < maxNumToLog)

          { long version = cmd.getVersion(); String msg = cmd.query; if (version != 0) msg = msg + " (" + version + ')'; toLog.add("deleteByQuery", msg); }

          }
          numDeletes++;
          }

          }

          @Override
          public void processMergeIndexes(MergeIndexesCommand cmd) throws IOException {
          if (logDebug)

          { log.debug("PRE_UPDATE " + cmd.toString()); }
          if (next != null) next.processMergeIndexes(cmd);

          synchronized (toLog) { toLog.add("mergeIndexes", cmd.toString()); }
          }

          @Override
          public void processCommit( CommitUpdateCommand cmd ) throws IOException {
          if (logDebug) { log.debug("PRE_UPDATE " + cmd.toString()); }

          if (next != null) next.processCommit(cmd);

          synchronized (toLog)

          { final String msg = cmd.optimize ? "optimize" : "commit"; toLog.add(msg, ""); }

          }

          /**

          • @since Solr 1.4
            */
            @Override
            public void processRollback( RollbackUpdateCommand cmd ) throws IOException {
            if (logDebug) { log.debug("PRE_UPDATE " + cmd.toString()); }

            if (next != null) next.processRollback(cmd);

          synchronized (toLog)

          { toLog.add("rollback", ""); }

          }

          @Override
          public void finish() throws IOException {
          if (logDebug)

          { log.debug("PRE_UPDATE finish()"); }

          if (next != null) next.finish();

          // LOG A SUMMARY WHEN ALL DONE (INFO LEVEL)

          NamedList<Object> stdLog = rsp.getToLog();

          StringBuilder sb = new StringBuilder(req.getCore().getLogId());

          for (int i=0; i<stdLog.size(); i++) {
          String name = stdLog.getName;
          Object val = stdLog.getVal;
          if (name != null)

          { sb.append(name).append('='); }

          sb.append(val).append(' ');
          }

          stdLog.clear(); // make it so SolrCore.exec won't log this again

          synchronized (toLog) {

          // if id lists were truncated, show how many more there were
          if (adds != null && numAdds > maxNumToLog)

          { adds.add("... (" + numAdds + " adds)"); }

          if (deletes != null && numDeletes > maxNumToLog)

          { deletes.add("... (" + numDeletes + " deletes)"); }

          long elapsed = rsp.getEndTime() - req.getStartTime();

          sb.append(toLog).append(" 0 ").append(elapsed);

          }

          log.info(sb.toString());
          }
          }

          Show
          Ethan Tao added a comment - Hi, we are having the same issue with latest snapshot. When updating the same set of docs repeatedly, we can easily reproduce it. We also have 10 secs commit in our env. I checked the code with LogUpdateProcessor, the code is not thread safe with "toLog" object as concurrent threads may be calling other methods when finish() is called. The problem is when "sb.append(toLog)" is called, StringBuilder starts to use namedlist to build the string object. If other methods are called to modify the objects reside within "toLog", the exception will be triggered. These objects include deletes, adds, etc. Also, the keys to these object have 7 different types (commit/rollback, ..etc.), any size change to the SimpleOrderedMap (i.e., toLog) object may also trigger the issue during the call to "sb.append(toLog)" in finish(). We did quick experiment by modifying the LogUpdateProcessorFactory file to synchronize on toLog in all methods. Then change our chain definition in solrconfig.xml to call our own LogUpdateProcessor instead. The issue went away. I am attaching the custom code below for your reference. Can someone please re-open and fix the issue? Thanks. -Ethan class LogUpdateProcessor extends UpdateRequestProcessor { ... @Override public void processAdd(AddUpdateCommand cmd) throws IOException { if (logDebug) { log.debug("PRE_UPDATE " + cmd.toString()); } // call delegate first so we can log things like the version that get set later if (next != null) next.processAdd(cmd); synchronized (toLog) { // Add a list of added id's to the response if (adds == null) { adds = new ArrayList<String>(); toLog.add("add",adds); } if (adds.size() < maxNumToLog) { long version = cmd.getVersion(); String msg = cmd.getPrintableId(); if (version != 0) msg = msg + " (" + version + ')'; adds.add(msg); } numAdds++; } } @Override public void processDelete( DeleteUpdateCommand cmd ) throws IOException { if (logDebug) { log.debug("PRE_UPDATE " + cmd.toString()); } if (next != null) next.processDelete(cmd); synchronized (toLog) { if (cmd.isDeleteById()) { if (deletes == null) { deletes = new ArrayList<String>(); toLog.add("delete",deletes); } if (deletes.size() < maxNumToLog) { long version = cmd.getVersion(); String msg = cmd.getId(); if (version != 0) msg = msg + " (" + version + ')'; deletes.add(msg); } } else { if (toLog.size() < maxNumToLog) { long version = cmd.getVersion(); String msg = cmd.query; if (version != 0) msg = msg + " (" + version + ')'; toLog.add("deleteByQuery", msg); } } numDeletes++; } } @Override public void processMergeIndexes(MergeIndexesCommand cmd) throws IOException { if (logDebug) { log.debug("PRE_UPDATE " + cmd.toString()); } if (next != null) next.processMergeIndexes(cmd); synchronized (toLog) { toLog.add("mergeIndexes", cmd.toString()); } } @Override public void processCommit( CommitUpdateCommand cmd ) throws IOException { if (logDebug) { log.debug("PRE_UPDATE " + cmd.toString()); } if (next != null) next.processCommit(cmd); synchronized (toLog) { final String msg = cmd.optimize ? "optimize" : "commit"; toLog.add(msg, ""); } } /** @since Solr 1.4 */ @Override public void processRollback( RollbackUpdateCommand cmd ) throws IOException { if (logDebug) { log.debug("PRE_UPDATE " + cmd.toString()); } if (next != null) next.processRollback(cmd); synchronized (toLog) { toLog.add("rollback", ""); } } @Override public void finish() throws IOException { if (logDebug) { log.debug("PRE_UPDATE finish()"); } if (next != null) next.finish(); // LOG A SUMMARY WHEN ALL DONE (INFO LEVEL) NamedList<Object> stdLog = rsp.getToLog(); StringBuilder sb = new StringBuilder(req.getCore().getLogId()); for (int i=0; i<stdLog.size(); i++) { String name = stdLog.getName ; Object val = stdLog.getVal ; if (name != null) { sb.append(name).append('='); } sb.append(val).append(' '); } stdLog.clear(); // make it so SolrCore.exec won't log this again synchronized (toLog) { // if id lists were truncated, show how many more there were if (adds != null && numAdds > maxNumToLog) { adds.add("... (" + numAdds + " adds)"); } if (deletes != null && numDeletes > maxNumToLog) { deletes.add("... (" + numDeletes + " deletes)"); } long elapsed = rsp.getEndTime() - req.getStartTime(); sb.append(toLog).append(" 0 ").append(elapsed); } log.info(sb.toString()); } }
          Hide
          Jan Høydahl added a comment -

          Closing this for now - could reopen if necessary...

          Show
          Jan Høydahl added a comment - Closing this for now - could reopen if necessary...
          Hide
          Jan Høydahl added a comment -

          3.2 and also 3.x branch. But I just recalled that this customer uses a custom version of ExtractingRequestHandler. I tried reverting to default ExtractingRequestHandler, and the ConcurrentModificationException does not happen.... So let us check our own code first...

          Show
          Jan Høydahl added a comment - 3.2 and also 3.x branch. But I just recalled that this customer uses a custom version of ExtractingRequestHandler. I tried reverting to default ExtractingRequestHandler, and the ConcurrentModificationException does not happen.... So let us check our own code first...
          Hide
          David Smiley added a comment -

          Jan, precisely which release of Solr are you reproducing this on?

          Show
          David Smiley added a comment - Jan, precisely which release of Solr are you reproducing this on?
          Hide
          Yonik Seeley added a comment -

          The normal example server uses logging by default, and I can't reproduce this there.

          From the exampledocs directory, I'm doing
          while true; do ./post.sh *xml; done
          in two different windows.

          One can also see in ContentStreamHandlerBase, a new processor is created for each request:
          UpdateRequestProcessor processor = processorChain.createProcessor(req, rsp);

          Is this stock solr?

          Show
          Yonik Seeley added a comment - The normal example server uses logging by default, and I can't reproduce this there. From the exampledocs directory, I'm doing while true; do ./post.sh *xml; done in two different windows. One can also see in ContentStreamHandlerBase, a new processor is created for each request: UpdateRequestProcessor processor = processorChain.createProcessor(req, rsp); Is this stock solr?
          Hide
          Jan Høydahl added a comment -

          Haven't analyzed it deeply, but it is very easy to reproduce.
          1. Setup an UpdateChain with the LogUpdateProcessor in it
          2. Start feeding a bunch of docs in one shell window
          3. Start feeding a bunch of docs in another shell window
          4. Bang!

          Cannot see from the code why this happens, but it seems to be related to usage of the SimpleOrderedMap.

          Show
          Jan Høydahl added a comment - Haven't analyzed it deeply, but it is very easy to reproduce. 1. Setup an UpdateChain with the LogUpdateProcessor in it 2. Start feeding a bunch of docs in one shell window 3. Start feeding a bunch of docs in another shell window 4. Bang! Cannot see from the code why this happens, but it seems to be related to usage of the SimpleOrderedMap.
          Hide
          David Smiley added a comment -

          As an aside, I think it's important to document thread safety (or lack thereof) in an API, particularly for classes that are extension points like UpdateRequestProcessor. FWIW Joshua Bloch thinks so too as it's item #70 in "Effective Java". This is good practice for object life-cycle information too – i.e. construction, and any applicable callbacks. As I'm working with coding in Lucene and Solr I often wonder wether I need to be careful to be thread safe or not and I always have to go deduce this question myself instead of the API telling me. I propose that a comment be added to UpdateRequestProcessor saying:

          UpdateRequestProcessors are instantiated once per request, and thus don't need to be thread safe.

          Show
          David Smiley added a comment - As an aside, I think it's important to document thread safety (or lack thereof) in an API, particularly for classes that are extension points like UpdateRequestProcessor. FWIW Joshua Bloch thinks so too as it's item #70 in "Effective Java". This is good practice for object life-cycle information too – i.e. construction, and any applicable callbacks. As I'm working with coding in Lucene and Solr I often wonder wether I need to be careful to be thread safe or not and I always have to go deduce this question myself instead of the API telling me. I propose that a comment be added to UpdateRequestProcessor saying: UpdateRequestProcessors are instantiated once per request, and thus don't need to be thread safe.
          Hide
          Yonik Seeley added a comment -

          A new update processor is built for every request, and hence they are not thread safe by design.
          How is this log processor getting shared between multiple threads?

          Show
          Yonik Seeley added a comment - A new update processor is built for every request, and hence they are not thread safe by design. How is this log processor getting shared between multiple threads?
          Hide
          Jan Høydahl added a comment -

          Example of exception thrown:

          SEVERE: java.util.ConcurrentModificationException
                  at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
                  at java.util.AbstractList$Itr.next(AbstractList.java:343)
                  at java.util.AbstractCollection.toString(AbstractCollection.java:421)
                  at java.lang.String.valueOf(String.java:2826)
                  at java.lang.StringBuilder.append(StringBuilder.java:115)
                  at org.apache.solr.common.util.NamedList.toString(NamedList.java:255)
                  at java.lang.String.valueOf(String.java:2826)
                  at java.lang.StringBuilder.append(StringBuilder.java:115)
                  at org.apache.solr.update.processor.LogUpdateProcessor.finish(LogUpdateProcessorFactory.java:171)
                  at org.apache.solr.update.processor.UpdateRequestProcessor.finish(UpdateRequestProcessor.java:78)
                  at org.apache.solr.update.processor.UpdateRequestProcessor.finish(UpdateRequestProcessor.java:78)
                  at org.apache.solr.update.processor.UpdateRequestProcessor.finish(UpdateRequestProcessor.java:78)
                  at org.apache.solr.update.processor.UpdateRequestProcessor.finish(UpdateRequestProcessor.java:78)
                  at org.apache.solr.update.processor.UpdateRequestProcessor.finish(UpdateRequestProcessor.java:78)
                  at org.apache.solr.update.processor.UpdateRequestProcessor.finish(UpdateRequestProcessor.java:78)
                  at org.apache.solr.update.processor.UpdateRequestProcessor.finish(UpdateRequestProcessor.java:78)
                  at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:76)
                  at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
                  at org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper.handleRequest(RequestHandlers.java:241)
                  at org.apache.solr.core.SolrCore.execute(SolrCore.java:1360)
                  at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:356)
                  at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:252)
                  at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
                  at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
                  at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
                  at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
                  at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
                  at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
                  at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
                  at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
                  at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
                  at org.mortbay.jetty.Server.handle(Server.java:326)
                  at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
                  at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
                  at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
                  at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
                  at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
                  at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
                  at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
          
          Show
          Jan Høydahl added a comment - Example of exception thrown: SEVERE: java.util.ConcurrentModificationException at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372) at java.util.AbstractList$Itr.next(AbstractList.java:343) at java.util.AbstractCollection.toString(AbstractCollection.java:421) at java.lang. String .valueOf( String .java:2826) at java.lang.StringBuilder.append(StringBuilder.java:115) at org.apache.solr.common.util.NamedList.toString(NamedList.java:255) at java.lang. String .valueOf( String .java:2826) at java.lang.StringBuilder.append(StringBuilder.java:115) at org.apache.solr.update.processor.LogUpdateProcessor.finish(LogUpdateProcessorFactory.java:171) at org.apache.solr.update.processor.UpdateRequestProcessor.finish(UpdateRequestProcessor.java:78) at org.apache.solr.update.processor.UpdateRequestProcessor.finish(UpdateRequestProcessor.java:78) at org.apache.solr.update.processor.UpdateRequestProcessor.finish(UpdateRequestProcessor.java:78) at org.apache.solr.update.processor.UpdateRequestProcessor.finish(UpdateRequestProcessor.java:78) at org.apache.solr.update.processor.UpdateRequestProcessor.finish(UpdateRequestProcessor.java:78) at org.apache.solr.update.processor.UpdateRequestProcessor.finish(UpdateRequestProcessor.java:78) at org.apache.solr.update.processor.UpdateRequestProcessor.finish(UpdateRequestProcessor.java:78) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:76) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) at org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper.handleRequest(RequestHandlers.java:241) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1360) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:356) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:252) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)

            People

            • Assignee:
              Unassigned
              Reporter:
              Jan Høydahl
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development