[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
11 years, 7 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: 3.5
> 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
11 years, 7 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:
-------------------------------------------
In the test setup, it would also be safer to use Util.waitUntilAllChannelHaveSameSize() rather than an immediate check on view formation.
> 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.
--
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, 7 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:
-------------------------------------------
Looking over the code in checkReceivedMessages, it seems there is a mixup in which receivers are used to check message arrival.
In the setup for the test, you define three receivers ra, rb, rc. But in checkReceivedMessages(), you send the messages and then create three receivers which are used to check message receipt:
{noformat}
private void sendAndCheckMessages(int num_msgs, JChannel ... channels) throws Exception {
ra.clear(); rb.clear(); rc.clear();
// 1. send unicast messages
Set<Address> mbrs=new HashSet<Address>(channels.length);
for(JChannel ch: channels)
mbrs.add(ch.getAddress());
for(JChannel ch: channels) {
Address addr=ch.getAddress();
for(Address dest: mbrs) {
for(int i=1; i <= num_msgs; i++) {
ch.send(dest, "unicast msg #" + i + " from " + addr);
}
}
}
int total_msgs=num_msgs * channels.length;
MyReceiver[] receivers=new MyReceiver[channels.length];
for(int i=0; i < channels.length; i++)
receivers[i]=(MyReceiver)channels[i].getReceiver();
checkReceivedMessages(total_msgs, receivers);
}
{noformat}
Isn't it possible that messages will be received by channels before these receivers are installed?
Would this not be safer?
{noformat}
private void sendAndCheckMessages(int num_msgs, JChannel ... channels) throws Exception {
ra.clear(); rb.clear(); rc.clear();
// send unicast messages
Set<Address> mbrs=new HashSet<Address>(channels.length);
for(JChannel ch: channels)
mbrs.add(ch.getAddress());
for(JChannel ch: channels) {
Address addr=ch.getAddress();
for(Address dest: mbrs) {
for(int i=1; i <= num_msgs; i++) {
ch.send(dest, "unicast msg #" + i + " from " + addr);
}
}
}
// check unicast message arrival
int total_msgs=num_msgs * channels.length;
checkReceivedMessages(total_msgs, ra,rb,rc);
}
{noformat}
> 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.
--
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, 7 months