Red Hat Bugzilla – Bug 1292546
Multi-User Environment: Can't access project after modification of whitelist
Last modified: 2016-01-19 16:29:42 EST
Created attachment 1106799 [details]
Console Log, git tars, error screen
Description of problem:
After creating a process we couldn't import the model classes so we attempted to modify the white list in an effort to allow the process to find the correct ata objects
Version-Release number of selected component (if applicable):
How reproducible: Very
Steps to Reproduce:
1. Multi-User Environment
2. Create two repos in this environment
3. create two data models in one of the repos
4. Create business process in the other repo
5. import data models into process
6. Attempt to save
Actual results: Error: see attached screenshot
Expected results: Successful save and ability to build and deploy
Additional info: Attached is console log, screenshot and tar files containing .niogit repos for two of our teams that encountered this bug
Created attachment 1106802 [details]
console log, error screen, and git tars
Marco - I'm pretty sure this is related to having multiple users on the same host at the same time. I've had a team of 10 people working with 6.2.0 for weeks, and this issue occurred for multiple teams immediately after we moved to a shared authoring environment.
The hosts are inside Red Hat OS1 - I can provide you access to the VMs if that is helping for debugging.
Two separate teams ran into this same error. The separate attachments are from each of the two teams.
Olumide, the BZ title mentions modifying the whitelist, but the steps to reproduce the error do not mention that step.
Is modifying the whitelist necessary to reproduce this problem?
Marco - this occurred when multiple people were in the editors, working with the same set of files.My gut reaction is that this but is not related to the whitelist, but that was just the last file Olu had edited. My suspicion is that this is a race condition/synchronized issue around multiple users working in BC at once, which leads to a corrupted system.git. Logs support this, as its a jgit error.
Additionally, I have had many people in BC in single user environments and have not seen this issue in those environments.
FYI - restarting the server seems to solve the problem, but it is possible that the issue occurs again if multiple users are in the same environment at the same time.
Feel free to change ticket name to reflect this context.
Justin - could you see if this problem is reproducible when the jBPM (process/workflow) designer is *not* used? There's a suspicion that it's related to designer.
@Porcelli: this might eventually be for Tiho, if FS batch is not being used correctly in Designer.
@Maro - Ok that would not surprise me. It might take me a bit to get a group that could reproduce this. I was running a training program when we encountered this - I don't have the same number of people at my disposal at this time.
Let me see what I can do, and I'll get back to you with a plan. For the time being, I'll leave the needinfo flag so I don't lose track of this
We've got five people available to test this out.
We're creating new users for use in a single environment and will be attempting to recreate the issue.
Let us know how else we can be of assistance and we'll see what we can do.
We've tried a variety of tests but haven't been able to pin down the cause of the issue. Below I'll briefly describe the test and the results.
1. Followed the steps to reproduce with multiple users and then when one user deleted the two data objects from the first org unit, clicking on the business process that had those data objects imported resulted in the error.
2. Same as test one but no error was thrown after the data objects were deleted... We tried to compile and the build failed and so we added a rule-flow group to the business process, and then the error appeared. (the first test had a rule-flow group already added, this one did not until the end.)
3. We tried to see if the issue was related to the jBPM designer and so we never created a business process. We created data objects and a user encountered the error as soon as they tried to open work definitions in the default package of the first repository.
4. Wes found a way to repeatedly create the error on his machine but the steps did not reproduce the error when followed on other machines.
If someone can help us design tests to better isolate the issue we'd be happy to try them out.
Here's the process I used to reproduce it on my machine. It did not work on Stefan's for whatever reason.
I was able to reproduce this on my own without having anyone else logged in. Steps:
1. Create two repositories in the same organizational unit
2. Create two separate projects, one in each repo
3. In the first project in the first repo only, create a data model.
4. Add a field and save it (or you might just be able to edit the data model in some way to reproduce)
5. In the second project in the second repo, attempt to open workDefinitions in the <default> package.
The error should occur here. I've been able to reproduce it several times in a row using these steps.
Can you provide the browsers you are using?
We all used Chrome.