Details

    • Global Rank:
      273

      Description

      See SUPPORT-676 for full details.

      2011-04-14 10:26:10 ERROR [p-15263993-3462] - org.mortbay.log - /content/repositories/exo-snapshots/org/exoplatform/ks/exo.ks.component.common/maven-metadata.xml
      org.apache.shiro.session.UnknownSessionException: There is no session with id [df49f6c6-8602-4a5a-898e-adb3fe356f7d]
      at org.apache.shiro.session.mgt.eis.AbstractSessionDAO.readSession(AbstractSessionDAO.java:170)
      at org.apache.shiro.session.mgt.eis.CachingSessionDAO.readSession(CachingSessionDAO.java:261)
      at org.apache.shiro.session.mgt.DefaultSessionManager.retrieveSessionFromDataSource(DefaultSessionManager.java:236)
      at org.apache.shiro.session.mgt.DefaultSessionManager.retrieveSession(DefaultSessionManager.java:222)
      at org.apache.shiro.session.mgt.AbstractValidatingSessionManager.doGetSession(AbstractValidatingSessionManager.java:118)
      at org.apache.shiro.session.mgt.AbstractNativeSessionManager.lookupSession(AbstractNativeSessionManager.java:105)
      at org.apache.shiro.session.mgt.AbstractNativeSessionManager.lookupRequiredSession(AbstractNativeSessionManager.java:109)
      at org.apache.shiro.session.mgt.AbstractNativeSessionManager.removeAttribute(AbstractNativeSessionManager.java:220)
      at org.apache.shiro.session.mgt.DelegatingSession.removeAttribute(DelegatingSession.java:159)
      at org.apache.shiro.session.ProxiedSession.removeAttribute(ProxiedSession.java:135)
      at org.apache.shiro.subject.support.DelegatingSubject.clearRunAsIdentities(DelegatingSubject.java:424)
      at org.apache.shiro.subject.support.DelegatingSubject.logout(DelegatingSubject.java:322)
      at org.sonatype.nexus.security.filter.authc.NexusHttpAuthenticationFilter.afterCompletion(NexusHttpAuthenticationFilter.java:489)
      at org.apache.shiro.web.servlet.AdviceFilter.cleanup(AdviceFilter.java:172)
      at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:148)
      at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:81)
      at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
      at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:359)
      at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:275)
      at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
      at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
      at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:344)
      at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:272)
      at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:81)
      at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1148)
      at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:387)
      at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
      at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
      at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
      at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417)
      at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
      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:534)
      at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:879)
      at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747)
      at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
      at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
      at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
      at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:520)
      

        Issue Links

          Activity

          Hide
          Arnaud Heritier added a comment - - edited

          I had this issue several times these last days ...
          I'm using 1.9.1.1

          Show
          Arnaud Heritier added a comment - - edited I had this issue several times these last days ... I'm using 1.9.1.1
          Hide
          Peter Lynch added a comment -

          No unit tests that I see - not sure about IT. Also no steps to repro stated. Also the 'fix' is currently in re-review.

          Show
          Peter Lynch added a comment - No unit tests that I see - not sure about IT. Also no steps to repro stated. Also the 'fix' is currently in re-review.
          Hide
          Peter Lynch added a comment -

          Brian, you are reviewing?

          Show
          Peter Lynch added a comment - Brian, you are reviewing?
          Hide
          Peter Lynch added a comment -

          Reopening to add missing tests - or if you can provide an existing IT that failed before this change, and now passes.

          Show
          Peter Lynch added a comment - Reopening to add missing tests - or if you can provide an existing IT that failed before this change, and now passes.
          Hide
          Brian Demers added a comment -
          Show
          Brian Demers added a comment - Until the jira git polling catches up: https://github.com/sonatype/nexus/commit/669b9f2d856bc455cccd2f1d8c7be4ee825ad463
          Hide
          Brian Demers added a comment -

          The problem has been resolved in the trunk. The problem caused by incorrect handling of sessions. We had made some assumptions for 'stateless' clients. The session cookie was set, then we removed the session (assuming the client would not use it). Some of these clients are not actually stateless. So, the correct fix is to not set the cookie, for the 'stateless' clients.

          This list currently includes: maven, ivy, java, wget, curl
          Any other user-agent is considered state-full

          Show
          Brian Demers added a comment - The problem has been resolved in the trunk. The problem caused by incorrect handling of sessions. We had made some assumptions for 'stateless' clients. The session cookie was set, then we removed the session (assuming the client would not use it). Some of these clients are not actually stateless. So, the correct fix is to not set the cookie, for the 'stateless' clients. This list currently includes: maven, ivy, java, wget, curl Any other user-agent is considered state-full
          Hide
          Rich Seddon added a comment -

          Using materialization I am able to reproduce tons of these exceptions in 1.9.1.1, none at all in 1.9.2.

          Also, using curl I see that 1.9.1.1 sets the session cookie with java user agent:

          curl -I http://localhost:8081/nexus/content/repositories/ --user admin:admin123 --user-agent "Java/1.6"
          HTTP/1.1 200 OK
          Date: Tue, 24 May 2011 17:57:40 GMT
          Set-Cookie: JSESSIONID=f0fb7eb4-11b1-4bb2-ac00-06f4b0fbe6f9; Path=/nexus; HttpOnly
          Set-Cookie: rememberMe=deleteMe; Path=/nexus; Max-Age=0; Expires=Mon, 23-May-2011 17:57:40 GMT
          Content-Type: text/html
          Last-Modified: Tue, 24 May 2011 17:57:40 GMT
          Date: Tue, 24 May 2011 17:57:40 GMT
          Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept
          Server: Noelios-Restlet-Engine/1.1.6-SONATYPE-5348-V4
          Set-Cookie: rememberMe=deleteMe; Path=/nexus; Max-Age=0; Expires=Mon, 23-May-2011 17:57:40 GMT
          Set-Cookie: JSESSIONID=deleteMe; Path=/nexus; Max-Age=0; Expires=Mon, 23-May-2011 17:57:40 GMT
          Content-Length: 0
          

          1.9.2 does not. Also verified with Apache-Maven user agent.

          curl -I http://localhost:8081/nexus/content/repositories/ --user admin:admin123 --user-agent "Java/1.6"
          HTTP/1.1 200 OK
          Date: Tue, 24 May 2011 17:59:04 GMT
          Set-Cookie: rememberMe=deleteMe; Path=/nexus; Max-Age=0; Expires=Mon, 23-May-2011 17:59:04 GMT
          Content-Type: text/html
          Last-Modified: Tue, 24 May 2011 17:59:05 GMT
          Date: Tue, 24 May 2011 17:59:05 GMT
          Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept
          Server: Noelios-Restlet-Engine/1.1.6-SONATYPE-5348-V4
          Content-Length: 0
          
          
          Show
          Rich Seddon added a comment - Using materialization I am able to reproduce tons of these exceptions in 1.9.1.1, none at all in 1.9.2. Also, using curl I see that 1.9.1.1 sets the session cookie with java user agent: curl -I http://localhost:8081/nexus/content/repositories/ --user admin:admin123 --user-agent "Java/1.6" HTTP/1.1 200 OK Date: Tue, 24 May 2011 17:57:40 GMT Set-Cookie: JSESSIONID=f0fb7eb4-11b1-4bb2-ac00-06f4b0fbe6f9; Path=/nexus; HttpOnly Set-Cookie: rememberMe=deleteMe; Path=/nexus; Max-Age=0; Expires=Mon, 23-May-2011 17:57:40 GMT Content-Type: text/html Last-Modified: Tue, 24 May 2011 17:57:40 GMT Date: Tue, 24 May 2011 17:57:40 GMT Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept Server: Noelios-Restlet-Engine/1.1.6-SONATYPE-5348-V4 Set-Cookie: rememberMe=deleteMe; Path=/nexus; Max-Age=0; Expires=Mon, 23-May-2011 17:57:40 GMT Set-Cookie: JSESSIONID=deleteMe; Path=/nexus; Max-Age=0; Expires=Mon, 23-May-2011 17:57:40 GMT Content-Length: 0 1.9.2 does not. Also verified with Apache-Maven user agent. curl -I http://localhost:8081/nexus/content/repositories/ --user admin:admin123 --user-agent "Java/1.6" HTTP/1.1 200 OK Date: Tue, 24 May 2011 17:59:04 GMT Set-Cookie: rememberMe=deleteMe; Path=/nexus; Max-Age=0; Expires=Mon, 23-May-2011 17:59:04 GMT Content-Type: text/html Last-Modified: Tue, 24 May 2011 17:59:05 GMT Date: Tue, 24 May 2011 17:59:05 GMT Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept Server: Noelios-Restlet-Engine/1.1.6-SONATYPE-5348-V4 Content-Length: 0
          Hide
          eXo SWF Team added a comment -

          COOOOLLLL. Thx

          Show
          eXo SWF Team added a comment - COOOOLLLL. Thx
          Hide
          David Göransson added a comment -

          This is causing large problems for my organization, when will 1.9.2 be released? Can I access a release candidate or something?

          Show
          David Göransson added a comment - This is causing large problems for my organization, when will 1.9.2 be released? Can I access a release candidate or something?
          Hide
          Brian Demers added a comment -

          David, which edition are you using?

          Show
          Brian Demers added a comment - David, which edition are you using?
          Hide
          David Göransson added a comment -

          1.9.0.2, didn't seem to be a point to upgrade to 1.9.1.1 since the issue appears in that version as well.

          Show
          David Göransson added a comment - 1.9.0.2, didn't seem to be a point to upgrade to 1.9.1.1 since the issue appears in that version as well.
          Hide
          Arnaud Heritier added a comment -

          David, are you using the OSS or the PRO version ?

          Show
          Arnaud Heritier added a comment - David, are you using the OSS or the PRO version ?
          Hide
          David Göransson added a comment -

          Suddenly realized that you asked about edition and not version. I am using the Open Source Edition and it is a Hudson server which has problems uploading the artifacts to Nexus.

          Show
          David Göransson added a comment - Suddenly realized that you asked about edition and not version. I am using the Open Source Edition and it is a Hudson server which has problems uploading the artifacts to Nexus.
          Hide
          Arnaud Heritier added a comment -

          Use Jenkins instead
          More seriously it was a wrong setting on the hudson side ?

          Show
          Arnaud Heritier added a comment - Use Jenkins instead More seriously it was a wrong setting on the hudson side ?
          Hide
          David Göransson added a comment -

          What kind of setting can I change to work around this? I have just been waiting for 1.9.2 with the fix.

          Since Hudson/Jenkins uses Maven and Maven is in the list that Brian mentions, I guess I need the fix?

          Show
          David Göransson added a comment - What kind of setting can I change to work around this? I have just been waiting for 1.9.2 with the fix. Since Hudson/Jenkins uses Maven and Maven is in the list that Brian mentions, I guess I need the fix?
          Hide
          Arnaud Heritier added a comment -

          ok, I misunderstand your comment. I though you fixed it on hudson side.
          Thus yes you'll need the new version (or you can try a SNAPSHOT of the OSS 1.9.2 but it may be dangerous in production ... https://repository.sonatype.org/content/groups/forge/org/sonatype/nexus/nexus-oss-webapp/1.9.2-SNAPSHOT/nexus-oss-webapp-1.9.2-20110614.064827-143-bundle.zip )
          Brian told me it should be out in ~2 weeks if everything is fine ...

          Show
          Arnaud Heritier added a comment - ok, I misunderstand your comment. I though you fixed it on hudson side. Thus yes you'll need the new version (or you can try a SNAPSHOT of the OSS 1.9.2 but it may be dangerous in production ... https://repository.sonatype.org/content/groups/forge/org/sonatype/nexus/nexus-oss-webapp/1.9.2-SNAPSHOT/nexus-oss-webapp-1.9.2-20110614.064827-143-bundle.zip ) Brian told me it should be out in ~2 weeks if everything is fine ...
          Hide
          Petr Novak added a comment -

          This issue is not Fixed, we have nexus-oss-webapp-1.9.2.2, Jenkins ver. 1.413, mavenVersion 2.2.1
          and the log on Nexus contains the same Exceptions as in this issue:

          2011-09-09 01:27:02 ERROR [p-14807813-3599] - org.mortbay.log - /nexus/content/groups/public/com/sun/org/apache/xml/internal/resolver/20050927/resolver-20050927.jar
          jvm 1 | org.apache.shiro.session.UnknownSessionException: There is no session with id [27834465-72c6-4f2a-8db3-0e09f280b0b4]
          jvm 1 | at org.apache.shiro.session.mgt.eis.AbstractSessionDAO.readSession(AbstractSessionDAO.java:170)
          jvm 1 | at org.apache.shiro.session.mgt.eis.CachingSessionDAO.readSession(CachingSessionDAO.java:261)
          jvm 1 | at org.apache.shiro.session.mgt.DefaultSessionManager.retrieveSessionFromDataSource(DefaultSessionManager.java:236)
          jvm 1 | at org.apache.shiro.session.mgt.DefaultSessionManager.retrieveSession(DefaultSessionManager.java:222)
          jvm 1 | at org.apache.shiro.session.mgt.AbstractValidatingSessionManager.doGetSession(AbstractValidatingSessionManager.java:118)
          jvm 1 | at org.apache.shiro.session.mgt.AbstractNativeSessionManager.lookupSession(AbstractNativeSessionManager.java:105)
          jvm 1 | at org.apache.shiro.session.mgt.AbstractNativeSessionManager.lookupRequiredSession(AbstractNativeSessionManager.java:109)
          jvm 1 | at org.apache.shiro.session.mgt.AbstractNativeSessionManager.setAttribute(AbstractNativeSessionManager.java:213)
          jvm 1 | at org.apache.shiro.session.mgt.DelegatingSession.setAttribute(DelegatingSession.java:151)
          jvm 1 | at org.apache.shiro.session.ProxiedSession.setAttribute(ProxiedSession.java:128)
          jvm 1 | at org.apache.shiro.mgt.DefaultSecurityManager.bind(DefaultSecurityManager.java:174)
          jvm 1 | at org.apache.shiro.mgt.DefaultSecurityManager.login(DefaultSecurityManager.java:284)
          jvm 1 | at org.apache.shiro.subject.support.DelegatingSubject.login(DelegatingSubject.java:247)
          jvm 1 | at org.sonatype.nexus.security.filter.authc.NexusHttpAuthenticationFilter.executeAnonymousLogin(NexusHttpAuthenticationFilter.java:237)
          jvm 1 | at org.sonatype.nexus.security.filter.authc.NexusHttpAuthenticationFilter.onAccessDenied(NexusHttpAuthenticationFilter.java:168)
          jvm 1 | at org.apache.shiro.web.filter.AccessControlFilter.onAccessDenied(AccessControlFilter.java:133)
          jvm 1 | at org.apache.shiro.web.filter.AccessControlFilter.onPreHandle(AccessControlFilter.java:162)
          jvm 1 | at org.apache.shiro.web.filter.PathMatchingFilter.preHandle(PathMatchingFilter.java:177)
          jvm 1 | at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:131)
          jvm 1 | at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:81)
          jvm 1 | at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
          jvm 1 | at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:359)
          jvm 1 | at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:275)
          jvm 1 | at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
          jvm 1 | at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
          jvm 1 | at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:344)
          jvm 1 | at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:272)
          jvm 1 | at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:81)
          jvm 1 | at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1148)

          Show
          Petr Novak added a comment - This issue is not Fixed, we have nexus-oss-webapp-1.9.2.2, Jenkins ver. 1.413, mavenVersion 2.2.1 and the log on Nexus contains the same Exceptions as in this issue: 2011-09-09 01:27:02 ERROR [p-14807813-3599] - org.mortbay.log - /nexus/content/groups/public/com/sun/org/apache/xml/internal/resolver/20050927/resolver-20050927.jar jvm 1 | org.apache.shiro.session.UnknownSessionException: There is no session with id [27834465-72c6-4f2a-8db3-0e09f280b0b4] jvm 1 | at org.apache.shiro.session.mgt.eis.AbstractSessionDAO.readSession(AbstractSessionDAO.java:170) jvm 1 | at org.apache.shiro.session.mgt.eis.CachingSessionDAO.readSession(CachingSessionDAO.java:261) jvm 1 | at org.apache.shiro.session.mgt.DefaultSessionManager.retrieveSessionFromDataSource(DefaultSessionManager.java:236) jvm 1 | at org.apache.shiro.session.mgt.DefaultSessionManager.retrieveSession(DefaultSessionManager.java:222) jvm 1 | at org.apache.shiro.session.mgt.AbstractValidatingSessionManager.doGetSession(AbstractValidatingSessionManager.java:118) jvm 1 | at org.apache.shiro.session.mgt.AbstractNativeSessionManager.lookupSession(AbstractNativeSessionManager.java:105) jvm 1 | at org.apache.shiro.session.mgt.AbstractNativeSessionManager.lookupRequiredSession(AbstractNativeSessionManager.java:109) jvm 1 | at org.apache.shiro.session.mgt.AbstractNativeSessionManager.setAttribute(AbstractNativeSessionManager.java:213) jvm 1 | at org.apache.shiro.session.mgt.DelegatingSession.setAttribute(DelegatingSession.java:151) jvm 1 | at org.apache.shiro.session.ProxiedSession.setAttribute(ProxiedSession.java:128) jvm 1 | at org.apache.shiro.mgt.DefaultSecurityManager.bind(DefaultSecurityManager.java:174) jvm 1 | at org.apache.shiro.mgt.DefaultSecurityManager.login(DefaultSecurityManager.java:284) jvm 1 | at org.apache.shiro.subject.support.DelegatingSubject.login(DelegatingSubject.java:247) jvm 1 | at org.sonatype.nexus.security.filter.authc.NexusHttpAuthenticationFilter.executeAnonymousLogin(NexusHttpAuthenticationFilter.java:237) jvm 1 | at org.sonatype.nexus.security.filter.authc.NexusHttpAuthenticationFilter.onAccessDenied(NexusHttpAuthenticationFilter.java:168) jvm 1 | at org.apache.shiro.web.filter.AccessControlFilter.onAccessDenied(AccessControlFilter.java:133) jvm 1 | at org.apache.shiro.web.filter.AccessControlFilter.onPreHandle(AccessControlFilter.java:162) jvm 1 | at org.apache.shiro.web.filter.PathMatchingFilter.preHandle(PathMatchingFilter.java:177) jvm 1 | at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:131) jvm 1 | at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:81) jvm 1 | at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66) jvm 1 | at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:359) jvm 1 | at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:275) jvm 1 | at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90) jvm 1 | at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83) jvm 1 | at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:344) jvm 1 | at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:272) jvm 1 | at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:81) jvm 1 | at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1148)
          Hide
          Brian Demers added a comment -

          Which wagon are you using?

          Show
          Brian Demers added a comment - Which wagon are you using?
          Show
          Petr Novak added a comment - The default one, we don't specify/change the wagon provider in our configuration. By http://maven.apache.org/guides/mini/guide-wagon-providers.html the default provider for HTTP/HTTPS Wagons is lightweight. From maven log: Downloading: http://192.168.4.160:8081/nexus/content/groups/pluginsGroup/org/apache/maven/wagon/wagon-file/1.0-beta-6/wagon-file-1.0-beta-6.pom Downloading: http://192.168.4.160:8081/nexus/content/groups/pluginsGroup/org/apache/maven/wagon/wagon-providers/1.0-beta-6/wagon-providers-1.0-2K Downloading: http://192.168.4.160:8081/nexus/content/groups/pluginsGroup/org/apache/maven/wagon/wagon/1.0-beta-6/wagon-1.0-beta-6.pom Downloading: http://192.168.4.160:8081/nexus/content/groups/pluginsGroup/org/apache/maven/wagon/wagon-provider-api/1.0-beta-6/wagon-provider-api-Downloading: http://192.168.4.160:8081/nexus/content/groups/pluginsGroup/org/apache/maven/maven-plugin-parameter-documenter/2.2.1/maven-plugin-1K Downloading: http://192.168.4.160:8081/nexus/content/groups/pluginsGroup/org/apache/maven/wagon/wagon-http-lightweight/1.0-beta-6/wagon-http-lightweight-1.0-beta-6.pom Downloading: http://192.168.4.160:8081/nexus/content/groups/pluginsGroup/org/apache/maven/wagon/wagon-http-shared/1.0-beta-6/wagon-http-shared-1.0-beta-6.pom
          Hide
          Brian Demers added a comment -

          Does Jenkins change the User-Agent ?

          Show
          Brian Demers added a comment - Does Jenkins change the User-Agent ?
          Hide
          Petr Novak added a comment -

          I'm not sure, in my opinion Jenkins starts only the maven build and the comunication with the Nexus is managed only by maven not by jenkins. But we will try to dump the HTTP communication between Nexus and Maven, so we will see the headers.

          BTW: There are some other infos in nexus log:
          2011-09-08 01:41:47 INFO [Thread-13] - o.a.s.s.m.AbstractV~ - Validating all active sessions...
          2011-09-08 01:41:47 INFO [Thread-13] - o.a.s.s.m.AbstractV~ - Finished session validation. [9907] sessions were stopped.
          2011-09-08 02:41:47 INFO [Thread-13] - o.a.s.s.m.AbstractV~ - Validating all active sessions...
          2011-09-08 02:41:47 INFO [Thread-13] - o.a.s.s.m.AbstractV~ - Finished session validation. [91] sessions were stopped.

          And we have problems with
          java.io.IOException: Too many open files
          o.s.t.DefaultTimeli~ - Failed to add a timeline record
          org.sonatype.timeline.TimelineException: Failed to persist timeline record to data file!
          But this is not problem in Nexus, it is about our environment and we will solve this soon.
          I hope - this should not corresponds to problem with org.apache.shiro.session.UnknownSessionException

          Show
          Petr Novak added a comment - I'm not sure, in my opinion Jenkins starts only the maven build and the comunication with the Nexus is managed only by maven not by jenkins. But we will try to dump the HTTP communication between Nexus and Maven, so we will see the headers. BTW: There are some other infos in nexus log: 2011-09-08 01:41:47 INFO [Thread-13] - o.a.s.s.m.AbstractV~ - Validating all active sessions... 2011-09-08 01:41:47 INFO [Thread-13] - o.a.s.s.m.AbstractV~ - Finished session validation. [9907] sessions were stopped. 2011-09-08 02:41:47 INFO [Thread-13] - o.a.s.s.m.AbstractV~ - Validating all active sessions... 2011-09-08 02:41:47 INFO [Thread-13] - o.a.s.s.m.AbstractV~ - Finished session validation. [91] sessions were stopped. And we have problems with java.io.IOException: Too many open files o.s.t.DefaultTimeli~ - Failed to add a timeline record org.sonatype.timeline.TimelineException: Failed to persist timeline record to data file! But this is not problem in Nexus, it is about our environment and we will solve this soon. I hope - this should not corresponds to problem with org.apache.shiro.session.UnknownSessionException
          Hide
          Petr Novak added a comment -

          BTW: The problem with org.apache.shiro.session.UnknownSessionException is not for each request, the problem occurred occasionally, when the Nexus is under heavy load during nightly builds that downloads/uploads many libraries. So after build there are many sessions:

          2011-09-09 01:41:47 INFO [Thread-13 ] - o.a.s.s.m.AbstractV~ - Validating all active sessions...
          2011-09-09 01:41:47 INFO [Thread-13 ] - o.a.s.s.m.AbstractV~ - Finished session validation. [9992] sessions were stopped.
          2011-09-09 02:41:47 INFO [Thread-13 ] - o.a.s.s.m.AbstractV~ - Validating all active sessions...
          2011-09-09 02:41:47 INFO [Thread-13 ] - o.a.s.s.m.AbstractV~ - Finished session validation. [1943] sessions were stopped.
          2011-09-09 03:00:00 INFO [pool-1-thread-8] - o.s.n.c.a.DefaultNe~ - Applying Nexus Configuration...

          But the exception occurred 14-minutes before this session cleaning
          2011-09-09 01:27:02 ERROR [p-14807813-3599] - org.mortbay.log
          org.apache.shiro.session.UnknownSessionException: There is no session with id [27834465-72c6-4f2a-8db3-0e09f280b0b4]

          Show
          Petr Novak added a comment - BTW: The problem with org.apache.shiro.session.UnknownSessionException is not for each request, the problem occurred occasionally, when the Nexus is under heavy load during nightly builds that downloads/uploads many libraries. So after build there are many sessions: 2011-09-09 01:41:47 INFO [Thread-13 ] - o.a.s.s.m.AbstractV~ - Validating all active sessions... 2011-09-09 01:41:47 INFO [Thread-13 ] - o.a.s.s.m.AbstractV~ - Finished session validation. [9992] sessions were stopped. 2011-09-09 02:41:47 INFO [Thread-13 ] - o.a.s.s.m.AbstractV~ - Validating all active sessions... 2011-09-09 02:41:47 INFO [Thread-13 ] - o.a.s.s.m.AbstractV~ - Finished session validation. [1943] sessions were stopped. 2011-09-09 03:00:00 INFO [pool-1-thread-8] - o.s.n.c.a.DefaultNe~ - Applying Nexus Configuration... But the exception occurred 14-minutes before this session cleaning 2011-09-09 01:27:02 ERROR [p-14807813-3599] - org.mortbay.log org.apache.shiro.session.UnknownSessionException: There is no session with id [27834465-72c6-4f2a-8db3-0e09f280b0b4]
          Hide
          Brian Demers added a comment -

          Exactly, because Maven is stateless, we try and detect maven request to help with this.

          If the user agent starts with one of the following, nexus will NOT create a session

          Apache-Maven
          Java/
          Apache Ivy/
          curl/
          Wget/

          Let me know what your user-agent is. If Hudson/Jenkins messes with the user agent, we can add it to the list.

          Show
          Brian Demers added a comment - Exactly, because Maven is stateless, we try and detect maven request to help with this. If the user agent starts with one of the following, nexus will NOT create a session Apache-Maven Java/ Apache Ivy/ curl/ Wget/ Let me know what your user-agent is. If Hudson/Jenkins messes with the user agent, we can add it to the list.
          Hide
          Rich Seddon added a comment -

          The "too many open files" message is not the cause of this problem, but it is undoubtedly causing other problems.

          This typically occurs because the Lucene indexes used by Nexus can periodically consume 10-20 file handles per repository (this is in addition to the baseline that Nexus will consume, of course).

          I'm assuming this is running on Linux?

          If so, you can increase this limit by adding the following to /etc/security/limits.conf (where "nexus" is the UID of the user running Nexus).

          #<domain>      <type>  <item>         <value>
          #
          nexus          hard    nofile          2048
          nexus          soft    nofile          2048
          
          

          This will take effect immediately for new processes, so all you need to do is restart Nexus

          Note: On Ubuntu, you also need to add the following line to /etc/pam.d/common-session

          session required pam_limits.so
          

          The most likely areas of damage after running out of file handles are the Lucene indexes and the repository storage areas.

          To fix the indexes, schedule a full re-index of all repositories. The other indexes are in what is known as the 'timeline', which is used to record events. These will be rebuilt automatically on restart if Nexus detects they are corrupted.

          In the storage area, Nexus may have created zero length files. This happens because a directory entries can still be created on a full disk. To find these, run the following in sonatype-work/nexus/storage:

              find . -type f -size 0
          

          Double check that the above worked correctly, and then to remove them run:

              find . type f -size 0 |xargs rm
          
          Show
          Rich Seddon added a comment - The "too many open files" message is not the cause of this problem, but it is undoubtedly causing other problems. This typically occurs because the Lucene indexes used by Nexus can periodically consume 10-20 file handles per repository (this is in addition to the baseline that Nexus will consume, of course). I'm assuming this is running on Linux? If so, you can increase this limit by adding the following to /etc/security/limits.conf (where "nexus" is the UID of the user running Nexus). #<domain> <type> <item> <value> # nexus hard nofile 2048 nexus soft nofile 2048 This will take effect immediately for new processes, so all you need to do is restart Nexus Note: On Ubuntu, you also need to add the following line to /etc/pam.d/common-session session required pam_limits.so The most likely areas of damage after running out of file handles are the Lucene indexes and the repository storage areas. To fix the indexes, schedule a full re-index of all repositories. The other indexes are in what is known as the 'timeline', which is used to record events. These will be rebuilt automatically on restart if Nexus detects they are corrupted. In the storage area, Nexus may have created zero length files. This happens because a directory entries can still be created on a full disk. To find these, run the following in sonatype-work/nexus/storage: find . -type f -size 0 Double check that the above worked correctly, and then to remove them run: find . type f -size 0 |xargs rm
          Hide
          Petr Novak added a comment -

          We dump the HTTP-Requests to Nexus during the build and it should be OK, there are "Apache-Maven" so Jenkins does not change headers, it is all about maven:

          url:/nexus/content/groups/public/apache-oro/jakarta-oro/2.0.8/jakarta-oro-2.0.8.jar.sha1
          header:Accept-Encoding, value:gzip
          header:Pragma, value:no-cache
          header:User-Agent, value:Apache-Maven/2.2 (Java 1.6.0_13; Linux 2.6.18-164.11.1.el5) maven-artifact/2.2.1
          header:Host, value:192.168.4.160:8081
          header:Accept, value:text/html, image/gif, image/jpeg, ; q=.2, */; q=.2

          But I can not simulate the exception now, so we will be monitoring the logs and I will dump the request when the exception will be thrown again and we will see. May be there is some special situation, when the header is changed by someone, somewhere. It is no so critical for us, so when I catch the problematic header, we will see more .

          Thank you very much for your time and help, keep the issue closed. Thank you once again.

          And thank you for the "Too many open files" info, we will try to change settings in our linux.

          Show
          Petr Novak added a comment - We dump the HTTP-Requests to Nexus during the build and it should be OK, there are "Apache-Maven" so Jenkins does not change headers, it is all about maven: url:/nexus/content/groups/public/apache-oro/jakarta-oro/2.0.8/jakarta-oro-2.0.8.jar.sha1 header:Accept-Encoding, value:gzip header:Pragma, value:no-cache header:User-Agent, value:Apache-Maven/2.2 (Java 1.6.0_13; Linux 2.6.18-164.11.1.el5) maven-artifact/2.2.1 header:Host, value:192.168.4.160:8081 header:Accept, value:text/html, image/gif, image/jpeg, ; q=.2, */ ; q=.2 But I can not simulate the exception now, so we will be monitoring the logs and I will dump the request when the exception will be thrown again and we will see. May be there is some special situation, when the header is changed by someone, somewhere. It is no so critical for us, so when I catch the problematic header, we will see more . Thank you very much for your time and help, keep the issue closed. Thank you once again. And thank you for the "Too many open files" info, we will try to change settings in our linux.
          Hide
          eXo SWF Team added a comment -

          Brian, the only case I know where Jenkins/Hudson need to change the User Agent it is when you use the M2 Release Plugin : https://wiki.jenkins-ci.org/display/JENKINS/M2+Release+Plugin
          But it's not Jenkins/Hudson which are doing it. It is in your maven settings in the server config to avoid conflicts between several // releases

          
                <configuration>
                  <httpHeaders>
                    <property>
                      <name>User-Agent</name>
                      <value>Maven m2Release (java:${java.vm.version} ${env.BUILD_TAG}</value>
                    </property>
                  </httpHeaders>
                </configuration>
          

          The issue is that (at least in my case) this User-Agent will be used to deploy releases from jenkins but also for SNAPSHOTs. I didn't know this special behavior on nexus side based on User-Agent.

          Show
          eXo SWF Team added a comment - Brian, the only case I know where Jenkins/Hudson need to change the User Agent it is when you use the M2 Release Plugin : https://wiki.jenkins-ci.org/display/JENKINS/M2+Release+Plugin But it's not Jenkins/Hudson which are doing it. It is in your maven settings in the server config to avoid conflicts between several // releases <configuration> <httpHeaders> <property> <name>User-Agent</name> <value>Maven m2Release (java:${java.vm.version} ${env.BUILD_TAG}</value> </property> </httpHeaders> </configuration> The issue is that (at least in my case) this User-Agent will be used to deploy releases from jenkins but also for SNAPSHOTs. I didn't know this special behavior on nexus side based on User-Agent.
          Hide
          eXo SWF Team added a comment -

          I updated my config to have the User-Agent starting with Apache-Maven

          Show
          eXo SWF Team added a comment - I updated my config to have the User-Agent starting with Apache-Maven
          Hide
          Rich Seddon added a comment -

          Oh.... of course! Good catch. I bet that's the problem.

          Show
          Rich Seddon added a comment - Oh.... of course! Good catch. I bet that's the problem.
          Hide
          Brian Demers added a comment -

          Still happening in some cases,
          The running plan is do disable sessions for the anonymous user.

          Show
          Brian Demers added a comment - Still happening in some cases, The running plan is do disable sessions for the anonymous user.
          Hide
          Brian Demers added a comment -

          Anonymous login will NEVER get a session. If there is a unknown session, it will be removed, and the anonymous user will be logged in again.

          NOTE: I could not find a way to test this case manually. (I did create UT's that reproduced it)

          Show
          Brian Demers added a comment - Anonymous login will NEVER get a session. If there is a unknown session, it will be removed, and the anonymous user will be logged in again. NOTE: I could not find a way to test this case manually. (I did create UT's that reproduced it)
          Hide
          Peter Lynch added a comment -

          Tested manually via ui, enabling, disabling security. Also mucked with session timeouts and monitored the session cleanup validator for cleaning up sessions.

          Verified that no session cookies were sent to client when anonymous user used.

          Show
          Peter Lynch added a comment - Tested manually via ui, enabling, disabling security. Also mucked with session timeouts and monitored the session cleanup validator for cleaning up sessions. Verified that no session cookies were sent to client when anonymous user used.

            People

            • Assignee:
              Peter Lynch
              Reporter:
              Rich Seddon
            • Votes:
              2 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Date of First Response: