| Summary: | Diagrams buggy for two instances of the same process | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise BRMS Platform 5 | Reporter: | Zuzana Krejčová <zkrejcov> | ||||||
| Component: | jBPM Console | Assignee: | Kris Verlaenen <kverlaen> | ||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Zuzana Krejčová <zkrejcov> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | BRMS 5.3.0.GA | CC: | atangrin, lpetrovi, mswiders | ||||||
| Target Milestone: | --- | Flags: | kverlaen:
needinfo+
|
||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2012-10-04 12:44:02 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Attachments: |
|
||||||||
Created attachment 572750 [details]
screenshot showing the bug
I have tried to reproduce this using the evaluation example that is included by default, but haven't been able to do so. Is it possible that the history log already contained older data from previous tests, that would show up? Using a clean install and then starting a number of evaluation processes and completing tasks in some of them seems to show the correct state for each of them. (In reply to comment #2) > I have tried to reproduce this using the evaluation example that is included by > default, but haven't been able to do so. Is it possible that the history log > already contained older data from previous tests, that would show up? Using a > clean install and then starting a number of evaluation processes and completing > tasks in some of them seems to show the correct state for each of them. Yes, with the Evaluation from the sample repo, it does not happen - I'm not sure why. It does happen with the two processes I supplied, even on clean install. I'm not sure what makes it go wrong and what makes it work as intended, but as far as I know, my two processes are defined well (according to the project documentation). If you manage to find anything wrong in them, please, let me know. Behold a way to reproduce this (even with the jbpm sample repo): 1) Import any repo with some processes (or just one process) and build it. 2) Log into the jbpm console. 3) Click the Processes and then the Process Overview. 4) Click on the process you want to start. 5) Click start, fill in a form and close the popup if you need to. 6) Click on the new instance (you can look at the diagram or not, doesn't matter). 7) Click start again to start a new instance. 8) Look at the diagram of the new instance. You'll see the bug now, even with the sample repo. If you don't do step 6, the diagrams look ok. It seems there might be some other conditions that make this work right/wrong, perhaps some race conditions, not sure yet. (In reply to comment #4) > Behold a way to reproduce this (even with the jbpm sample repo): > > 1) Import any repo with some processes (or just one process) and build it. > 2) Log into the jbpm console. > 3) Click the Processes and then the Process Overview. > 4) Click on the process you want to start. > 5) Click start, fill in a form and close the popup if you need to. > 6) Click on the new instance (you can look at the diagram or not, doesn't > matter). > 7) Click start again to start a new instance. > 8) Look at the diagram of the new instance. > > You'll see the bug now, even with the sample repo. If you don't do step 6, the > diagrams look ok. > > It seems there might be some other conditions that make this work right/wrong, > perhaps some race conditions, not sure yet. I followed all the steps to reproduce the problem but I couldn't. It keeps showing the right status of every process instance. I used the repository attached to this bz adn tried on Firefox 11 and Chrome 17.0.9... Is the intances table refreshed after you create new process instance or the selection is on the previous one? (In reply to comment #6) > I followed all the steps to reproduce the problem but I couldn't. It keeps > showing the right status of every process instance. I used the repository > attached to this bz adn tried on Firefox 11 and Chrome 17.0.9... > > Is the intances table refreshed after you create new process instance or the > selection is on the previous one? This is very disappointing. I tried again with freshly started computer and the behaviour is inconsistent again. I'm working with Firefox 10.0.1. Sometimes the bug shows, others it does not. I'm afraid I won't find any better way to reproduce this issue. Slow down your computer, make it swap to disk, perhaps you'll have better luck reproducing it. I'll keep my eyes open for anything that could help here; it reminds me a lot of the BZ 768135 - the slower the computer, the more it happens. Three people from the team have tried to reproduce this (even trying to slow down their computer with other heavy loads) but we've had no success in reproducing this. Since you are saying that the bugs occurs sometimes, does that mean that reopening the same diagram a second time might solve the issue? Reopening the diagram didn't help (relog, refreshing the instances' table or refreshing the browser didn't help either). If the diagram gets corrupted, it stays corrupted. It might help (or not) to know, it happens a lot when testing on Hudson/Jenkins Windows slaves (server 2k3 & 2k8), it is basically non-existent on RHEL slaves (5 & 6) and happens on my Fedora 15 - less after start up, more after a few hours of work. I also tried with a fresh install on my computer again with the same result. I thought that, perhaps, like with the BZ 768135, I'm clicking the Diagram button too soon - but waiting 2 seconds before any action didn't help. And just now, the bug got more pronounced after I deleted some instances. But this also doesn't have to mean anything. Since the behaviour seems to be consistent when reopening, I doubt this is a rendering or timing issue. My guess would be that the history log in this case contains information from the execution of process instances previously (or simultaneously in other sessions), which are then responsible for these incorrect markers. Would this be possible? Are you sure the history log does not contain any info other than the info that was added by executions in the jbpm-console itself? It is a good suggestion, but I doubt it. It happens with a clean install while nothing else of this nature is running. I unpacked the standalone version, copied configuration from the old standalone product, thrown away the old one and the repository/ & repository.xml & derby.log. Can't think of anything else that could be a problem - I'm running it on my computer with the in-memory db. The issue is still there after all this cleaning. I'm sorry that I couldn't give you a "better" answer. Could you paste the url you are using for connecting to the database? Because when using h2 for example, you can configure it to just use a file in your home folder to store information. e.g. in the community we use: jdbc:h2:tcp://localhost/runtime/jbpm-demo which I believe might create some db files in that location. I use it out-of-the-box (locally) and just add the right users and groups, so the url is:
jdbc:hsqldb:${jboss.server.data.dir}/hypersonic/localDB
That means the db files are in the server dir in <profile>/data/hypersonic/. I already knew that.. That directory is deleted each time I start the server locally (along with tmp/ and work/ just to be sure), it is not even there on a clean install.
There's only conf/, deploy/, deployers/, lib/ in <profile>/ on a clean install.
And this clean-up still does not prevent this bug.
Closing as duplicate. Although the relationship should technically be reversed, it will be easier this way. *** This bug has been marked as a duplicate of bug 861898 *** |
Created attachment 572749 [details] tested repository Description of problem: When two instances of the same process overlap (one is started before the other is finished), the diagram of the second one shows two red triangles instead of just one. If you start more instances, the behaviour is similar, just a bit more random, some instances have even 3 or 4 triangles, some just one. The diagrams show progress of the task. Having it this messy is just unfortunate with simple processes but with something more complicated, it is plain hell for the user. To the user, it looks like that step it points to will be repeated. It won't (and shouldn't) repeat though. Version-Release number of selected component (if applicable): BRMS 5.3.0 ER5 Steps to Reproduce: 1. Import and build the provided Guvnor repo. 2. Start a process and start the same one again. 3. Look at the diagram of the 2nd instance. Actual results: 2 red triangles where there should be only one. Expected results: Only one triangle, as with the first instance. Additional info: It is quite well visible, if you try with a process with some human task or a timer event, so that the process does not finish too quickly. Tested in Firefox 10.