Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1090907

Summary: Cluster sync on startup is not working
Product: [Retired] JBoss BRMS Platform 6 Reporter: Pedro Zapata <pzapataf>
Component: Business CentralAssignee: Maciej Swiderski <mswiders>
Status: CLOSED DUPLICATE QA Contact: Jiri Locker <jlocker>
Severity: unspecified Docs Contact:
Priority: high    
Version: 6.0.1CC: kverlaen, lpetrovi, rrajasek
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-08-27 05:42:11 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Debug Info none

Description Pedro Zapata 2014-04-24 11:38:43 UTC
Created attachment 889252 [details]
Debug Info

When the property 'org.uberfire.cluster.autostart' is set to true ( <property name="org.uberfire.cluster.autostart" value="true"/> )

an exception is thrown during cluster initialization. The problem is that the URI is not composed of a single one but with two concatenated URIs 
final URI fs = URI.create( fileSystemInfo.getScheme() + "://" + fileSystemInfo.getId() + "?sync=" + fileSystemInfo.getUri() + "&force" );

where fileSystemInfo().getUri() =
'git://127.0.0.1:9520/system\n
ssh://127.0.0.1:9521/system'

See screenshot for debug info.

The fix https://github.com/uberfire/uberfire/commit/f0a9b54634fcdaf3dbf5547870911cf186fcfe34 for BZ-1049390 solved a similar problem in the IOServiceClusterImpl$SyncFileSystemMessageHandler implementation, but was not applied to the start() method of IOServiceClusterImpl.

--------------
13:27:03,317 ERROR [stderr] (Thread-83) Exception in thread "Thread-83" java.lang.IllegalArgumentException
13:27:03,317 ERROR [stderr] (Thread-83)         at java.net.URI.create(URI.java:841)
13:27:03,317 ERROR [stderr] (Thread-83)         at org.uberfire.io.impl.cluster.IOServiceClusterImpl$2$1$1.run(IOServiceClusterImpl.java:182)
13:27:03,318 ERROR [stderr] (Thread-83) Caused by: java.net.URISyntaxException: Illegal character in query at index 49: default://system?sync=git://127.0.0.1:9520/system
13:27:03,318 ERROR [stderr] (Thread-83) ssh://127.0.0.1:9521/system&force
13:27:03,318 ERROR [stderr] (Thread-83)         at java.net.URI$Parser.fail(URI.java:2810)
13:27:03,318 ERROR [stderr] (Thread-83)         at java.net.URI$Parser.checkChars(URI.java:2983)
13:27:03,318 ERROR [stderr] (Thread-83)         at java.net.URI$Parser.parseHierarchical(URI.java:3073)
13:27:03,318 ERROR [stderr] (Thread-83)         at java.net.URI$Parser.parse(URI.java:3015)
13:27:03,318 ERROR [stderr] (Thread-83)         at java.net.URI.<init>(URI.java:577)
13:27:03,319 ERROR [stderr] (Thread-83)         at java.net.URI.create(URI.java:839)
13:27:03,319 ERROR [stderr] (Thread-83)         ... 1 more

Comment 2 Maciej Swiderski 2014-04-28 10:30:52 UTC
Pedro,

org.uberfire.cluster.autostart property must be set to false in clustered environment to avoid duplicated writes on cluster startup. The main issue here is that when there is something cloned on application start - like we take repositories from github for community both servers will clone the repositories and then (if cluster is auto started) start broadcasting clone repo events causing other cluster members to receive and re-clone repositories. That is undesired behavior and thus this auto start is disabled unless application is completely configured and running. 

Even if the same fix for URI would be applied it will cause issues described above and thus auto start must always be disabled for clustered setups.

Does that make sense to you?

Comment 3 Pedro Zapata 2014-05-21 08:06:48 UTC
Maciej,

Thanks for the clarification, however this raises a question.

How a newly created node will get in sync with the rest of the cluster's repositories? Is there a mechanism for this? Or is it assumed that all cluster's node will start from the same state?

Comment 4 Maciej Swiderski 2014-05-22 13:44:00 UTC
Pedro,

this is responsibility of helix and zookeeper to provide all sync information to the servers that join the cluster. It has be discovered not working properly and fixed as part of this bz https://bugzilla.redhat.com/show_bug.cgi?id=1100097 so once it gets verified by QA we should be good on this.

Comment 5 Maciej Swiderski 2014-08-27 05:42:11 UTC
I believe this can be closed as BZ 1100097 has been implemented and verified so this one is duplicate

*** This bug has been marked as a duplicate of bug 1100097 ***