Community
Participate
Working Groups
It seems like this execution path does include know workaround and I still see this error (btw, search for duplicates does not work for this stack trace too): -- Error Log -- Date: Tue Dec 26 17:32:53 EST 2006 Message: Unable to update attributes for http://jira.codehaus.org null Severity: Info Plugin ID: org.eclipse.mylar.core Stack Trace: org.tigris.jira.core.service.exceptions.AuthenticationException at org.tigris.jira.internal.core.service.soap.SoapJiraService.getProjectsNoSchemes(SoapJiraService.java:204) at org.tigris.jira.core.service.CachedRpcJiraServer.initializeProjects(CachedRpcJiraServer.java:193) at org.tigris.jira.core.service.CachedRpcJiraServer.refreshDetails(CachedRpcJiraServer.java:117) at org.eclipse.mylar.internal.jira.core.JiraServerFacade.refreshServerSettings(JiraServerFacade.java:117) at org.eclipse.mylar.internal.jira.core.JiraRepositoryConnector.updateAttributes(JiraRepositoryConnector.java:319) at org.eclipse.mylar.internal.tasks.ui.ScheduledTaskListSynchJob.run(ScheduledTaskListSynchJob.java:100) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
I am still seeing this issue in v20070105-1700 build.
My current theory is that automatic updates for the repository attributes may kill the auth token if update takes too long. So, we could try to disable that automatic update for JIRA (completely, or have a checkbox in repository preferences that to disable that). Other possibility could be to put some safeguard code around attributes retrieval or even run that in a separate job, to make it less destructive.
I've tried to debug it and come with the following findings: -- Current JiraRepositoryConnector.ensureServerConnectionValid(..) method don't really do anything. The reason it works when user hit "Validate" in repository settings is because server instance is wiped out and created from scratch (effectively loosing any cached attributes). -- I've tried to explicitly logout using JiraServer.logout(), but it seems like there is a bug in jira core services, so even if logout method is called, locally cached login token is not reset. All in all it seems like we can't do anything until this is fixed in jira core services. Another weird thing in jira core services, that it swallow any errors during fetching query results and even it catches the auth exception login token also is not reset up there.
Created attachment 56883 [details] mylar/context/zip
*** Bug 170093 has been marked as a duplicate of this bug. ***
Given comment#3, it looks like we're unfortunately stuck until the contribution for bug 165389 is approved.
Eugene: are you still seeing this on the latest dev build? It stopped happening in my workspace once I added the add/remove server code to the connection reset.
(In reply to comment #7) > Eugene: are you still seeing this on the latest dev build? It stopped > happening in my workspace once I added the add/remove server code to the > connection reset. It works ok when you online, but I noticed that it still fail when system goes offline (or in sleep/hybernate). The major problem is that JIRA core services don't report any errors back and just return empty result on query request. Also, that logging to stdout is polluting my console window and I may loose some stack traces now... Unknown Issue attribute: parent Unknown Issue attribute: attachments Unknown Issue attribute: subtasks
Eugene: are you still seeing this?
I don't think original report is relevant anymore. Let's track further issues in a separate reports.
