February 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1800) OverlappingMergeTest testRegularMessageSending does not receive all expected mcast messages

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/JGRP-1800?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz commented on JGRP-1800: ------------------------------------------- I have reviewed the platform test results incorporating this change: - instances of the failure before the change (across all platforms): 18 - instances of this failure after the change (across all platforms): 0 So it appears that this was the root cause of the issue. I'm going to close this issue. > OverlappingMergeTest testRegularMessageSending does not receive all expected mcast messages > ------------------------------------------------------------------------------------------- > > Key: JGRP-1800 > URL: https://issues.jboss.org/browse/JGRP-1800 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.13 > Environment: RHEL, Solairis > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.2.13 > > > testRegularMessageSending is a kind of smoke test for the stack used in OverlappingMergeTest: > - three channels a,b,c are created with a particular stack (see modifyConfigs) > - each of a,b,c sends 5 multicast messages to the group, with message payloads "1", "2", "3", "4", "5" > - the receiver in each channel collects up the multicasts received > - the test checks that all 15 messages are received by each of the channels, and an assertion error is thrown is this is not the case > This test is failing occasionally. An example of the error: > {noformat} > Error Message > (C) num_mcasts=C: 1 C: 2 C: 3 C: 4 C: 5 A: 1 B: 1 A: 2 B: 2 B: 3 B: 4 A: 4 B: 5 A: 5 expected: 15) > Stacktrace > java.lang.AssertionError > at org.jgroups.tests.OverlappingMergeTest.checkReceivedMessages(OverlappingMergeTest.java:476) > at org.jgroups.tests.OverlappingMergeTest.testRegularMessageSending(OverlappingMergeTest.java:66) > {noformat} > This assertion error indicates that multicast #3 was not received from A by C. > This is a very simple scenario and failures should not be occurring. I mention this error as there are other merge tests, namely: > * testOverlappingMergeWithBC > * testOverlappingMergeWithABC > which are more complex, but when we look at their failures, they fail on an initial step similar to the one described above. -- 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

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1795) OOBTest testRandomRegularAndOOBMulticasts fails to receive all messages

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/JGRP-1795?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz commented on JGRP-1795: ------------------------------------------- I have reviewed the platform test results incorporating this change: instances of the failure before the change (across all platforms): 10 instances of this failure after the change (across all platforms): 0 So it appears that this was the root cause of the issue. I'm going to keep this open for another test run, just to confirm. > OOBTest testRandomRegularAndOOBMulticasts fails to receive all messages > ----------------------------------------------------------------------- > > Key: JGRP-1795 > URL: https://issues.jboss.org/browse/JGRP-1795 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.13 > Environment: RHEL(3/24), WIN (1/6), Solaris (6/24) where (x/y) means x failures over y test executions. > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.2.13 > > > This test does the following with two channels a and b: > - adds a DISCARD layer to a to disccard 50% of down messages > - sends 20 messages to the group, randomly using a and b as senders, and randomly choosing OOB or non-OOB > - wait 10 seconds for 20 messages to be received by each of a and b > - print out the messages received > - remove the DISCARD layer from a > - wait 2.5 seconds for further messages to arrive > - assert that 20 messages have arrived for each channel a and b > The test fails on the assertion, with results such as: > {noformat} > expected 20 elements, but got 19 (list=[1, 4, 3, 8, 6, 7, 10, 13, 15, 20, 2, 5, 9, 12, 14, 16, 17, 18, 19]), missing=[0, 11] > {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

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1794) OOBTest method testNonBlockingUnicastOOBMessage fails to correctly receive all OOB mssages

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/JGRP-1794?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz commented on JGRP-1794: ------------------------------------------- I have reviewed the platform test results incorporating this change: - instances of the failure before the change (across all platforms): 19 - instances of this failure after the change (across all platforms): 1 So it appears that this was the root cause of the issue. I'm going to keep this open for another test run, just to confirm. > 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 > 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 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

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1722) Improve performance of ENCRYPT protocol

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1722?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1722: -------------------------------- Parallelization doesn't help with message batches: all messages of a batch are decrypted sequentially (using the same cipher though), replaced with the decrypted message, and then the batch is passed up. Parallel decryption of the messages in a batch would probably help here, e.g. using the fork-join framework. > Improve performance of ENCRYPT protocol > --------------------------------------- > > Key: JGRP-1722 > URL: https://issues.jboss.org/browse/JGRP-1722 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.4 > Reporter: Martin Gencur > Assignee: Bela Ban > Fix For: 3.5 > > > A stress tests with the following setup showed that performance (reads and writes/sec) is halved when ENCRYPT protocol is enabled: > Infinispan had distributed sync cache with 2 owners on 4 nodes, no transactions. The stress test used 10 threads on each node accessing 1024 byte entries, no conflicts on keys, 20 % writes, 80 % reads. > It would be great if we could improve the performance of ENCRYPT protocol. -- 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

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2205) Undeployment prints null

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-2205?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-2205: ----------------------------------- Assignee: David Salter (was: Tomaz Cerar) > Undeployment prints null > ------------------------ > > Key: WFLY-2205 > URL: https://issues.jboss.org/browse/WFLY-2205 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Server > Affects Versions: 8.0.0.Beta1 > Reporter: Jesper Pedersen > Assignee: David Salter > Fix For: 8.0.1.Final > > > The following is printed during a shutdown of an .ear > {noformat} > 11:21:52,260 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015877: Stopped deployment null (runtime-name: msginflow1_mdb_msginflow_ejb.jar) in 16ms > 11:21:52,260 INFO [org.jboss.as.server.deployment] (MSC service thread 1-11) JBAS015877: Stopped deployment null (runtime-name: msginflow_mdb_msginflow_ejb.jar) in 16ms > 11:21:52,262 INFO [org.jboss.as.server.deployment] (MSC service thread 1-11) JBAS015877: Stopped deployment msginflow_mdb.ear (runtime-name: msginflow_mdb.ear) in 18ms > 11:21:52,387 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018558: Undeployed "msginflow_mdb.ear" (runtime-name: "msginflow_mdb.ear") > {noformat} > The 'null' part of the .jar undeployment doesn't look nice. -- 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

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBEE-148) Unbounded ELEvaluator cache can cause OOMEs

