[JBoss JIRA] (WFLY-3040) Missing modules
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3040?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-3040:
-----------------------------------
What is your issue exactly?
And please before you file JIRA with such vague description, try to discuss problem on forums / mailing lists first.
> Missing modules
> ---------------
>
> Key: WFLY-3040
> URL: https://issues.jboss.org/browse/WFLY-3040
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: OSGi
> Affects Versions: 8.0.0.Final
> Environment: Windows 64 bits
> Reporter: David Cabillic
> Assignee: Thomas Diesler
>
> I listed modules with links to missing ones :
> || module || missing module ||
> | org.infinispan.client.hotrod | com.google.protobuf |
> | org.jboss.as.aggregate | org.jboss.as.managed-beans |
> | org.jboss.genericjms | org.jboss.genericjms.provider |
--
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, 2 months
[JBoss JIRA] (WFLY-3040) Missing modules
by David Cabillic (JIRA)
[ https://issues.jboss.org/browse/WFLY-3040?page=com.atlassian.jira.plugin.... ]
David Cabillic commented on WFLY-3040:
--------------------------------------
Sorry, perhaps OSGi is not the good component, it is a Wildfly's modules issue.
> Missing modules
> ---------------
>
> Key: WFLY-3040
> URL: https://issues.jboss.org/browse/WFLY-3040
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: OSGi
> Affects Versions: 8.0.0.Final
> Environment: Windows 64 bits
> Reporter: David Cabillic
> Assignee: Thomas Diesler
>
> I listed modules with links to missing ones :
> || module || missing module ||
> | org.infinispan.client.hotrod | com.google.protobuf |
> | org.jboss.as.aggregate | org.jboss.as.managed-beans |
> | org.jboss.genericjms | org.jboss.genericjms.provider |
--
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, 2 months
[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 closed JGRP-1800.
-------------------------------------
Resolution: Done
The issue no longer appears in the test results. I'll reopen if it starts to appear again.
> 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
12 years, 2 months
[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
12 years, 2 months
[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
12 years, 2 months
[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
12 years, 2 months
[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
12 years, 2 months
[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
12 years, 2 months