Community
Participate
Working Groups
Created attachment 238051 [details] log showing the deadlock I had a scenario where I needed to setup a task with two subtasks and attach a file to both subtasks programatically from mylyn. The attaching of the file sometimes worked sometimes failed for one of the subtasks silently. Checking the webserver's errorlog of the bugzilla server showed the attached lines. Checking further, i came to see that MyLynn tries to handle such cases at least within one JVM: SubmitTaskAttachmentJob in it's constructor sets a MutexSchedulingRule, how ever it won't provide mutex scheduling as it would only work if the same mutex scheduling rule instance would be passed in to parallel running submitAttachemntJobs. When setting a common instance as scheduling rule, it DOES resolve my problem of fast task attachment. SO, I'd suggest to convert that org.eclipse.mylyn.internal.tasks.core.ITasksCoreConstants.MutexSchedulingRule into a enum singleton and passed that to jobs requiring mutex scheduling.
It sounds like you have a good understanding of the issue, would you be interested in pushing a review to Gerrit?
I've pushed an implementation candidate for review to gerrit. https://git.eclipse.org/r/#/c/20506/
This sounds like the dead lock is happening in Bugzilla? The mutex scheduling rule in Mylyn is intended to prevent the attachment job from running while the "root" scheduling rule is in use. The goal is not to prevent attachment jobs from running concurrently. Do you have a sense what exactly is causing the dead lock? I'd rather not limit concurrent attachment submission in general if this is a Bugzilla specific problem.
Endre, thanks a lot for pushing the review, but I am going to mark this as NOT_ECLIPSE for the following reasons: * This is actually a bug in Bugzilla and not the connector itself. * Since this resulted from a 3rd party program using the Bugzilla connector to attach files to multiple tasks simultaneously, it seems unlikely it would be triggered by using the Mylyn UI, and the 3rd party program should be able to work around the issue by ensuring the attachments are not submitted too close together. As Steffen said, it doesn't make sense to prevent concurrent attachment submission when this affects only one connector. Feel free to reopen this bug if you think the connector should handle this case better.
