Bug 1292546 - Multi-User Environment: Can't access project after modification of whitelist
Multi-User Environment: Can't access project after modification of whitelist
Product: JBoss BPMS Platform 6
Classification: JBoss
Component: Business Central (Show other bugs)
x86_64 Linux
high Severity medium
: ---
: ---
Assigned To: Alexandre Porcelli
Lukáš Petrovický
Depends On:
  Show dependency treegraph
Reported: 2015-12-17 13:02 EST by ooteniya
Modified: 2016-01-19 16:29 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Console Log, git tars, error screen (680.55 KB, application/zip)
2015-12-17 13:02 EST, ooteniya
no flags Details
console log, error screen, and git tars (436.05 KB, application/zip)
2015-12-17 13:10 EST, ooteniya
no flags Details

  None (edit)
Description ooteniya 2015-12-17 13:02:36 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
Comment 2 ooteniya 2015-12-17 13:10 EST
Created attachment 1106802 [details]
console log, error screen, and git tars
Comment 3 Justin Holmes 2015-12-17 13:22:31 EST
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.
Comment 4 Joe Wohar 2015-12-17 13:28:27 EST
Two separate teams ran into this same error. The separate attachments are from each of the two teams.
Comment 5 Marco Rietveld 2015-12-18 13:02:50 EST
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?
Comment 8 Justin Holmes 2015-12-21 13:37:11 EST
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.
Comment 9 Marco Rietveld 2016-01-08 05:37:40 EST
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.
Comment 10 Justin Holmes 2016-01-08 12:41:13 EST
@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
Comment 11 kowalmax.s 2016-01-19 13:59:31 EST
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.
Comment 12 kowalmax.s 2016-01-19 15:40:05 EST
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.
Comment 13 Wesley Stafford 2016-01-19 15:41:53 EST
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.
Comment 14 Justin Holmes 2016-01-19 16:05:11 EST
Can you provide the browsers you are using?
Comment 15 Wesley Stafford 2016-01-19 16:29:42 EST
We all used Chrome.

Note You need to log in before you can comment on or make changes to this bug.