[JBoss JIRA] (JGRP-1785) TOA, inconsistent message delivery
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1785?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1785:
--------------------------------
Thanks, applied your PR. Ryan, can you confirm this fixes your problem and then resolve the issue ?
Cheers,
> TOA, inconsistent message delivery
> ----------------------------------
>
> Key: JGRP-1785
> URL: https://issues.jboss.org/browse/JGRP-1785
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.5
> Environment: Fedora release 17 (Beefy Miracle)
> Reporter: Ryan Emerson
> Assignee: Pedro Ruivo
> Fix For: 3.5
>
>
> When sending total order messages between two nodes, for a prolonged period of time, an inconsistency is encountered when comparing each node's total order of messages.
> I believe this issue is related to how sequence numbers are handled in the implementation, not the protocol itself. I appreciate that TOA is designed for environments where the subset of destinations in the network varies, however I have been unable to reproduce this error when the total number of nodes is > 2. It is still possible that this inconsistency may occur after a large amount of time when the number of nodes is > 2.
--
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, 10 months
[JBoss JIRA] (JGRP-1785) TOA, inconsistent message delivery
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/JGRP-1785?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo commented on JGRP-1785:
-----------------------------------
I don't know if I don't have permissions or something similar, but I'm not seeing the pull request link button...
pull request made: https://github.com/belaban/JGroups/pull/126
> TOA, inconsistent message delivery
> ----------------------------------
>
> Key: JGRP-1785
> URL: https://issues.jboss.org/browse/JGRP-1785
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.5
> Environment: Fedora release 17 (Beefy Miracle)
> Reporter: Ryan Emerson
> Assignee: Pedro Ruivo
> Fix For: 3.5
>
>
> When sending total order messages between two nodes, for a prolonged period of time, an inconsistency is encountered when comparing each node's total order of messages.
> I believe this issue is related to how sequence numbers are handled in the implementation, not the protocol itself. I appreciate that TOA is designed for environments where the subset of destinations in the network varies, however I have been unable to reproduce this error when the total number of nodes is > 2. It is still possible that this inconsistency may occur after a large amount of time when the number of nodes is > 2.
--
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, 10 months
[JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1802:
-------------------------------------------
Also, here you install a view by sending a VIEW_CHANGE event up the stack and down the stack, whereas in OverlappingMergeTest, you install a view my calling GMS.installView(newView).
Are these equivalent?
> 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, 3.5
>
>
> 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.
--
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, 10 months
[JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on JGRP-1802 at 3/3/14 10:03 AM:
--------------------------------------------------------------------
I also noticed that the test description you provided in the javadoc for testWithViewBC() is no longer carried out in the test.
In the javadoc description, you:
- send messages
- inject a new view and then
- send more messages
whereas in the actual test, you just inject a view and then send messages).
Any reason for the change? The first test seems more realistic.
was (Author: rachmato):
I also noticed that the test description you provided in the javadoc for testWithViewBC() is no longer carried out in the test.
In the javadoc description, you:
- send messages
- inject a new view and then
- send more messages
whereas in the actual test, you just inject a view and then send messages).
Any reason for the change? The first test seems more realistic.
> 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, 3.5
>
>
> 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.
--
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, 10 months
[JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1802:
-------------------------------------------
I also noticed that the test description you provided in the javadoc for testWithViewBC() is no longer carried out in the test.
In the javadoc description, you:
- send messages
- inject a new view and then
- send more messages
whereas in the actual test, you just inject a view and then send messages).
Any reason for the change? The first test seems more realistic.
> 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, 3.5
>
>
> 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.
--
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, 10 months
[JBoss JIRA] (JGRP-1803) S3_PING: incorrect format for presigned URLs
by Bela Ban (JIRA)
Bela Ban created JGRP-1803:
------------------------------
Summary: S3_PING: incorrect format for presigned URLs
Key: JGRP-1803
URL: https://issues.jboss.org/browse/JGRP-1803
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.5
AWS changed the format for presigned URLs, so S3_PING doesn't work anymore with presigned URLs.
All pre-signed URLs must include the bucket name in the hostname now. This updates the S3_PING code to both generate the new style URLs as well as be able to parse and use them.
--
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, 10 months