[JBoss JIRA] (WFLY-4245) https socket-binding still a dependency of http
by Giuseppe Mazzotta (JIRA)
[ https://issues.jboss.org/browse/WFLY-4245?page=com.atlassian.jira.plugin.... ]
Giuseppe Mazzotta updated WFLY-4245:
------------------------------------
Description:
Although this problem has been reported as fixed in WFLY-2836, I am still able to reproduce a failure by removing the https socket-binding from default standalone.xml configuration file:
{noformat}
--- standalone.xml.orig 2015-01-13 11:33:57.956000250 +0100
+++ standalone.xml 2015-01-13 11:34:04.456000250 +0100
@@ -375,11 +375,10 @@
<socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
<socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
<socket-binding name="http" port="${jboss.http.port:8080}"/>
- <socket-binding name="https" port="${jboss.https.port:8443}"/>
<socket-binding name="txn-recovery-environment" port="4712"/>
<socket-binding name="txn-status-manager" port="4713"/>
<outbound-socket-binding name="mail-smtp">
<remote-destination host="localhost" port="25"/>
</outbound-socket-binding>
</socket-binding-group>
-</server>
\ No newline at end of file
+</server>
{noformat}
Failure I receive is:
{noformat}
{noformat}
Is this expected behavior?
was:
Although this problem has been reported as fixed in WFLY-2836, I am still able to reproduce a failure by removing the https socket-binding from default standalone.xml configuration file:
{noformat}
--- standalone.xml.orig 2015-01-13 11:33:57.956000250 +0100
+++ standalone.xml 2015-01-13 11:34:04.456000250 +0100
@@ -375,11 +375,10 @@
<socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
<socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
<socket-binding name="http" port="${jboss.http.port:8080}"/>
- <socket-binding name="https" port="${jboss.https.port:8443}"/>
<socket-binding name="txn-recovery-environment" port="4712"/>
<socket-binding name="txn-status-manager" port="4713"/>
<outbound-socket-binding name="mail-smtp">
<remote-destination host="localhost" port="25"/>
</outbound-socket-binding>
</socket-binding-group>
-</server>
\ No newline at end of file
+</server>
{noformat}
Is this expected behavior?
> https socket-binding still a dependency of http
> -----------------------------------------------
>
> Key: WFLY-4245
> URL: https://issues.jboss.org/browse/WFLY-4245
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Environment: Linux 64bit
> Reporter: Giuseppe Mazzotta
> Assignee: Stuart Douglas
> Priority: Minor
>
> Although this problem has been reported as fixed in WFLY-2836, I am still able to reproduce a failure by removing the https socket-binding from default standalone.xml configuration file:
> {noformat}
> --- standalone.xml.orig 2015-01-13 11:33:57.956000250 +0100
> +++ standalone.xml 2015-01-13 11:34:04.456000250 +0100
> @@ -375,11 +375,10 @@
> <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
> <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
> <socket-binding name="http" port="${jboss.http.port:8080}"/>
> - <socket-binding name="https" port="${jboss.https.port:8443}"/>
> <socket-binding name="txn-recovery-environment" port="4712"/>
> <socket-binding name="txn-status-manager" port="4713"/>
> <outbound-socket-binding name="mail-smtp">
> <remote-destination host="localhost" port="25"/>
> </outbound-socket-binding>
> </socket-binding-group>
> -</server>
> \ No newline at end of file
> +</server>
> {noformat}
> Failure I receive is:
> {noformat}
> {noformat}
> Is this expected behavior?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4245) https socket-binding still a dependency of http
by Giuseppe Mazzotta (JIRA)
Giuseppe Mazzotta created WFLY-4245:
---------------------------------------
Summary: https socket-binding still a dependency of http
Key: WFLY-4245
URL: https://issues.jboss.org/browse/WFLY-4245
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 8.2.0.Final
Environment: Linux 64bit
Reporter: Giuseppe Mazzotta
Assignee: Stuart Douglas
Priority: Minor
Although this problem has been reported as fixed in WFLY-2836, I am still able to reproduce a failure by removing the https socket-binding from default standalone.xml configuration file:
{noformat}
--- standalone.xml.orig 2015-01-13 11:33:57.956000250 +0100
+++ standalone.xml 2015-01-13 11:34:04.456000250 +0100
@@ -375,11 +375,10 @@
<socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
<socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
<socket-binding name="http" port="${jboss.http.port:8080}"/>
- <socket-binding name="https" port="${jboss.https.port:8443}"/>
<socket-binding name="txn-recovery-environment" port="4712"/>
<socket-binding name="txn-status-manager" port="4713"/>
<outbound-socket-binding name="mail-smtp">
<remote-destination host="localhost" port="25"/>
</outbound-socket-binding>
</socket-binding-group>
-</server>
\ No newline at end of file
+</server>
{noformat}
Is this expected behavior?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4244) Naming alias to datasource in deployment
by Frank Denninger (JIRA)
[ https://issues.jboss.org/browse/WFLY-4244?page=com.atlassian.jira.plugin.... ]
Frank Denninger commented on WFLY-4244:
---------------------------------------
Relevant Stacktrace
Caused by: java.lang.Exception: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"532c25d4-4815-49f4-a80e-7490f7d7865c.war#spxUnit\".__FIRST_PHASE__" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"532c25d4-4815-49f4-a80e-7490f7d7865c.war#spxUnit\".__FIRST_PHASE__: Failed to start service
Caused by: java.lang.NullPointerException"}}
at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134)
at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123)
at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85)
at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42)
at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55)
at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77)
at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64)
at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46)
at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:146)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:84)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:65)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80)
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:190)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:345)
at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:49)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:207)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:155)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> Naming alias to datasource in deployment
> ----------------------------------------
>
> Key: WFLY-4244
> URL: https://issues.jboss.org/browse/WFLY-4244
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Affects Versions: 8.2.0.Final
> Reporter: Frank Denninger
> Assignee: David Lloyd
> Priority: Minor
>
> Using a name alias to a datasource that is defined in the deployment (with a *-ds.xml in the .war) causes a npe when jpa tries to resolve that datasource with the alias.
> <lookup name="java:/de/datasource/sub" lookup="java:/de/datasource/main"/>
> When both the datasource and name-alias are defined in the standalone.xml it works as expected.
>
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4072) Unable to Enable JTA for a Datasource
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/WFLY-4072?page=com.atlassian.jira.plugin.... ]
Stefano Maestri resolved WFLY-4072.
-----------------------------------
Resolution: Incomplete Description
I'm not able to reproduce the bug. Maybe no more present in upstream, or at least I need more context to reproduce it as pointed out in my last comment
> Unable to Enable JTA for a Datasource
> -------------------------------------
>
> Key: WFLY-4072
> URL: https://issues.jboss.org/browse/WFLY-4072
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 8.1.0.Final
> Environment: Windows 7
> Java 8u25
> WildFly 8.1.0.Final
> Reporter: shinzey shinzey
> Assignee: Stefano Maestri
> Priority: Critical
> Labels: Datasource, JTA, ejb, wildfly
>
> Whenever trying to enable JTA, the following error is reported:
> Unknown error
> Unexpected HTTP response: 500
> Request
> {
> "name" => "test",
> "user-name" => "test",
> "password" => "test",
> "security-domain" => "",
> "jndi-name" => "java:/datasource/test",
> "transaction-isolation" => "TRANSACTION_READ_COMMITTED",
> "new-connection-sql" => "",
> "connection-url" => "jdbc:derby://localhost:1527/test",
> "driver-class" => "org.apache.derby.jdbc.ClientDriver",
> "jta" => true,
> "pool-name" => "",
> "use-ccm" => false,
> "datasource-class" => "",
> "valid-connection-checker-class-name" => "",
> "check-valid-connection-sql" => "",
> "background-validation" => false,
> "background-validation-millis" => -1L,
> "validate-on-match" => false,
> "stale-connection-checker-class-name" => "",
> "exception-sorter-class-name" => "",
> "prepared-statements-cache-size" => -1L,
> "share-prepared-statements" => false,
> "enabled" => false,
> "driver-name" => "Derby_org.apache.derby.jdbc.ClientDriver_10_10",
> "operation" => "enable",
> "address" => [
> ("subsystem" => "datasources"),
> ("data-source" => "test")
> ]
> }
> Response
> Internal Server Error
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014750: Operation handler failed to complete",
> "rolled-back" => true
> }
> Due to this issue, EJB's transaction management does not work. I tested the same database on GlassFish and JTA works fine.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (ELY-118) Reloadable File-backed KeyStore
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-118?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse commented on ELY-118:
--------------------------------------
On demand reload instead of dynamic reload may also be a consideration - although that could be accomplished within the subsystem by recreating it anyway.
> Reloadable File-backed KeyStore
> -------------------------------
>
> Key: ELY-118
> URL: https://issues.jboss.org/browse/ELY-118
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: KeyStores
> Reporter: David Lloyd
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Alpha1
>
>
> File-backed keystores can generically be made reloadable. This can be done by creating a KeyStore wrapper which contains an {{AtomicReference<KeyStore>}}. The wrapper also has a file name reference, and will initialize itself from that file. It would use an NIO.2 file watcher to monitor the file for changes; when the file is changed, the watcher attempts to re-load the file into a new KeyStore instance (using cached protection parameters). If successful, the new KeyStore replaces the old one atomically, providing atomic and clean real-time update capability.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JGRP-1876) MERGE3 : Strange number and content of subgroups
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1876?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1876 at 1/13/15 2:07 AM:
---------------------------------------------------------
Another (perhaps different) issue brought up by Dan:
I might have brought this up before, but I'm seeing some weird (and quite rare) stuff with MERGE3 and multiple partitions merging at the same time.
I have a cluster with three nodes: S, T, and U. I split it in 3 partitions with DISCARD, then I disable DISCARD on a single node (U, which will be the merge coordinator when the partitions merge back). Then I create another node V and make it join U's cluster.
After this, I disable DISCARD on S and T, and I wait for the partitions to join. Sometimes, however, the merge doesn't go as planned, and U is excluded from the merge:
{noformat}
11:13:06,230 DEBUG (Incoming-1,U:) [GMS] U: installing view [U|4] (2) [U, V]
11:13:06,251 DEBUG (testng-ClusterTopologyManagerTest:) [GMS] V: installing view [U|4] (2) [U, V]
11:13:06,264 DEBUG (testng-ClusterTopologyManagerTest:) [ClusterTopologyManagerTest] Merging the cluster partitions
11:13:06,271 TRACE (ViewHandler,U:) [GMS] U: got all ACKs (1) from joiners for view [U|4]
11:13:12,721 TRACE (Timer-2,T:) [MERGE3] discovery protocol returned 3 responses: 3 rsps (2 coords) [done]
11:13:13,059 DEBUG (Timer-3,T:) [MERGE3] I (T) will be the merge leader
11:13:13,059 TRACE (Timer-3,T:) [MERGE3] merge participants are [T, V, S]
11:13:13,101 DEBUG (ViewHandler,T:) [Merger] T: I will be the leader. Starting the merge task for 4 coords
11:13:13,102 DEBUG (MergeTask,T:) [Merger] T: merge task T::4 started with 3 coords
11:13:13,102 TRACE (INT-2,T:) [GMS] T: got merge response from T, merge_id=T::4, merge data is sender=T, view=[T|3] (1) [T], digest=T: [1 (1)]
11:13:13,143 TRACE (INT-1,T:) [GMS] T: got merge response from S, merge_id=T::4, merge data is sender=S, view=[S|4] (1) [S], digest=S: [15 (15)]
11:13:13,143 TRACE (INT-2,T:) [GMS] T: got merge response from V, merge_id=T::4, merge data is sender=V, view=[U|4] (1) [V], digest=V: [0 (0)]
11:13:13,143 DEBUG (MergeTask,T:) [Merger] T: installing merge view [T|5] (3 members) in 3 coords
11:13:13,143 DEBUG (MergeTask,T:) [Merger] T: merge T::4 took 41 ms
11:13:13,143 TRACE (Incoming-1,T:) [GMS] T: mcasting view MergeView::[T|5] (3) [T, S, V], 2 subgroups: [S|4] (1) [S], [T|3] (1) [T] (3 mbrs)
{noformat}
I'm not sure why, but V suddenly reports being the only one in view U|4, and the number of coords is 2, then 4, and then 3. Can you take a look if maybe there's something wrong with the logging?
Ideally I'd like U to always be part of the merge, but I'm not sure if it's missing because Discovery.findMembers is called with async = true or because there's a problem with our TEST_PING protocol implementation. The next best thing would be to exclude V from the merge, since it's not really a coordinator.
I haven't been able to reproduce this even when I re-enabled DISCARD on U before disabling it on S and T, so I've given up on obtaining a reliable reproducer for now. I have attached the full log, in case there's something else there that could help.
was (Author: belaban):
Another (perhaps different) issue brought up by Dan:
I might have brought this up before, but I'm seeing some weird (and quite rare) stuff with MERGE3 and multiple partitions merging at the same time.
I have a cluster with three nodes: S, T, and U. I split it in 3 partitions with DISCARD, then I disable DISCARD on a single node (U, which will be the merge coordinator when the partitions merge back). Then I create another node V and make it join U's cluster.
After this, I disable DISCARD on S and T, and I wait for the partitions to join. Sometimes, however, the merge doesn't go as planned, and U is excluded from the merge:
11:13:06,230 DEBUG (Incoming-1,U:) [GMS] U: installing view [U|4] (2) [U, V]
11:13:06,251 DEBUG (testng-ClusterTopologyManagerTest:) [GMS] V: installing view [U|4] (2) [U, V]
11:13:06,264 DEBUG (testng-ClusterTopologyManagerTest:) [ClusterTopologyManagerTest] Merging the cluster partitions
11:13:06,271 TRACE (ViewHandler,U:) [GMS] U: got all ACKs (1) from joiners for view [U|4]
11:13:12,721 TRACE (Timer-2,T:) [MERGE3] discovery protocol returned 3 responses: 3 rsps (2 coords) [done]
11:13:13,059 DEBUG (Timer-3,T:) [MERGE3] I (T) will be the merge leader
11:13:13,059 TRACE (Timer-3,T:) [MERGE3] merge participants are [T, V, S]
11:13:13,101 DEBUG (ViewHandler,T:) [Merger] T: I will be the leader. Starting the merge task for 4 coords
11:13:13,102 DEBUG (MergeTask,T:) [Merger] T: merge task T::4 started with 3 coords
11:13:13,102 TRACE (INT-2,T:) [GMS] T: got merge response from T, merge_id=T::4, merge data is sender=T, view=[T|3] (1) [T], digest=T: [1 (1)]
11:13:13,143 TRACE (INT-1,T:) [GMS] T: got merge response from S, merge_id=T::4, merge data is sender=S, view=[S|4] (1) [S], digest=S: [15 (15)]
11:13:13,143 TRACE (INT-2,T:) [GMS] T: got merge response from V, merge_id=T::4, merge data is sender=V, view=[U|4] (1) [V], digest=V: [0 (0)]
11:13:13,143 DEBUG (MergeTask,T:) [Merger] T: installing merge view [T|5] (3 members) in 3 coords
11:13:13,143 DEBUG (MergeTask,T:) [Merger] T: merge T::4 took 41 ms
11:13:13,143 TRACE (Incoming-1,T:) [GMS] T: mcasting view MergeView::[T|5] (3) [T, S, V], 2 subgroups: [S|4] (1) [S], [T|3] (1) [T] (3 mbrs)
I'm not sure why, but V suddenly reports being the only one in view U|4, and the number of coords is 2, then 4, and then 3. Can you take a look if maybe there's something wrong with the logging?
Ideally I'd like U to always be part of the merge, but I'm not sure if it's missing because Discovery.findMembers is called with async = true or because there's a problem with our TEST_PING protocol implementation. The next best thing would be to exclude V from the merge, since it's not really a coordinator.
I haven't been able to reproduce this even when I re-enabled DISCARD on U before disabling it on S and T, so I've given up on obtaining a reliable reproducer for now. I have attached the full log, in case there's something else there that could help.
> MERGE3 : Strange number and content of subgroups
> ------------------------------------------------
>
> Key: JGRP-1876
> URL: https://issues.jboss.org/browse/JGRP-1876
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.2
> Reporter: Karim AMMOUS
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6, 3.6.2
>
> Attachments: 4Subgroups.zip, DkeJgrpAddress.java, MergeTest4.java, MergeViewWith210Subgroups.log, SplitMergeTest.java, views.txt
>
>
> Using JGroups 3.4.2, a split occurred and a merge was processed successfully but number of subgroups is wrong (210 instead of 2).
> The final mergeView is correct and contains 210 members.
> Here is an extract of subviews:
> {code}
> INFO | Incoming-18,cluster,term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F] | [MyMembershipListener.java:126] | (middleware) | MergeView view ID = [serv-ZM2BU35940-58033:vt-14:192.168.55.55:1:CL(GROUP01)[F]|172]
> 210 subgroups
> [....
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [term-ETJ104215245-11092:host:192.168.56.72:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU38960-6907:asb:192.168.55.52:1:CL(GROUP01)[F]]
> [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]|171] (1) [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU47533-55240:vt-14:192.168.55.57:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU35943-49435:asb:192.168.55.51:1:CL(GROUP01)[F]]
> ....]
> {code}
> II wasn't able to reproduce that with a simple program. But I observed that merge was preceded by an ifdown/ifup on host 192.168.56.6. That member lost all others members, but it still present in their view.
> Example:
> {code}
> {A, B, C} => {A, B, C} and {C} => {A, B, C}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JGRP-1876) MERGE3 : Strange number and content of subgroups
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1876?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1876:
--------------------------------
Another (perhaps different) issue brought up by Dan:
I might have brought this up before, but I'm seeing some weird (and quite rare) stuff with MERGE3 and multiple partitions merging at the same time.
I have a cluster with three nodes: S, T, and U. I split it in 3 partitions with DISCARD, then I disable DISCARD on a single node (U, which will be the merge coordinator when the partitions merge back). Then I create another node V and make it join U's cluster.
After this, I disable DISCARD on S and T, and I wait for the partitions to join. Sometimes, however, the merge doesn't go as planned, and U is excluded from the merge:
11:13:06,230 DEBUG (Incoming-1,U:) [GMS] U: installing view [U|4] (2) [U, V]
11:13:06,251 DEBUG (testng-ClusterTopologyManagerTest:) [GMS] V: installing view [U|4] (2) [U, V]
11:13:06,264 DEBUG (testng-ClusterTopologyManagerTest:) [ClusterTopologyManagerTest] Merging the cluster partitions
11:13:06,271 TRACE (ViewHandler,U:) [GMS] U: got all ACKs (1) from joiners for view [U|4]
11:13:12,721 TRACE (Timer-2,T:) [MERGE3] discovery protocol returned 3 responses: 3 rsps (2 coords) [done]
11:13:13,059 DEBUG (Timer-3,T:) [MERGE3] I (T) will be the merge leader
11:13:13,059 TRACE (Timer-3,T:) [MERGE3] merge participants are [T, V, S]
11:13:13,101 DEBUG (ViewHandler,T:) [Merger] T: I will be the leader. Starting the merge task for 4 coords
11:13:13,102 DEBUG (MergeTask,T:) [Merger] T: merge task T::4 started with 3 coords
11:13:13,102 TRACE (INT-2,T:) [GMS] T: got merge response from T, merge_id=T::4, merge data is sender=T, view=[T|3] (1) [T], digest=T: [1 (1)]
11:13:13,143 TRACE (INT-1,T:) [GMS] T: got merge response from S, merge_id=T::4, merge data is sender=S, view=[S|4] (1) [S], digest=S: [15 (15)]
11:13:13,143 TRACE (INT-2,T:) [GMS] T: got merge response from V, merge_id=T::4, merge data is sender=V, view=[U|4] (1) [V], digest=V: [0 (0)]
11:13:13,143 DEBUG (MergeTask,T:) [Merger] T: installing merge view [T|5] (3 members) in 3 coords
11:13:13,143 DEBUG (MergeTask,T:) [Merger] T: merge T::4 took 41 ms
11:13:13,143 TRACE (Incoming-1,T:) [GMS] T: mcasting view MergeView::[T|5] (3) [T, S, V], 2 subgroups: [S|4] (1) [S], [T|3] (1) [T] (3 mbrs)
I'm not sure why, but V suddenly reports being the only one in view U|4, and the number of coords is 2, then 4, and then 3. Can you take a look if maybe there's something wrong with the logging?
Ideally I'd like U to always be part of the merge, but I'm not sure if it's missing because Discovery.findMembers is called with async = true or because there's a problem with our TEST_PING protocol implementation. The next best thing would be to exclude V from the merge, since it's not really a coordinator.
I haven't been able to reproduce this even when I re-enabled DISCARD on U before disabling it on S and T, so I've given up on obtaining a reliable reproducer for now. I have attached the full log, in case there's something else there that could help.
> MERGE3 : Strange number and content of subgroups
> ------------------------------------------------
>
> Key: JGRP-1876
> URL: https://issues.jboss.org/browse/JGRP-1876
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.2
> Reporter: Karim AMMOUS
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6, 3.6.2
>
> Attachments: 4Subgroups.zip, DkeJgrpAddress.java, MergeTest4.java, MergeViewWith210Subgroups.log, SplitMergeTest.java, views.txt
>
>
> Using JGroups 3.4.2, a split occurred and a merge was processed successfully but number of subgroups is wrong (210 instead of 2).
> The final mergeView is correct and contains 210 members.
> Here is an extract of subviews:
> {code}
> INFO | Incoming-18,cluster,term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F] | [MyMembershipListener.java:126] | (middleware) | MergeView view ID = [serv-ZM2BU35940-58033:vt-14:192.168.55.55:1:CL(GROUP01)[F]|172]
> 210 subgroups
> [....
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [term-ETJ104215245-11092:host:192.168.56.72:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU38960-6907:asb:192.168.55.52:1:CL(GROUP01)[F]]
> [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]|171] (1) [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU47533-55240:vt-14:192.168.55.57:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU35943-49435:asb:192.168.55.51:1:CL(GROUP01)[F]]
> ....]
> {code}
> II wasn't able to reproduce that with a simple program. But I observed that merge was preceded by an ifdown/ifup on host 192.168.56.6. That member lost all others members, but it still present in their view.
> Example:
> {code}
> {A, B, C} => {A, B, C} and {C} => {A, B, C}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JGRP-1905) FORK: RPCs might block if fork channel or fork stack is not available
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1905?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1905:
--------------------------------
Can you close this issue ?
> FORK: RPCs might block if fork channel or fork stack is not available
> ---------------------------------------------------------------------
>
> Key: JGRP-1905
> URL: https://issues.jboss.org/browse/JGRP-1905
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.6.2
>
>
> When we have nodes A,B,C,D, but fork-stack "fs-2" is not available on B, or fork-channel "ch-3" is not available on B, then an RPC invoked by A on all cluster nodes will time out.
> h5. Solution
> * Throw an exception on B if a fork-stack or -channel is not available on a target node. This way, the RPC would return quickly and B's response would be set to the exception (e.g. "fork channel fc-2 not available").
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months