[JBoss JIRA] (WFLY-2198) Remote Naming throws the same exception for different causes
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2198?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2198:
-----------------------------------------------
Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1053426|https://bugzilla.redhat.com/show_bug.cgi?id=1053426] from MODIFIED to ON_QA
> Remote Naming throws the same exception for different causes
> ------------------------------------------------------------
>
> Key: WFLY-2198
> URL: https://issues.jboss.org/browse/WFLY-2198
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Naming
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
>
> A generic NamingException are thrown if all of the servers specified are unreachable as well as if the user/pass are invalid and a security exception is thrown up, they both are converted into a RuntimeException and a message listing the servers it was unable to call is reported.
> We should be throwing a different exception in the cases we know the cause, such as connection timeout or authentication exception.
> If all the the servers specified are not not running:
> --------------------------------------------------------------------------------------------
> javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447]
> at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213)
> If one of the servers is running, but the client's username/password are incorrect
> --------------------------------------------------------------------------------------------
> javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447]
> at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213)
--
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
10 years, 1 month
[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
10 years, 1 month
[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
10 years, 1 month
[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
10 years, 1 month
[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
10 years, 1 month
[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
10 years, 1 month
[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
10 years, 1 month