[JBoss JIRA] (WFLY-3703) arq.container.domain.ManagementClient.readRootNode does not see servers on remote hosts
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-3703?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov edited comment on WFLY-3703 at 8/31/14 3:23 AM:
---------------------------------------------------------------
Can this be pushed into the 8.x branch as well?
The pull into wildfly-core was merged (https://github.com/wildfly/wildfly-core/pull/110)
was (Author: arcivanov):
Can this be pushed into the 8.x branch as well?
> arq.container.domain.ManagementClient.readRootNode does not see servers on remote hosts
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-3703
> URL: https://issues.jboss.org/browse/WFLY-3703
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite
> Affects Versions: 8.1.0.Final
> Environment: Linux aimobile-sm.servicemesh.com 3.15.6-200.fc20.x86_64 #1 SMP Fri Jul 18 02:36:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Arcadiy Ivanov
> Assignee: Alexey Loubyansky
> Priority: Blocker
> Attachments: non-recursive.txt, recursive-runtime.txt, recursive.txt
>
>
> Trying to use Arquillian with remote multi-host domain.
> Now see the code snippet below:
> * readRootNode calls readResource with includeRuntime set to true.
> * readResource also sets recursive to true.
> However due to this behavior of read-resource *no hosts other than domain controller's are visible to Arquillian*:
> [proxies – (boolean, default is false) – whether to include remote resources in a recursive query (i.e. host level resources from slave Host Controllers in a query of the Domain Controller; running server resources in a query of a host).|https://docs.jboss.org/author/display/WFLY8/Global+operations]
> +As a result if I have a DC on localhost with no servers and Host1 with Node1 on 127.0.0.2 and Host2 with Node2 on 127.0.0.3, Arquillian will not find ANY servers to deploy to - no proxies (remote hosts) will be enumerated.+
> {noformat}
> private void readRootNode() throws Exception {
> rootNode = readResource(new ModelNode());
> }
> private ModelNode readResource(ModelNode address) throws Exception {
> return readResource(address, true);
> }
> private ModelNode readResource(ModelNode address, boolean includeRuntime) throws Exception {
> final ModelNode operation = new ModelNode();
> operation.get(OP).set(READ_RESOURCE_OPERATION);
> operation.get(RECURSIVE).set("true");
> operation.get(INCLUDE_RUNTIME).set(includeRuntime);
> operation.get(OP_ADDR).set(address);
> return executeForResult(operation);
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (WFLY-3703) arq.container.domain.ManagementClient.readRootNode does not see servers on remote hosts
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-3703?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov commented on WFLY-3703:
--------------------------------------
Can this be pushed into the 8.x branch as well?
> arq.container.domain.ManagementClient.readRootNode does not see servers on remote hosts
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-3703
> URL: https://issues.jboss.org/browse/WFLY-3703
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite
> Affects Versions: 8.1.0.Final
> Environment: Linux aimobile-sm.servicemesh.com 3.15.6-200.fc20.x86_64 #1 SMP Fri Jul 18 02:36:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Arcadiy Ivanov
> Assignee: Alexey Loubyansky
> Priority: Blocker
> Attachments: non-recursive.txt, recursive-runtime.txt, recursive.txt
>
>
> Trying to use Arquillian with remote multi-host domain.
> Now see the code snippet below:
> * readRootNode calls readResource with includeRuntime set to true.
> * readResource also sets recursive to true.
> However due to this behavior of read-resource *no hosts other than domain controller's are visible to Arquillian*:
> [proxies – (boolean, default is false) – whether to include remote resources in a recursive query (i.e. host level resources from slave Host Controllers in a query of the Domain Controller; running server resources in a query of a host).|https://docs.jboss.org/author/display/WFLY8/Global+operations]
> +As a result if I have a DC on localhost with no servers and Host1 with Node1 on 127.0.0.2 and Host2 with Node2 on 127.0.0.3, Arquillian will not find ANY servers to deploy to - no proxies (remote hosts) will be enumerated.+
> {noformat}
> private void readRootNode() throws Exception {
> rootNode = readResource(new ModelNode());
> }
> private ModelNode readResource(ModelNode address) throws Exception {
> return readResource(address, true);
> }
> private ModelNode readResource(ModelNode address, boolean includeRuntime) throws Exception {
> final ModelNode operation = new ModelNode();
> operation.get(OP).set(READ_RESOURCE_OPERATION);
> operation.get(RECURSIVE).set("true");
> operation.get(INCLUDE_RUNTIME).set(includeRuntime);
> operation.get(OP_ADDR).set(address);
> return executeForResult(operation);
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (JGRP-1794) OOBTest method testNonBlockingUnicastOOBMessage fails to correctly receive all OOB mssages
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1794?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1794:
-----------------------------------------------
Paul Ferraro <paul.ferraro(a)redhat.com> changed the Status of [bug 910773|https://bugzilla.redhat.com/show_bug.cgi?id=910773] from NEW to CLOSED
> OOBTest method testNonBlockingUnicastOOBMessage fails to correctly receive all OOB mssages
> -------------------------------------------------------------------------------------------
>
> Key: JGRP-1794
> URL: https://issues.jboss.org/browse/JGRP-1794
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.2.13
> Environment: Solaris, RHEL, Windows, HPUX
> tcp stack only
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
>
> This test fails regularly on multiple platforms. It doesn't fail all the time, but perhaps on 5/10 platform executions.
> The test consists of a sender and a receiver. The receiver B will receive OOB messages but blocks on a latch for 25 seconds when it receives a non-OOB message. After 25 seconds, it unblocks and continues receiving
> The test does this:
> - send 1 regular message from A -> B
> - send 9 OOB meesages from A -> B
> - wait 20 seconds for messages to arrive
> - check that all 9 OOB messages have arrived
> - unblock the latch
> - check that all 10 message have arrived
> The test failures all involve the first 9 OOB messages not arriving completely. For example, sample lists of received messages before the first 20 second interval are:
> [3,2,6,8,9,10,4]
> [2,3,4,8,9,5]
> [2,3,4,8,7,9]
> [2,3,5,4,6]
> So, it appears that either the messages are slow to arrive or not arriving at all.
> A correct result looks like this:
> {noformat}
> list = [2, 4, 3, 7, 8, 9, 10, 5, 6]
> [main]: releasing latch
> list = [2, 4, 3, 7, 8, 9, 10, 5, 6, 1]
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (JGRP-1806) UnicastLoopbackTest fails to receive all messages in the allotted time
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1806?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1806:
-----------------------------------------------
Paul Ferraro <paul.ferraro(a)redhat.com> changed the Status of [bug 927921|https://bugzilla.redhat.com/show_bug.cgi?id=927921] from NEW to CLOSED
> UnicastLoopbackTest fails to receive all messages in the allotted time
> ----------------------------------------------------------------------
>
> Key: JGRP-1806
> URL: https://issues.jboss.org/browse/JGRP-1806
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.2.13
> Environment: RHEL, Windows, Solaris
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
>
> UnicastLoopbackTest.testUnicastMessagesWithLoopback() is failing with the following error:
> {noformat}
> Error Message
> Test timed out before all messages were received
> Stacktrace
> java.lang.AssertionError
> at org.testng.Assert.fail(Assert.java:94)
> at org.jgroups.tests.UnicastLoopbackTest.testUnicastMsgsWithLoopback(UnicastLoopbackTest.java:78)
> {noformat}
> The test does the following:
> - creates one channel with loopback enabled in the transport
> - the channel is assigned a receiver which collects the messages received and sets a Boolean valued Promise when all messages have been received
> - the channel sends 1000 messages to itself in a burst
> - waits 20 seconds for the promise to be set to true
> The test fails because the messages do not arrive within the allotted 20 seconds.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (JGRP-1805) OverlappingMergeTest testMergeWithDifferentPartitions fails to create correct merged view
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1805?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1805:
-----------------------------------------------
Paul Ferraro <paul.ferraro(a)redhat.com> changed the Status of [bug 920741|https://bugzilla.redhat.com/show_bug.cgi?id=920741] from NEW to CLOSED
> OverlappingMergeTest testMergeWithDifferentPartitions fails to create correct merged view
> -----------------------------------------------------------------------------------------
>
> Key: JGRP-1805
> URL: https://issues.jboss.org/browse/JGRP-1805
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.2.13
> Environment: RHEL
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
>
> This test does the following:
> - creates four channels a,b,c,d
> - injects views A: {A,C,B}, B:{A,C,B}, C:{A,C,B} and D: {B,A,C,D}
> - injects a merge event in each of channels A,B,C,D representing these four views
> - checks that all channels have the final view of size 4
> The test fails intermittently on RHEL, with the same failure each time:
> {noformat}
> 181595 [DEBUG] GMS: - A: installing view [A|2] [A]
> [testng] 181596 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|2]
> [testng] 181866 [TRACE] GMS: - view [A|3] [] is empty: will not multicast it (last view)
> [testng]
> [testng] -------------------------------------------------------------------
> [testng] GMS: address=A, cluster=OverlappingMergeTest, physical address=10.16.94.42:27199
> [testng] -------------------------------------------------------------------
> [testng] 184954 [TRACE] GMS: - A: no initial members discovered: creating group as first member
> [testng] 184954 [DEBUG] GMS: - A: installing view [A|0] [A]
> [testng] 184955 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
> [testng]
> [testng] -------------------------------------------------------------------
> [testng] GMS: address=B, cluster=OverlappingMergeTest, physical address=10.16.94.42:27200
> [testng] -------------------------------------------------------------------
> [testng] 184961 [TRACE] GMS: - B: initial_mbrs are A
> [testng] 184961 [DEBUG] GMS: - election results: {A=1}
> [testng] 184961 [DEBUG] GMS: - sending JOIN(B) to A
> [testng] 185013 [TRACE] GMS: - A: new members=[B], suspected=[], leaving=[], new view: [A|1] [A, B]
> [testng] 185014 [TRACE] GMS: - A: mcasting view [A|1] [A, B] (2 mbrs)
> [testng]
> [testng] 185025 [DEBUG] GMS: - A: installing view [A|1] [A, B]
> [testng] 185026 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|1]
> [testng] 185055 [TRACE] GMS: - B: JOIN-RSP=[A|1] [A, B] [size=2]
> [testng]
> [testng]
> [testng] 185055 [DEBUG] GMS: - B: installing view [A|1] [A, B]
> [testng] 185057 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|1]
> [testng]
> [testng] -------------------------------------------------------------------
> [testng] GMS: address=C, cluster=OverlappingMergeTest, physical address=10.16.94.42:27201
> [testng] -------------------------------------------------------------------
> [testng] 185064 [TRACE] GMS: - C: initial_mbrs are B A
> [testng] 185064 [DEBUG] GMS: - election results: {A=2}
> [testng] 185064 [DEBUG] GMS: - sending JOIN(C) to A
> [testng] 185108 [TRACE] GMS: - A: new members=[C], suspected=[], leaving=[], new view: [A|2] [A, B, C]
> [testng] 185108 [TRACE] GMS: - A: mcasting view [A|2] [A, B, C] (3 mbrs)
> [testng]
> [testng] 185117 [DEBUG] GMS: - A: installing view [A|2] [A, B, C]
> [testng] 185118 [DEBUG] GMS: - B: installing view [A|2] [A, B, C]
> [testng] 185119 [TRACE] GMS: - A: received all 2 ACKs from members for view [A|2]
> [testng] 185148 [TRACE] GMS: - C: JOIN-RSP=[A|2] [A, B, C] [size=3]
> [testng]
> [testng]
> [testng] 185149 [DEBUG] GMS: - C: installing view [A|2] [A, B, C]
> [testng] 185151 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|2]
> [testng]
> [testng] -------------------------------------------------------------------
> [testng] GMS: address=D, cluster=OverlappingMergeTest, physical address=10.16.94.42:27202
> [testng] -------------------------------------------------------------------
> [testng] 185164 [TRACE] GMS: - D: initial_mbrs are B C A
> [testng] 185164 [DEBUG] GMS: - election results: {A=3}
> [testng] 185164 [DEBUG] GMS: - sending JOIN(D) to A
> [testng] 185203 [TRACE] GMS: - A: new members=[D], suspected=[], leaving=[], new view: [A|3] [A, B, C, D]
> [testng] 185203 [TRACE] GMS: - A: mcasting view [A|3] [A, B, C, D] (4 mbrs)
> [testng]
> [testng] 185210 [DEBUG] GMS: - A: installing view [A|3] [A, B, C, D]
> [testng] 185211 [DEBUG] GMS: - B: installing view [A|3] [A, B, C, D]
> [testng] 185211 [DEBUG] GMS: - C: installing view [A|3] [A, B, C, D]
> [testng] 185213 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|3]
> [testng] 185242 [TRACE] GMS: - D: JOIN-RSP=[A|3] [A, B, C, D] [size=4]
> [testng]
> [testng]
> [testng] 185242 [DEBUG] GMS: - D: installing view [A|3] [A, B, C, D]
> [testng] 185242 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|3]
> [testng]
> [testng] ==== Injecting view [A|4] [A, C, B] into A, B and C ====
> [testng] 185243 [DEBUG] GMS: - A: installing view [A|4] [A, C, B]
> [testng] 185243 [DEBUG] GMS: - B: installing view [A|4] [A, C, B]
> [testng] 185244 [DEBUG] GMS: - C: installing view [A|4] [A, C, B]
> [testng]
> [testng] ==== Injecting view [B|4] [B, A, C, D] into D ====
> [testng]
> [testng] 185245 [DEBUG] GMS: - D: installing view [B|4] [B, A, C, D]
> [testng] A: [A|4] [A, C, B]
> [testng] B: [A|4] [A, C, B]
> [testng] C: [A|4] [A, C, B]
> [testng] D: [B|4] [B, A, C, D]
> [testng]
> [testng] ==== Injecting a merge event into A, B, C and D====
> [testng] 185251 [TRACE] GMS: - A: got merge response from A, merge_id=A::3, merge data is sender=A, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (0)], A: [4 (4)]
> [testng] 185253 [TRACE] GMS: - B: queue is suspended; request MERGE(4 views) is discarded
> [testng] 185255 [TRACE] GMS: - C: queue is suspended; request MERGE(4 views) is discarded
> [testng] 185255 [TRACE] GMS: - A: got merge response from B, merge_id=A::3, merge data is sender=B, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (1)], A: [4 (4)]
> [testng] 190286 [TRACE] GMS: - A: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
> [testng]
> [testng] 190286 [TRACE] GMS: - B: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
> [testng]
> [testng] 190317 [DEBUG] GMS: - A: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
> [testng] 190318 [DEBUG] GMS: - B: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
> [testng] 190318 [DEBUG] GMS: - C: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
> [testng] 190320 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|5]
> [testng] 190320 [TRACE] GMS: - B: received all 3 ACKs from members for view [A|5]
> [testng] A: [A|5] [A, B, C] (coord=true)
> [testng] B: [A|5] [A, B, C] (coord=false)
> [testng] C: [A|5] [A, B, C] (coord=false)
> [testng] D: [B|4] [B, A, C, D] (coord=false)
> [testng] 195277 [DEBUG] GMS: - D: sending LEAVE request to B
> [testng] FAIL: [1] org.jgroups.tests.OverlappingMergeTest.testMergeWithDifferentPartitions()
> {noformat}
> Whenever this test fails, I see that the queues are suspended on the initial merge attempt.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest fails to receive all messages
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1802:
-----------------------------------------------
Paul Ferraro <paul.ferraro(a)redhat.com> changed the Status of [bug 920741|https://bugzilla.redhat.com/show_bug.cgi?id=920741] from NEW to CLOSED
> OverlappingUnicastMergeTest fails to receive all messages
> ---------------------------------------------------------
>
> Key: JGRP-1802
> URL: https://issues.jboss.org/browse/JGRP-1802
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.2.13
> Environment: Solaris, RHEL
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
>
> OverlappingUnicastMergeTest does the following:
> - set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
> - the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
> - inject some new view into the channels which represents a view configuration which should be recovered from
> - send messages to the channels and check that the messages are received, despite the injected view
> OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms.
> What we expect to see is:
> {noformat}
> receiver A: ucasts=15
> receiver B: ucasts=15
> receiver C: ucasts=15
> {noformat}
> What we instead see is:
> {noformat}
> receiver A: ucasts=15
> receiver B: ucasts=11
> ucasts for B:
> B: unicast msg #1 from B B: unicast msg #2 from B B: unicast msg #3 from B B: unicast msg #4 from B B: unicast msg #5 from B A: unicast msg #1 from A C: unicast msg #2 from C C: unicast msg #3 from C A: unicast msg #4 from A C: unicast msg #4 from C C: unicast msg #5 from C
> {noformat}
> The order here is the order in which the unicasts were received from all three senders by the single receiver. For example, in the above, in testWithViewBC, channel A should receive messages #1 through #5 from channels A, B and C, but it does not receive #1 from channel C.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (JGRP-1812) ProgrammaticApiTest.testSharedTransport fails to receive correct number of messages
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1812?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1812:
-----------------------------------------------
Paul Ferraro <paul.ferraro(a)redhat.com> changed the Status of [bug 948762|https://bugzilla.redhat.com/show_bug.cgi?id=948762] from NEW to CLOSED
> ProgrammaticApiTest.testSharedTransport fails to receive correct number of messages
> -----------------------------------------------------------------------------------
>
> Key: JGRP-1812
> URL: https://issues.jboss.org/browse/JGRP-1812
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.2.14
> Environment: RHEL, Solaris
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.14
>
>
> ProgrammaticApiTest tests the use of the API for creating and configuring channels. One such test testSharedTransport tests the creation and use of a stack with a shared transport. This test does the following:
> - creates two channels A and B
> - creates a UDP-based shared transport stack
> - assigns the same stack to both channels
> - channel A connects to group cluster-one; channel B connects to group cluster-two
> - channel A multicasts 10 messages to its group; channel B multicasts 5 messages to its group
> - the test then waits for the correct number of multicast messages to arrive
> Problem:the test is failing because the receiver on channel A is receiving 20 messages instead of 10 messages.
> This test fails intermittently, but fairly regularly.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (JGRP-1801) DuplicateTest fails when testing OOB multicast to all three senders
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1801?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1801:
-----------------------------------------------
Paul Ferraro <paul.ferraro(a)redhat.com> changed the Status of [bug 927911|https://bugzilla.redhat.com/show_bug.cgi?id=927911] from NEW to CLOSED
> DuplicateTest fails when testing OOB multicast to all three senders
> -------------------------------------------------------------------
>
> Key: JGRP-1801
> URL: https://issues.jboss.org/browse/JGRP-1801
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.2.13
> Environment: Windows (18), Solaris (2), RHEL(1) where (x) is the number of failures seen
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.14
>
>
> DuplicateTest does the following:
> - creates three channels containing the DUPL layer called c1, c2, c3
> - DUPL is used to duplicate messages sent
> - channel receiver for channel each keeps a map of messages received from each sender
> - channels send messages: regular, OOB, or mixed
> - the test checks that the messages received by each channel are correct in number and in order
> The test testOOBMuloticastToAll3Senders is failing regularly on multple platforms. The test makes each of the channels send OOB multicast messages to the group, but only two of three members ever end up receiving the multicast messages. Al example of the failure:
> {noformat}
> Error Message
> expected size=3, msgs: [C2, C1]
> Stacktrace
> java.lang.AssertionError
> at org.jgroups.tests.DuplicateTest.check(DuplicateTest.java:217)
> at org.jgroups.tests.DuplicateTest.testOOBMulticastToAll3Senders(DuplicateTest.java:123)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (WFLY-3791) Allow deployment initialization to have read-access to portions of the model
by ofbiz brazil (JIRA)
[ https://issues.jboss.org/browse/WFLY-3791?page=com.atlassian.jira.plugin.... ]
ofbiz brazil commented on WFLY-3791:
------------------------------------
Well, be a question of luck in Jboss 7,1,1 sounds really weird for me.
Right now my current project works on Production without issues using @Startup EJB, as you say I should have faced anytime some error but I never got one related to it.
In my opinion Wildfly changed EJB box somewhere, but if it may possible to include any solution in Wildfly 8.2 I'd appreciate a lot!
Thanks!
> Allow deployment initialization to have read-access to portions of the model
> ----------------------------------------------------------------------------
>
> Key: WFLY-3791
> URL: https://issues.jboss.org/browse/WFLY-3791
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Environment: Java 7
> Reporter: ofbiz brazil
> Fix For: Awaiting Volunteers
>
>
> Hello,
> When there's a client trying to list a node for a security section, Wildfly says it does not exist but on Jboss 7.1.1 it works fine.
> Java Code:
> {code:java}
> final ModelNode request = new ModelNode();
> request.get(ClientConstants.OP).set("read-resource");
> request.get("recursive").set(true);
> request.get(ClientConstants.OP_ADDR).add("subsystem", "security");
> final ModelControllerClient client = ModelControllerClient.Factory.create(InetAddress.getByName("127.0.0.1"), 9999);
> final ModelNode response = client.execute(new OperationBuilder(request).build());
> final String section = response.get(ClientConstants.RESULT).get("security-domain")
> .get("pw_MSSQL_CAS_DS")
> {code}
> Result:
> ---------
> {code}
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014807: Management resource '[(\"subsystem\" => \"security\")]' not found",
> "rolled-back" => true
> }
> {code}
> Cheers,
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months