[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected
by Preeta Kuruvilla (JIRA)
[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ]
Preeta Kuruvilla edited comment on WFLY-6781 at 6/30/16 12:05 PM:
------------------------------------------------------------------
Attached are the logs before and after incorporating the failover testing scenario for both RC and SL.
BeforeFailover logs : Are when Node1 and Node2 are running and working correctly and JMS messages is processed.
AfterFailover logs: Are when Node2 is powered off and Node1 is running but JMS messages on Node1 is not getting processed by SL on Node1.
Note : The workaround we have found is to restart both Node1 and Node2. Just powering on Node2 is not enough to make it work as expected.
[^attachment-name.zip]
was (Author: kpreeta12):
Attached are the logs before and after testing failover for both RC and SL.
BeforeFailover logs : Are when Node1 and Node2 are running and working correctly and JMS messages is processed.
AfterFailover logs: Are when Node2 is powered off and Node1 is running but JMS messages on Node1 is not getting processed by SL on Node1.
Note : The workaround we have found is to restart both Node1 and Node2. Just powering on Node2 is not enough to make it work as expected.
[^attachment-name.zip]
> Wildfly cluster's failover functionality doesn't work as expected
> -----------------------------------------------------------------
>
> Key: WFLY-6781
> URL: https://issues.jboss.org/browse/WFLY-6781
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: domain.Node1.xml, host.Node1.xml, host.Node2.xml, server.RC.Node1.AfterFailover.log, server.RC.Node1.BeforeFailover.log, server.RC.Node2.AfterFailover.log, server.RC.Node2.BeforeFailover.log, server.SL.Node1.AfterFailover.log, server.SL.Node1.BeforeFailover.log
>
>
> Following are the testing scenarios we did and the outcome:-
> 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment.
> 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment.
> 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment
> 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment.
> Jgroups subsystem configuration in domain.xml we have is below:-
> <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp">
> <stack name="udp">
> <transport type="UDP" socket-binding="jgroups-udp"/>
> <protocol type="PING"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
> <protocol type="FD_ALL"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="MPING" socket-binding="jgroups-mping"/>
> <protocol type="MERGE2"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6793) Batch subsystem cannot be removed with a remove operation
by James Perkins (JIRA)
James Perkins created WFLY-6793:
-----------------------------------
Summary: Batch subsystem cannot be removed with a remove operation
Key: WFLY-6793
URL: https://issues.jboss.org/browse/WFLY-6793
Project: WildFly
Issue Type: Bug
Components: Batch
Reporter: James Perkins
Assignee: James Perkins
The {{batch-jberet}} subsystem fails when a {{remove}} operation is invoked.
{code}
[standalone@localhost:9990 /] /subsystem=batch-jberet:remove
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
Service org.wildfly.batch.thread.pool.batch was depended upon by service org.wildfly.batch.configuration",
"rolled-back" => true,
"response-headers" => undefined
}
{code}
The batch configuration dependency needs to be removed before the its dependencies are removed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-351) CLI "revert to snapshot" command
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-351?page=com.atlassian.jira.plugin... ]
Kabir Khan commented on WFCORE-351:
-----------------------------------
It seems to be the original file.
In core, I copied standalone.xml to standalone2.xml.
I then start using standalone.xml, and execute these commands:
{code}
/system-property=test:add(value=a)
{code}
standalone.xml gets updated as expected
{code}
reload --server-config=standalone2.xml
{code}
This now overwrites standalone.xml so there is no property 'test' there (nor in standalone2.xml)
{code}
/system-property=test:add(value=b)
{code}
standalone.xml contains the 'test' property, but standalone2.xml does not.
> CLI "revert to snapshot" command
> --------------------------------
>
> Key: WFCORE-351
> URL: https://issues.jboss.org/browse/WFCORE-351
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Environment: all
> Reporter: Rich Sharples
> Assignee: Kabir Khan
> Labels: eap6-ux
> Fix For: 3.0.0.Alpha1
>
>
> The CLI has commands for taking snapshots, listing snapshots, deleting snapshots but no way to rollback or revert to a previous snapshot.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected
by Preeta Kuruvilla (JIRA)
[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ]
Preeta Kuruvilla updated WFLY-6781:
-----------------------------------
Attachment: host.Node2.xml
host.Node1.xml
domain.Node1.xml
Also attached are the domain.xml and host.xml
> Wildfly cluster's failover functionality doesn't work as expected
> -----------------------------------------------------------------
>
> Key: WFLY-6781
> URL: https://issues.jboss.org/browse/WFLY-6781
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: domain.Node1.xml, host.Node1.xml, host.Node2.xml, server.RC.Node1.AfterFailover.log, server.RC.Node1.BeforeFailover.log, server.RC.Node2.AfterFailover.log, server.RC.Node2.BeforeFailover.log, server.SL.Node1.AfterFailover.log, server.SL.Node1.BeforeFailover.log
>
>
> Following are the testing scenarios we did and the outcome:-
> 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment.
> 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment.
> 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment
> 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment.
> Jgroups subsystem configuration in domain.xml we have is below:-
> <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp">
> <stack name="udp">
> <transport type="UDP" socket-binding="jgroups-udp"/>
> <protocol type="PING"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
> <protocol type="FD_ALL"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="MPING" socket-binding="jgroups-mping"/>
> <protocol type="MERGE2"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected
by Preeta Kuruvilla (JIRA)
[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ]
Preeta Kuruvilla commented on WFLY-6781:
----------------------------------------
Attached are the logs before and after testing failover for both RC and SL.
BeforeFailover logs : Are when Node1 and Node2 are running and working correctly and JMS messages is processed.
AfterFailover logs: Are when Node2 is powered off and Node1 is running but JMS messages on Node1 is not getting processed by SL on Node1.
Note : The workaround we have found is to restart both Node1 and Node2. Just powering on Node2 is not enough to make it work as expected.
[^attachment-name.zip]
> Wildfly cluster's failover functionality doesn't work as expected
> -----------------------------------------------------------------
>
> Key: WFLY-6781
> URL: https://issues.jboss.org/browse/WFLY-6781
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: server.RC.Node1.AfterFailover.log, server.RC.Node1.BeforeFailover.log, server.RC.Node2.AfterFailover.log, server.RC.Node2.BeforeFailover.log, server.SL.Node1.AfterFailover.log, server.SL.Node1.BeforeFailover.log
>
>
> Following are the testing scenarios we did and the outcome:-
> 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment.
> 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment.
> 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment
> 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment.
> Jgroups subsystem configuration in domain.xml we have is below:-
> <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp">
> <stack name="udp">
> <transport type="UDP" socket-binding="jgroups-udp"/>
> <protocol type="PING"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
> <protocol type="FD_ALL"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="MPING" socket-binding="jgroups-mping"/>
> <protocol type="MERGE2"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected
by Preeta Kuruvilla (JIRA)
[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ]
Preeta Kuruvilla updated WFLY-6781:
-----------------------------------
Attachment: server.SL.Node1.BeforeFailover.log
server.SL.Node1.AfterFailover.log
server.RC.Node2.BeforeFailover.log
server.RC.Node2.AfterFailover.log
server.RC.Node1.BeforeFailover.log
server.RC.Node1.AfterFailover.log
> Wildfly cluster's failover functionality doesn't work as expected
> -----------------------------------------------------------------
>
> Key: WFLY-6781
> URL: https://issues.jboss.org/browse/WFLY-6781
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: server.RC.Node1.AfterFailover.log, server.RC.Node1.BeforeFailover.log, server.RC.Node2.AfterFailover.log, server.RC.Node2.BeforeFailover.log, server.SL.Node1.AfterFailover.log, server.SL.Node1.BeforeFailover.log
>
>
> Following are the testing scenarios we did and the outcome:-
> 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment.
> 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment.
> 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment
> 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment.
> Jgroups subsystem configuration in domain.xml we have is below:-
> <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp">
> <stack name="udp">
> <transport type="UDP" socket-binding="jgroups-udp"/>
> <protocol type="PING"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
> <protocol type="FD_ALL"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="MPING" socket-binding="jgroups-mping"/>
> <protocol type="MERGE2"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1628) Create module using 'module add' CLI command with absolute-path in resource-root element
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1628?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1628:
------------------------------------------
You can also have two params --resources and --absolute-resources (or some name like that) with the latter being used for absolute paths. That allows a mix and is less typing for the case where all resources are absolute.
> Create module using 'module add' CLI command with absolute-path in resource-root element
> ----------------------------------------------------------------------------------------
>
> Key: WFCORE-1628
> URL: https://issues.jboss.org/browse/WFCORE-1628
> Project: WildFly Core
> Issue Type: Enhancement
> Components: CLI
> Reporter: Martin Simka
> Assignee: Alexey Loubyansky
>
> MODULES-218, included in WildFly 10/WildFly Core 2.0.10, allows absolute paths to be used for resource-roots in module.xml. But there is no way to create module with absolute paths in resource-roots using CLI command {{module add}}.
> {quote}
> resource-root's path previously only allowed resources within the module's directory, e.g.:
> <resource-root path="wildfly-controller-2.2.0.CR2.jar"/>
> With MODULES-218 it allows resources to exist anywhere on the filesystem, in the form of an absolute path, e.g.:
> <resource-root path="/Users/whoever/mymodules/wildfly-controller-2.2.0.CR2.jar"/>
> {quote}
> {{module add}} command could have optional argument {{--copy-resources=(true|false)}} with default {{true}}, which would specify how new module will look like.
> * {{true}} copy files to the created module's directory = no change from how it works now.
> * {{false}} don't copy files and use absolute paths in {{resource-root}} instead.
> Another option could be to add optional argument without value, which would only specify to not copy files to the created module's directory and use absolute paths in {{resource-root}} instead. Name of this argument could be something like {{--use-absolute-paths-for-resources}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-351) CLI "revert to snapshot" command
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-351?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-351:
-----------------------------------------
[~kabirkhan] What about persistence? When you reload to a different file, and then make a config change, what file gets written?
> CLI "revert to snapshot" command
> --------------------------------
>
> Key: WFCORE-351
> URL: https://issues.jboss.org/browse/WFCORE-351
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Environment: all
> Reporter: Rich Sharples
> Assignee: Kabir Khan
> Labels: eap6-ux
> Fix For: 3.0.0.Alpha1
>
>
> The CLI has commands for taking snapshots, listing snapshots, deleting snapshots but no way to rollback or revert to a previous snapshot.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1628) Create module using 'module add' CLI command with absolute-path in resource-root element
by Martin Simka (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1628?page=com.atlassian.jira.plugi... ]
Martin Simka updated WFCORE-1628:
---------------------------------
Description:
MODULES-218, included in WildFly 10/WildFly Core 2.0.10, allows absolute paths to be used for resource-roots in module.xml. But there is no way to create module with absolute paths in resource-roots using CLI command {{module add}}.
{quote}
resource-root's path previously only allowed resources within the module's directory, e.g.:
<resource-root path="wildfly-controller-2.2.0.CR2.jar"/>
With MODULES-218 it allows resources to exist anywhere on the filesystem, in the form of an absolute path, e.g.:
<resource-root path="/Users/whoever/mymodules/wildfly-controller-2.2.0.CR2.jar"/>
{quote}
{{module add}} command could have optional argument {{--copy-resources=(true|false)}} with default {{true}}, which would specify how new module will look like.
* {{true}} copy files to the created module's directory = no change from how it works now.
* {{false}} don't copy files and use absolute paths in {{resource-root}} instead.
Another option could be to add optional argument without value, which would only specify to not copy files to the created module's directory and use absolute paths in {{resource-root}} instead. Name of this argument could be something like {{--use-absolute-paths-for-resources}}.
was:
MODULES-218, included in WildFly 10/WildFly Core 2.0.10, allows absolute paths to be used for resource-roots in module.xml. But there is no way to create module with absolute paths in resource-roots using CLI command {{module add}}.
{quote}
resource-root's path previously only allowed resources within the module's directory, e.g.:
<resource-root path="wildfly-controller-2.2.0.CR2.jar"/>
With MODULES-218 it allows resources to exist anywhere on the filesystem, in the form of an absolute path, e.g.:
<resource-root path="/Users/whoever/mymodules/wildfly-controller-2.2.0.CR2.jar"/>
{quote}
{{module add}} command could have optional argument {{--copy-resources=(true|false)}}, which would specify how new module will look like.
* {{true}} copy files to the created module's directory = no change from how it works now.
* {{false}} don't copy files and use absolute paths in {{resource-root}} instead.
Another option could be to add optional argument without value, which would only specify to not copy files to the created module's directory and use absolute paths in {{resource-root}} instead. Name of this argument could be something like {{--use-absolute-paths-for-resources}}.
> Create module using 'module add' CLI command with absolute-path in resource-root element
> ----------------------------------------------------------------------------------------
>
> Key: WFCORE-1628
> URL: https://issues.jboss.org/browse/WFCORE-1628
> Project: WildFly Core
> Issue Type: Enhancement
> Components: CLI
> Reporter: Martin Simka
> Assignee: Alexey Loubyansky
>
> MODULES-218, included in WildFly 10/WildFly Core 2.0.10, allows absolute paths to be used for resource-roots in module.xml. But there is no way to create module with absolute paths in resource-roots using CLI command {{module add}}.
> {quote}
> resource-root's path previously only allowed resources within the module's directory, e.g.:
> <resource-root path="wildfly-controller-2.2.0.CR2.jar"/>
> With MODULES-218 it allows resources to exist anywhere on the filesystem, in the form of an absolute path, e.g.:
> <resource-root path="/Users/whoever/mymodules/wildfly-controller-2.2.0.CR2.jar"/>
> {quote}
> {{module add}} command could have optional argument {{--copy-resources=(true|false)}} with default {{true}}, which would specify how new module will look like.
> * {{true}} copy files to the created module's directory = no change from how it works now.
> * {{false}} don't copy files and use absolute paths in {{resource-root}} instead.
> Another option could be to add optional argument without value, which would only specify to not copy files to the created module's directory and use absolute paths in {{resource-root}} instead. Name of this argument could be something like {{--use-absolute-paths-for-resources}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JGRP-1914) S3_PING doesn't work with S3 buckets created in Frankfurt region
by Mark Morris (JIRA)
[ https://issues.jboss.org/browse/JGRP-1914?page=com.atlassian.jira.plugin.... ]
Mark Morris commented on JGRP-1914:
-----------------------------------
Hi Ali,
Yes, I have code I need to check in and push that will allow access to ALL regions. Specifically, it implements Amazon's current authentication protocol. I still have some work on it for presigned urls, but otherwise, it works great! I'll clean it up, check it in and push to Bella this weekend.
-Mark
> S3_PING doesn't work with S3 buckets created in Frankfurt region
> -----------------------------------------------------------------
>
> Key: JGRP-1914
> URL: https://issues.jboss.org/browse/JGRP-1914
> Project: JGroups
> Issue Type: Bug
> Reporter: Gleb Leonov
> Assignee: Bela Ban
> Fix For: 4.1
>
> Attachments: AWS4.png
>
>
> I tried to use S3_PING with access and secret key pair. However, I got 400 (Bad Request) error. After some investigation, I found that modern S3 buckets created in Frankfurt needs amazon v4 authentication, which needs hmac-sha256. But now S3_PING supports only hmac-sha1, so I see no way to use S3_PING with buckets in Frankfurt region.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months