[JBoss JIRA] (WFLY-1172) mechanism to load tag libraries from module
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1172?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-1172:
--------------------------------------
Can you try with this patch? https://github.com/wildfly/wildfly/pull/6650
> mechanism to load tag libraries from module
> -------------------------------------------
>
> Key: WFLY-1172
> URL: https://issues.jboss.org/browse/WFLY-1172
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Reporter: Ivica Loncar
> Assignee: Stuart Douglas
> Priority: Critical
> Labels: modules, tag, taglib, tld
> Fix For: 9.0.0.Beta1
>
> Attachments: ExternalTld.txt, ExternalTldParsingDeploymentProcessor.java.diff
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> tag libraries are scanned only if they appear in jar inside WEB-INF/lib or are defined in tld under WEB-INF.
> The simplest scenario to explain why this is a problem: portlet 2 defines standard portlet taglib, but the classes in this file come from concrete implementations. Currently I see no way to use 2 different portals in a portable way.
> Please provide a way to notify a relevant subsystem for web applications that specific module contains a .tld.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 3 months
[JBoss JIRA] (WFLY-1172) mechanism to load tag libraries from module
by Frank Langelage (JIRA)
[ https://issues.jboss.org/browse/WFLY-1172?page=com.atlassian.jira.plugin.... ]
Frank Langelage updated WFLY-1172:
----------------------------------
Attachment: ExternalTld.txt
ExternalTldParsingDeploymentProcessor.java.diff
The .diff file shows the messages I put in.
The .txt file shows the messages from server.log for any web module of my ear.
> mechanism to load tag libraries from module
> -------------------------------------------
>
> Key: WFLY-1172
> URL: https://issues.jboss.org/browse/WFLY-1172
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Reporter: Ivica Loncar
> Assignee: Stuart Douglas
> Priority: Critical
> Labels: modules, tag, taglib, tld
> Fix For: 9.0.0.Beta1
>
> Attachments: ExternalTld.txt, ExternalTldParsingDeploymentProcessor.java.diff
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> tag libraries are scanned only if they appear in jar inside WEB-INF/lib or are defined in tld under WEB-INF.
> The simplest scenario to explain why this is a problem: portlet 2 defines standard portlet taglib, but the classes in this file come from concrete implementations. Currently I see no way to use 2 different portals in a portable way.
> Please provide a way to notify a relevant subsystem for web applications that specific module contains a .tld.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 3 months
[JBoss JIRA] (WFLY-1172) mechanism to load tag libraries from module
by Frank Langelage (JIRA)
[ https://issues.jboss.org/browse/WFLY-1172?page=com.atlassian.jira.plugin.... ]
Frank Langelage commented on WFLY-1172:
---------------------------------------
This implementation created a big performance drop when deploying my ear.
Before it took about 1 min 15s to deploy, now the 5 minutes are not enough and deployment gets a timeout and is stopped.
My ear is of 22 MB size, contains 23 ejb and web modules.
If I revert changes in UndertowSubsystemAdd.java everything is fine again.
I added some debug statements to ExternalTldParsingDeploymentProcessor.java and found out, that line 83 is causing the problem.
The first call of next for a deploymentunit takes a lot of time, subsequent calls for the same DU are no problem then.
Getting the first element takes about 1m - 1m 30s and lot of memory is used, as I see many lines of the garbage collector in this period.
> mechanism to load tag libraries from module
> -------------------------------------------
>
> Key: WFLY-1172
> URL: https://issues.jboss.org/browse/WFLY-1172
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Reporter: Ivica Loncar
> Assignee: Stuart Douglas
> Priority: Critical
> Labels: modules, tag, taglib, tld
> Fix For: 9.0.0.Beta1
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> tag libraries are scanned only if they appear in jar inside WEB-INF/lib or are defined in tld under WEB-INF.
> The simplest scenario to explain why this is a problem: portlet 2 defines standard portlet taglib, but the classes in this file come from concrete implementations. Currently I see no way to use 2 different portals in a portable way.
> Please provide a way to notify a relevant subsystem for web applications that specific module contains a .tld.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 3 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 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)
10 years, 3 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)
10 years, 3 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)
10 years, 3 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)
10 years, 3 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)
10 years, 3 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)
10 years, 3 months