[JBoss JIRA] (WFLY-3073) MBeanServer.createMBean methods that take a classloader don't work
by Stuart Douglas (JIRA)
Stuart Douglas created WFLY-3073:
------------------------------------
Summary: MBeanServer.createMBean methods that take a classloader don't work
Key: WFLY-3073
URL: https://issues.jboss.org/browse/WFLY-3073
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JMX
Affects Versions: 8.0.0.Final
Reporter: Stuart Douglas
Assignee: Kabir Khan
Fix For: 8.0.1.Final
The MBeanServer.createMBean methods that take an "ObjectName loaderName" argument are completely broken in EAP 6.
These methods call findDelegate to make sure there is already an existing MBean registered with the given name passed in for the new MBean, or else it throws an exception.
This is obviously wrong, as there'd be no point in calling createMBean if it already existed.
javax.management.InstanceNotFoundException: test:service=Test
at org.jboss.as.jmx.PluggableMBeanServerImpl.findDelegate(PluggableMBeanServerImpl.java:1083)
at org.jboss.as.jmx.PluggableMBeanServerImpl.createMBean(PluggableMBeanServerImpl.java:253)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JGRP-1805) OverlappingMergeTest testMergeWithDifferentPartitions fails to create correct merged view
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1805?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1805:
---------------------------
Fix Version/s: (was: 3.5)
I removed the 3.5 target. Should the issue get fixed in 3.2.x, we can still forward-port it to master (3.5) if it exists in master.
> OverlappingMergeTest testMergeWithDifferentPartitions fails to create correct merged view
> -----------------------------------------------------------------------------------------
>
> Key: JGRP-1805
> URL: https://issues.jboss.org/browse/JGRP-1805
> Project: JGroups
> Issue Type: Bug
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JGRP-1801) DuplicateTest fails when testing OOB multicast to all three senders
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1801?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1801:
---------------------------
Fix Version/s: (was: 3.5)
I removed the 3.5 target. Should the issue get fixed in 3.2.x, we can still forward-port it to master (3.5) if it exists in master.
> 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
> 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.13
>
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1802:
---------------------------
Fix Version/s: (was: 3.5)
I removed the 3.5 target. Should the issue get fixed in 3.2.x, we can still forward-port it to master (3.5) if it exists in master.
> OverlappingUnicastMergeTest
> ---------------------------
>
> Key: JGRP-1802
> URL: https://issues.jboss.org/browse/JGRP-1802
> Project: JGroups
> Issue Type: Bug
> 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.
> For example, in testWithViewBC, channel A should receive messages #1 through #5 from channels A, B and C, but it does not receive #1 through #3 from channel C.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (WFLY-2959) Downgrade Jackson dependency
by Chris Roberts (JIRA)
[ https://issues.jboss.org/browse/WFLY-2959?page=com.atlassian.jira.plugin.... ]
Chris Roberts commented on WFLY-2959:
-------------------------------------
I believe the attached test project is the simplest recreation of the issues. Sorry, I'm not a king of writing test cases, so it's just a project with the issues, I don't know how to right unit tests for JAX-RS resources :-) You can test it after deployment with:
curl http://localhost:8080/org.jboss.test.test-jackson/rest/person/
- Uses Jackson2 (per POM and jboss-deployment-structure.xml)
- Uses jackson-datatype-hibernate4 (currently 2.3.0 as per jackson-core in wildfly 8 final) with a OneToMany entity
As it stands it gives the _configForWriter issue (with wildfly 8 final).
With wildfly 8 CR1 (change jackson-datatype-hibernate4 version to 2.2.3 in the pom.xml to match wildfly 8 cr1 jackson version), it will give a lazy initialisation exception I think.
Ideally this project should not give lazy initialisation exceptions and should work and return json in wildlfly 8.
> Downgrade Jackson dependency
> ----------------------------
>
> Key: WFLY-2959
> URL: https://issues.jboss.org/browse/WFLY-2959
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: REST
> Affects Versions: 8.0.0.Final
> Reporter: James Perkins
> Assignee: James Perkins
> Fix For: 8.0.1.Final
>
> Attachments: org.jboss.test.test-jackson.tar.gz
>
>
> Jackson was upgraded to 2.3.0 which contains a [bug|https://github.com/FasterXML/jackson-jaxrs-providers/commit/bafb6fb64...] that breaks RESTEasy. RESTEasy currently uses 2.2.1. Downgrading to at least 2.2.3, which is what CR1 is at, seems to resolve this issue.
> We should likely keep the version aligned with RESTEasy, but since CR1 was using 2.2.3 with no issues, I think reverting back to that should be fine.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (WFLY-2959) Downgrade Jackson dependency
by Chris Roberts (JIRA)
[ https://issues.jboss.org/browse/WFLY-2959?page=com.atlassian.jira.plugin.... ]
Chris Roberts edited comment on WFLY-2959 at 3/5/14 2:42 PM:
-------------------------------------------------------------
I believe the attached test project is the simplest recreation of the issues. Sorry, I'm not a king of writing test cases, so it's just a project with the issues, I don't know how to write unit tests for JAX-RS resources :-) You can test it after deployment with:
curl http://localhost:8080/org.jboss.test.test-jackson/rest/person/
- Uses Jackson2 (per POM and jboss-deployment-structure.xml)
- Uses jackson-datatype-hibernate4 (currently 2.3.0 as per jackson-core in wildfly 8 final) with a OneToMany entity
As it stands it gives the _configForWriter issue (with wildfly 8 final).
With wildfly 8 CR1 (change jackson-datatype-hibernate4 version to 2.2.3 in the pom.xml to match wildfly 8 cr1 jackson version), it will give a lazy initialisation exception I think.
Ideally this project should not give lazy initialisation exceptions and should work and return json in wildlfly 8.
was (Author: night199uk):
I believe the attached test project is the simplest recreation of the issues. Sorry, I'm not a king of writing test cases, so it's just a project with the issues, I don't know how to right unit tests for JAX-RS resources :-) You can test it after deployment with:
curl http://localhost:8080/org.jboss.test.test-jackson/rest/person/
- Uses Jackson2 (per POM and jboss-deployment-structure.xml)
- Uses jackson-datatype-hibernate4 (currently 2.3.0 as per jackson-core in wildfly 8 final) with a OneToMany entity
As it stands it gives the _configForWriter issue (with wildfly 8 final).
With wildfly 8 CR1 (change jackson-datatype-hibernate4 version to 2.2.3 in the pom.xml to match wildfly 8 cr1 jackson version), it will give a lazy initialisation exception I think.
Ideally this project should not give lazy initialisation exceptions and should work and return json in wildlfly 8.
> Downgrade Jackson dependency
> ----------------------------
>
> Key: WFLY-2959
> URL: https://issues.jboss.org/browse/WFLY-2959
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: REST
> Affects Versions: 8.0.0.Final
> Reporter: James Perkins
> Assignee: James Perkins
> Fix For: 8.0.1.Final
>
> Attachments: org.jboss.test.test-jackson.tar.gz
>
>
> Jackson was upgraded to 2.3.0 which contains a [bug|https://github.com/FasterXML/jackson-jaxrs-providers/commit/bafb6fb64...] that breaks RESTEasy. RESTEasy currently uses 2.2.1. Downgrading to at least 2.2.3, which is what CR1 is at, seems to resolve this issue.
> We should likely keep the version aligned with RESTEasy, but since CR1 was using 2.2.3 with no issues, I think reverting back to that should be fine.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months