Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-43927

Unable to login due to too many jsessionids creating a too large header

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • None

      If you use jenkins for a while, you will note that the jsessionid's never expire, and seem to get a new jsessionid.<id> every time. 

       

      Over time these build up until the header being sent to the server is so large it can't service the request. 

       

      What should happen: 

      • I should be able to log into jenkins
      • Jessionid should be like every other app server 

          [JENKINS-43927] Unable to login due to too many jsessionids creating a too large header

          Oleg Nenashev added a comment -

          JSESSION IDs are being managed correctly in Jenkins itself. The session Id expiration on the Jenkins side is being managed by async garbage collector, Cookies use the built-in expiration logic provided by the browser (unless the user explicitly logs out from Jenkins). So IMHO Jenkins manages sessions "like every other app".

          Could you please clarify your use-cases? Is it about Blue Ocean?

          Oleg Nenashev added a comment - JSESSION IDs are being managed correctly in Jenkins itself. The session Id expiration on the Jenkins side is being managed by async garbage collector, Cookies use the built-in expiration logic provided by the browser (unless the user explicitly logs out from Jenkins). So IMHO Jenkins manages sessions "like every other app". Could you please clarify your use-cases? Is it about Blue Ocean?

          Michael Neale added a comment - - edited

          oleg_nenashev no not blue ocean specifically, I have seen this for many years (you can see there are many many jsession id cookies). What could be causing this? I have never seen another app to "jsessionid.<someuniqueid>" - this seems specific to jenkins.

           

          I have seen this running hpi:run, but also on a "dogfood" server. This happens mainly when you restart things a lot (for development purposes)

           

          Michael Neale added a comment - - edited oleg_nenashev no not blue ocean specifically, I have seen this for many years (you can see there are many many jsession id cookies). What could be causing this? I have never seen another app to "jsessionid.<someuniqueid>" - this seems specific to jenkins.   I have seen this running hpi:run, but also on a "dogfood" server. This happens mainly when you restart things a lot (for development purposes)  

          Oleg Nenashev added a comment -

          Cannot say anything about hpi:run. In this mode Jetty runs differently using Jetty plugin fork for Maven. Everything may happen there.

          Regarding the common runs, I would need to investigate what happens on the common Jetty server. On the Jenkins side sessions are being persisted in a pretty strange way, but in general the session should be recovered after the restart

          Oleg Nenashev added a comment - Cannot say anything about hpi:run. In this mode Jetty runs differently using Jetty plugin fork for Maven. Everything may happen there. Regarding the common runs, I would need to investigate what happens on the common Jetty server. On the Jenkins side sessions are being persisted in a pretty strange way, but in general the session should be recovered after the restart

          Will McKinley added a comment -

          I just ran into this today.  I received a 413 Request Entity Too Large when trying to update plugins on Jenkins and noticed that there were a massive amount of JSESSIONIDs attached to the request.  Does Jenkins never purge these?

          Will McKinley added a comment - I just ran into this today.  I received a 413 Request Entity Too Large when trying to update plugins on Jenkins and noticed that there were a massive amount of JSESSIONIDs attached to the request.  Does Jenkins never purge these?

          Josh Soref added a comment -

          I claim I fixed this problem.

          It may have since resurfaced, but if it has, it's a new bug unrelated to the symptoms of this old bug.

          Josh Soref added a comment - I claim I fixed this problem. It may have since resurfaced, but if it has, it's a new bug unrelated to the symptoms of this old bug.

            Unassigned Unassigned
            michaelneale Michael Neale
            Votes:
            2 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: