[JBoss JIRA] (JGRP-2092) MERGE3: merge never happens
by Neal Dillman (JIRA)
[ https://issues.jboss.org/browse/JGRP-2092?page=com.atlassian.jira.plugin.... ]
Neal Dillman updated JGRP-2092:
-------------------------------
Attachment: jgroups.txt
I believe that the attached output from several minutes of sendInfo() provides the view from every member as well as an implied state. Unfortunately, we have not had another repeat of the exact break I was referencing, but this one is an example of what is essentially the same thing.
Note that 10.214.51.102 is a member of 10.214.51.100's subgroup. However, 10.215.33.105 (and others) thinks that 10.214.51.102 is his coordinator -- hence they are in a "stuck membership state" can cannot get unstuck.
> MERGE3: merge never happens
> ---------------------------
>
> Key: JGRP-2092
> URL: https://issues.jboss.org/browse/JGRP-2092
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.11, 4.0
>
> Attachments: jgroups.txt
>
>
> (Reported by Neal Dillman)
> In the case below, a merge doesn't seem to happen. Write a unit test to reprodue this.
> {noformat}
> Host A view: B, X, Y, Z, A (where B should be coordinator)
> Host B view: C, Q, R, S, B (where C should be coordinator)
> Host C view: A, M, N, O, C (where A should be coordinator)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2092) MERGE3: merge never happens
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2092?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2092:
---------------------------
Summary: MERGE3: merge never happens (was: MERGE2: merge never happens)
> MERGE3: merge never happens
> ---------------------------
>
> Key: JGRP-2092
> URL: https://issues.jboss.org/browse/JGRP-2092
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.11, 4.0
>
>
> (Reported by Neal Dillman)
> In the case below, a merge doesn't seem to happen. Write a unit test to reprodue this.
> {noformat}
> Host A view: B, X, Y, Z, A (where B should be coordinator)
> Host B view: C, Q, R, S, B (where C should be coordinator)
> Host C view: A, M, N, O, C (where A should be coordinator)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2092) MERGE2: merge never happens
by Neal Dillman (JIRA)
[ https://issues.jboss.org/browse/JGRP-2092?page=com.atlassian.jira.plugin.... ]
Neal Dillman commented on JGRP-2092:
------------------------------------
The title currently reads: "MERGE2: merge never happens". I agree that the issue is likely present in MERGE2, but we have been working with MERGE3. Suggest editing the title
> MERGE2: merge never happens
> ---------------------------
>
> Key: JGRP-2092
> URL: https://issues.jboss.org/browse/JGRP-2092
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.11, 4.0
>
>
> (Reported by Neal Dillman)
> In the case below, a merge doesn't seem to happen. Write a unit test to reprodue this.
> {noformat}
> Host A view: B, X, Y, Z, A (where B should be coordinator)
> Host B view: C, Q, R, S, B (where C should be coordinator)
> Host C view: A, M, N, O, C (where A should be coordinator)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6882) A client is not able to invoke EJB's deployed as "HASingleton deployment"
by Enrique González Martínez (JIRA)
[ https://issues.jboss.org/browse/WFLY-6882?page=com.atlassian.jira.plugin.... ]
Enrique González Martínez reassigned WFLY-6882:
-----------------------------------------------
Assignee: Enrique González Martínez (was: Paul Ferraro)
> A client is not able to invoke EJB's deployed as "HASingleton deployment"
> -------------------------------------------------------------------------
>
> Key: WFLY-6882
> URL: https://issues.jboss.org/browse/WFLY-6882
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.Final, 11.0.0.Alpha1
> Reporter: Wolf-Dieter Fink
> Assignee: Enrique González Martínez
>
> Given that an application contains a SLSB and is clustered, any EJB client will be updated to have a view off all cluster members and is able to use and failover to any node in the cluster no matter whether it is in the initial list of servers.
> Now if the application is marked as "singleton-deployment" via jboss-all.xml and deployed to all servers only one server in a cluster will pick it and make it active.
> Now the expectation is that a client is routed to that server no matter whether this special server is included in the clients initial connection list.
> The interesting thing is that the client.log show that both servers are connected it the application is NOT marked as singleton
> But only the initial server is connected if the app is marked as singleton!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6892) Access logging for EJBs
by Andrig Miller (JIRA)
[ https://issues.jboss.org/browse/WFLY-6892?page=com.atlassian.jira.plugin.... ]
Andrig Miller commented on WFLY-6892:
-------------------------------------
I would add, that we need to be careful about the performance hit here. This should be off by default.
> Access logging for EJBs
> -----------------------
>
> Key: WFLY-6892
> URL: https://issues.jboss.org/browse/WFLY-6892
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Brad Maxwell
> Labels: affects_elytron
>
> Access logging for EJB requests similar to Web access logging would be very useful.
> Possibly something like:
> {code}
> [date-time] [host/IP of caller] [EJB Name] [EJB Method] [invocation id] Request Received ...
> [date-time] [host/IP of caller] [EJB Name] [EJB Method] invocation id] Starting Invocation ...
> [date-time] [host/IP of caller] [EJB Name] [EJB Method] invocation id] Finished Invocation ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months