by Aaron Ogburn (JIRA)

[ https://issues.jboss.org/browse/JBEE-148?page=com.atlassian.jira.plugin.s... ] Aaron Ogburn updated JBEE-148: ------------------------------ Attachment: diff.out Attached a diff reference of the related changes > Unbounded ELEvaluator cache can cause OOMEs > ------------------------------------------- > > Key: JBEE-148 > URL: https://issues.jboss.org/browse/JBEE-148 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Components: jboss-jstl-api > Affects Versions: jboss-jstl-api_1.2_spec-1.0.5.Final, jboss-jstl-api_1.2_spec-1.1.0.Final > Reporter: Aaron Ogburn > Assignee: Shelly McGowan > Attachments: diff.out > > > Unbounded jstl ELEvaluator cache can cause OOMEs. > Related community issue: > https://issues.apache.org/bugzilla/show_bug.cgi?id=31789 > This was fixed in 1.0 and 1.1 but never got added to 1.2 so we missed this here too. -- 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

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBEE-148) Unbounded ELEvaluator cache can cause OOMEs

by Aaron Ogburn (JIRA)

Aaron Ogburn created JBEE-148: --------------------------------- Summary: Unbounded ELEvaluator cache can cause OOMEs Key: JBEE-148 URL: https://issues.jboss.org/browse/JBEE-148 Project: JBoss JavaEE Spec APIs Issue Type: Bug Components: jboss-jstl-api Affects Versions: jboss-jstl-api_1.2_spec-1.1.0.Final, jboss-jstl-api_1.2_spec-1.0.5.Final Reporter: Aaron Ogburn Assignee: Shelly McGowan Unbounded jstl ELEvaluator cache can cause OOMEs. Related community issue: https://issues.apache.org/bugzilla/show_bug.cgi?id=31789 This was fixed in 1.0 and 1.1 but never got added to 1.2 so we missed this here too. -- 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

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3045) Expose JAXRS deployments via the management API

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3045?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-3045: --------------------------------- Assignee: Bill Burke (was: Stuart Douglas) > Expose JAXRS deployments via the management API > ----------------------------------------------- > > Key: WFLY-3045 > URL: https://issues.jboss.org/browse/WFLY-3045 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: REST > Affects Versions: 8.0.0.Final > Reporter: Emmanuel Hugonnet > Assignee: Bill Burke > > Currently WildFly expose webapps and ejbs deployments through the management API. I think we should also expose in a similar manner the other deployments such as REST resources -- 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

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3045) Expose JAXRS deployments via the management API

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3045?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-3045: ------------------------------ Component/s: Domain Management > Expose JAXRS deployments via the management API > ----------------------------------------------- > > Key: WFLY-3045 > URL: https://issues.jboss.org/browse/WFLY-3045 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management, REST > Affects Versions: 8.0.0.Final > Reporter: Emmanuel Hugonnet > Assignee: Bill Burke > > Currently WildFly expose webapps and ejbs deployments through the management API. I think we should also expose in a similar manner the other deployments such as REST resources -- 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

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3045) Expose JAXRS deployments via the management API

by Emmanuel Hugonnet (JIRA)

Emmanuel Hugonnet created WFLY-3045: --------------------------------------- Summary: Expose JAXRS deployments via the management API Key: WFLY-3045 URL: https://issues.jboss.org/browse/WFLY-3045 Project: WildFly Issue Type: Feature Request Security Level: Public (Everyone can see) Components: REST Affects Versions: 8.0.0.Final Reporter: Emmanuel Hugonnet Assignee: Stuart Douglas Currently WildFly expose webapps and ejbs deployments through the management API. I think we should also expose in a similar manner the other deployments such as REST resources -- 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

11 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2014