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

Updating Master configuration causes Jabber client to disconnect

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: jabber-plugin
    • Labels:
      None
    • Environment:
      Hudson 1.359, Jabber 1.10, IM 1.8
    • Similar Issues:

      Description

      Twice in the last few days I've had to update our Master node configuration, making changes only to a couple of environment variables. In both cases, the Jabber client in Hudson has disconnected and not reconnected. I don't see anything in the logs related to the disconnection or an attempt to reconnect:

      Jul 15, 2010 9:31:04 AM org.springframework.context.support.AbstractApplicationContext prepareRefresh
      INFO: Refreshing org.springframework.web.context.support.StaticWebApplicationContext@101318a: display name [Root WebApplicationContext]; startup date [Thu Jul 15 09:31:04 EDT 2010]; root of context hierarchy
      Jul 15, 2010 9:31:04 AM org.springframework.context.support.AbstractApplicationContext obtainFreshBeanFactory
      INFO: Bean factory for application context [org.springframework.web.context.support.StaticWebApplicationContext@101318a]: org.springframework.beans.factory.support.DefaultListableBeanFactory@15064b8
      Jul 15, 2010 9:31:04 AM org.springframework.beans.factory.support.DefaultListableBeanFactory preInstantiateSingletons
      INFO: Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@15064b8: defining beans [activeDirectory,authenticationManager]; root of factory hierarchy
      Jul 15, 2010 9:31:04 AM hudson.plugins.active_directory.ActiveDirectoryAuthenticationProvider <init>
      INFO: Active Directory domain is DC=example,DC=com
      Jul 15, 2010 9:31:04 AM org.springframework.context.support.AbstractApplicationContext prepareRefresh
      INFO: Refreshing org.springframework.web.context.support.StaticWebApplicationContext@fb8ca2: display name [Root WebApplicationContext]; startup date [Thu Jul 15 09:31:04 EDT 2010]; root of context hierarchy
      Jul 15, 2010 9:31:04 AM org.springframework.context.support.AbstractApplicationContext obtainFreshBeanFactory
      INFO: Bean factory for application context [org.springframework.web.context.support.StaticWebApplicationContext@fb8ca2]: org.springframework.beans.factory.support.DefaultListableBeanFactory@15f89a7
      Jul 15, 2010 9:31:04 AM org.springframework.beans.factory.support.DefaultListableBeanFactory preInstantiateSingletons
      INFO: Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@15f89a7: defining beans [filter,legacy]; root of factory hierarchy
      

      If I restart Hudson, our Hudson Jabber user reconnects fine.

        Attachments

          Activity

          Hide
          kutzi kutzi added a comment -

          Maybe you could make a stack dump of Hudson, if that problem occurs again?

          Show
          kutzi kutzi added a comment - Maybe you could make a stack dump of Hudson, if that problem occurs again?
          Hide
          oeuftete oeuftete added a comment -

          Here's something from the current thread dump (I haven't restarted, so it's not yet reconnected)... this help?

          IM-Reconnector-Thread
          
          "IM-Reconnector-Thread" Id=29 Group=main WAITING on java.util.concurrent.Semaphore$NonfairSync@1796f1e
          	at sun.misc.Unsafe.park(Native Method)
          	-  waiting on java.util.concurrent.Semaphore$NonfairSync@1796f1e
          	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
          	at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
          	at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:905)
          	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1217)
          	at java.util.concurrent.Semaphore.acquire(Semaphore.java:286)
          	at hudson.plugins.im.IMConnectionProvider$ConnectorRunnable.run(IMConnectionProvider.java:130)
          	at java.lang.Thread.run(Thread.java:619)
          
          
          Show
          oeuftete oeuftete added a comment - Here's something from the current thread dump (I haven't restarted, so it's not yet reconnected)... this help? IM-Reconnector-Thread "IM-Reconnector-Thread" Id=29 Group=main WAITING on java.util.concurrent.Semaphore$NonfairSync@1796f1e at sun.misc.Unsafe.park(Native Method) - waiting on java.util.concurrent.Semaphore$NonfairSync@1796f1e at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:905) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1217) at java.util.concurrent.Semaphore.acquire(Semaphore.java:286) at hudson.plugins.im.IMConnectionProvider$ConnectorRunnable.run(IMConnectionProvider.java:130) at java.lang.Thread.run(Thread.java:619)
          Hide
          kutzi kutzi added a comment -

          Not sure, yet, didn't have the time to look at this issue.
          But the stack dump of all threads would maybe be useful, too.

          Show
          kutzi kutzi added a comment - Not sure, yet, didn't have the time to look at this issue. But the stack dump of all threads would maybe be useful, too.
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in hudson
          User: : kutzi
          Path:
          trunk/hudson/plugins/instant-messaging/src/main/java/hudson/plugins/im/IMConnectionProvider.java
          trunk/hudson/plugins/ircbot/src/main/java/hudson/plugins/ircbot/v2/IRCConnectionProvider.java
          trunk/hudson/plugins/jabber/src/main/java/hudson/plugins/jabber/im/transport/JabberIMConnectionProvider.java
          http://jenkins-ci.org/commit/33295
          Log:
          JENKINS-6993 jabber/ircbot didn't reconnect after global config was changed

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : kutzi Path: trunk/hudson/plugins/instant-messaging/src/main/java/hudson/plugins/im/IMConnectionProvider.java trunk/hudson/plugins/ircbot/src/main/java/hudson/plugins/ircbot/v2/IRCConnectionProvider.java trunk/hudson/plugins/jabber/src/main/java/hudson/plugins/jabber/im/transport/JabberIMConnectionProvider.java http://jenkins-ci.org/commit/33295 Log: JENKINS-6993 jabber/ircbot didn't reconnect after global config was changed
          Hide
          kutzi kutzi added a comment -

          Could you also please try the snapshots attached to JENKINS-5233 to confirm if it fixes the bug?

          Show
          kutzi kutzi added a comment - Could you also please try the snapshots attached to JENKINS-5233 to confirm if it fixes the bug?
          Hide
          oeuftete oeuftete added a comment - - edited

          That did not fix it. I verified I was using the correct snapshot versions from JENKINS-5233.

          EDIT: I lie... it did fix it... it just took 30 seconds to sign back on. That is likely a side effect of unrelated Hudson memory bloat issues I'm working through here.

          Show
          oeuftete oeuftete added a comment - - edited That did not fix it. I verified I was using the correct snapshot versions from JENKINS-5233 . EDIT: I lie... it did fix it... it just took 30 seconds to sign back on. That is likely a side effect of unrelated Hudson memory bloat issues I'm working through here.
          Hide
          kutzi kutzi added a comment -

          The 30 sec delay is intentional as the same code is used to reconnect, if the connection failed for some other reason and I want to wait for some time in case the Jabber server has just some 'hickup'

          Show
          kutzi kutzi added a comment - The 30 sec delay is intentional as the same code is used to reconnect, if the connection failed for some other reason and I want to wait for some time in case the Jabber server has just some 'hickup'

            People

            • Assignee:
              kutzi kutzi
              Reporter:
              oeuftete oeuftete
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: