Bug 985929 - Jcr2vfs migration tool hangs and does not exit properly after finishing the migration
Jcr2vfs migration tool hangs and does not exit properly after finishing the m...
Product: JBoss BRMS Platform 6
Classification: JBoss
Component: Business Central (Show other bugs)
Unspecified Unspecified
high Severity high
: ER2
: 6.0.1
Assigned To: Alexandre Porcelli
Petr Široký
: Regression, TestBlocker
Depends On:
  Show dependency treegraph
Reported: 2013-07-18 10:13 EDT by Petr Široký
Modified: 2014-08-06 15:58 EDT (History)
3 users (show)

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

Attachments (Terms of Use)

  None (edit)
Description Petr Široký 2013-07-18 10:13:50 EDT
Description of problem:
The jcr2vfs migration hangs and does not exit properly after the migration is completed. Seems like some background thread is preventing the app from exiting. 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Get the jcr2vfs migration tool and unzip it into DIR.
2. Download and unzip attached mortgages-sample-repo.zip and unzip it into $DIR/bin/inputJcr
3. Run $DIR/bin/runMigration.sh script

Actual results:
After the migration ends the migration tool hangs and does not exit properly. It needs to be manually terminated.

Expected results:
The migration tool should correctly exit.
Comment 1 Petr Široký 2013-07-29 07:36:05 EDT
Issue is probably caused by non-daemon thread "Git-Daemon-Accept" that is not correctly shutdown after the migration. Seems like problem is in underlying Git VFS implementation.
Comment 2 Petr Široký 2013-07-29 10:27:29 EDT
There is workaround for the "Git-Daemon-Accept" thread, simply set system property "org.kie.nio.git.deamon.enabled" to "false" and the thread won't even start.

However, seems like that is not the only thread that is blocking the process from exiting. After analyzing the thread dump, I found "pool-4-thread-1" (the name can be different) is also still running as is related to uberfire backend:

Part of thread dump related to mentioned thread:
"pool-4-thread-1" prio=10 tid=0x00007fe6ad799000 nid=0x2517 waiting on condition [0x00007fe680ebe000]    java.lang.Thread.State: TIMED_WAITING (sleeping) 	at java.lang.Thread.sleep(Native Method) 	at org.uberfire.backend.server.config.ConfigurationServiceImpl$CheckConfigurationUpdates.run(ConfigurationServiceImpl.java:218) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 	at java.lang.Thread.run(Thread.java:724)
Comment 3 Jervis Liu 2013-08-05 06:22:54 EDT
Comment 4 Petr Široký 2013-09-15 13:59:34 EDT
The git daemon thread was still running in non-daemon mode, so I disabled it as migration tool doesn't need it anyway. (Seems like the previous fix was applied only to master branch).

Comment 8 Petr Široký 2013-10-22 08:26:54 EDT
Issue is fixed, tested with community 6.0.x-SNAPSHOT. I will mark this as VERIFIED once the productized build arrives and I test it also there.
Comment 9 Petr Široký 2013-12-06 05:12:55 EST
The migration tool in ER5 is broken. See https://bugzilla.redhat.com/show_bug.cgi?id=1034931 . I will try to verify this issue again in ER6. Please note that issue is fixed in community 6.0.0.Final.
Comment 10 Petr Široký 2014-01-14 06:14:54 EST
Verified fixed in 6.0.0-ER7.
Comment 11 Petr Široký 2014-02-11 09:45:00 EST
Reopening as the issue back. Tested with the current 6.0.2-SNAPSHOT.
Comment 12 Alexandre Porcelli 2014-02-13 08:43:38 EST
Fix pushed to master and product branch:

(master) http://github.com/droolsjbpm/drools-wb/commit/4b39bb9ce
(6.0.x) http://github.com/droolsjbpm/drools-wb/commit/16f97da3e
Comment 13 Petr Široký 2014-02-19 18:02:31 EST
This issue is fixed in community 6.0.2-SNAPSHOT, but not in 6.0.1-ER1. The commit probably arrived after the sync. I am moving this back to MODIFIED and will verify it with next build.
Comment 14 Petr Široký 2014-03-07 10:20:31 EST
Verified fixed in 6.0.1-ER2.

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