|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Thanks Jordan for your detailed feedback. Reading the logs and reviewing the issue again, I begin to doubt that this is related to vcard in any way. At least there are no proofs that this is caused by the vcard code. The only hint towards vcard appears in the stacktrace, but this could be pure coincidence. After all it's the server who was closing the connection. The server logs from the relevant time period would sure be helpful.
So I don't think that the internal-server-error exception is related to the connection termination at all. What likely happened is that createVCard in JabberIMConnection:537 threw an internal-server-error XMPPException, but this does not mean that the connection will get closed. This only means that the server responded to the vcard IQ request from the client, with an IQ error. The timestamps also strengthen this thesis: the XMPPException is at 5:17:45, but the closing stream elements are send at 5:27:23.
@Jordan I think the answer, or at least helpful information what is going on, is found in the server logs (under the assumption that it's the server who is terminating the connection, the timestamps give no clear indication who sends the closing stream element first).
@kutzi I recommend reverting the related change and reopening this issue.