You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "subes (JIRA)" <ji...@apache.org> on 2011/02/13 19:13:57 UTC
[jira] Created: (HTTPCLIENT-1058) SO_TIMEOUT not set early enough
for SOCKS proxies in PlainSocketFactory
SO_TIMEOUT not set early enough for SOCKS proxies in PlainSocketFactory
-----------------------------------------------------------------------
Key: HTTPCLIENT-1058
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1058
Project: HttpComponents HttpClient
Issue Type: Bug
Components: HttpClient
Affects Versions: 4.1 Final
Reporter: subes
I've created my own delegating SchemeSocketFactory implementation which supports setting SOCKS proxies on socket creation. In the connectSocket implementation, I previously just delegated to PlainSocketFactory.
The problem there was, that the SO_TIMEOUT was not set on the socket before the connection was established through the SOCKS proxy. This lead to a stop on the native read0 method because the socket is endlessly waiting for a read to occur from the proxy, so it can continue with the the connect to the actual socket destination through the proxy. I made sure I set the SO_TIMEOUT parameter in HttpParams, but it did not get honored by PlainSocketFactory.
To fix this and make HttpClient honor SO_TIMEOUT for SOCKS proxies, the following line has to be added:
sock.setSoTimeout(HttpConnectionParams.getSoTimeout(params));
in PlainSocketFactory.connectSocket(...).
Heres the complete fixed method:
PlainSocketFactory:
public Socket connectSocket(
final Socket socket,
final InetSocketAddress remoteAddress,
final InetSocketAddress localAddress,
final HttpParams params) throws IOException, ConnectTimeoutException {
if (remoteAddress == null) {
throw new IllegalArgumentException("Remote address may not be null");
}
if (params == null) {
throw new IllegalArgumentException("HTTP parameters may not be null");
}
Socket sock = socket;
if (sock == null) {
sock = createSocket();
}
if (localAddress != null) {
sock.setReuseAddress(HttpConnectionParams.getSoReuseaddr(params));
sock.bind(localAddress);
}
//FIX for SOCKS proxies which get stalled if they don't answer
sock.setSoTimeout(HttpConnectionParams.getSoTimeout(params));
int timeout = HttpConnectionParams.getConnectionTimeout(params);
try {
sock.connect(remoteAddress, timeout);
} catch (SocketTimeoutException ex) {
throw new ConnectTimeoutException("Connect to " + remoteAddress.getHostName() + "/"
+ remoteAddress.getAddress() + " timed out");
}
return sock;
}
Currently I've implemented this in my delegating SchemeSocketFactory, because PlainSocketFactory misses this setting.
Dunno if there are other implementations of SocketFactory in HttpClient, which might need this fix. Anyway I hope this helps other people who get headaches about halting threads because they use SOCKS proxies. :)
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Resolved: (HTTPCLIENT-1058) SO_TIMEOUT not set early enough
for SOCKS proxies in PlainSocketFactory
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski resolved HTTPCLIENT-1058.
-------------------------------------------
Resolution: Fixed
Fix Version/s: 4.2 Final
SOCKS is a TCP level, not an HTTP level protocol. If configured correctly, it should be completely transparent to HttpClient. However, I am open to contributions of a better, more integrated support for SOCKS.
I committed the proposed fix to SVN trunk.
Oleg
> SO_TIMEOUT not set early enough for SOCKS proxies in PlainSocketFactory
> -----------------------------------------------------------------------
>
> Key: HTTPCLIENT-1058
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1058
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpConn
> Affects Versions: 4.1 Final
> Reporter: subes
> Priority: Minor
> Fix For: 4.2 Final
>
>
> I've created my own delegating SchemeSocketFactory implementation which supports setting SOCKS proxies on socket creation. In the connectSocket implementation, I previously just delegated to PlainSocketFactory.
> The problem there was, that the SO_TIMEOUT was not set on the socket before the connection was established through the SOCKS proxy. This lead to a stop on the native read0 method because the socket is endlessly waiting for a read to occur from the proxy, so it can continue with the the connect to the actual socket destination through the proxy. I made sure I set the SO_TIMEOUT parameter in HttpParams, but it did not get honored by PlainSocketFactory.
> To fix this and make HttpClient honor SO_TIMEOUT for SOCKS proxies, the following line has to be added:
> sock.setSoTimeout(HttpConnectionParams.getSoTimeout(params));
> in PlainSocketFactory.connectSocket(...).
> Heres the complete fixed method:
> PlainSocketFactory:
> public Socket connectSocket(
> final Socket socket,
> final InetSocketAddress remoteAddress,
> final InetSocketAddress localAddress,
> final HttpParams params) throws IOException, ConnectTimeoutException {
> if (remoteAddress == null) {
> throw new IllegalArgumentException("Remote address may not be null");
> }
> if (params == null) {
> throw new IllegalArgumentException("HTTP parameters may not be null");
> }
> Socket sock = socket;
> if (sock == null) {
> sock = createSocket();
> }
> if (localAddress != null) {
> sock.setReuseAddress(HttpConnectionParams.getSoReuseaddr(params));
> sock.bind(localAddress);
> }
>
> //FIX for SOCKS proxies which get stalled if they don't answer
> sock.setSoTimeout(HttpConnectionParams.getSoTimeout(params));
>
> int timeout = HttpConnectionParams.getConnectionTimeout(params);
> try {
> sock.connect(remoteAddress, timeout);
> } catch (SocketTimeoutException ex) {
> throw new ConnectTimeoutException("Connect to " + remoteAddress.getHostName() + "/"
> + remoteAddress.getAddress() + " timed out");
> }
> return sock;
> }
> Currently I've implemented this in my delegating SchemeSocketFactory, because PlainSocketFactory misses this setting.
> Dunno if there are other implementations of SocketFactory in HttpClient, which might need this fix. Anyway I hope this helps other people who get headaches about halting threads because they use SOCKS proxies. :)
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-1058) SO_TIMEOUT not set early enough
for SOCKS proxies in PlainSocketFactory
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12994474#comment-12994474 ]
Oleg Kalnichevski commented on HTTPCLIENT-1058:
-----------------------------------------------
What is the problem with setting SO_TIMEOUT on the socket instance in the #createSocket(HttpParams) method?
Oleg
> SO_TIMEOUT not set early enough for SOCKS proxies in PlainSocketFactory
> -----------------------------------------------------------------------
>
> Key: HTTPCLIENT-1058
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1058
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.1 Final
> Reporter: subes
>
> I've created my own delegating SchemeSocketFactory implementation which supports setting SOCKS proxies on socket creation. In the connectSocket implementation, I previously just delegated to PlainSocketFactory.
> The problem there was, that the SO_TIMEOUT was not set on the socket before the connection was established through the SOCKS proxy. This lead to a stop on the native read0 method because the socket is endlessly waiting for a read to occur from the proxy, so it can continue with the the connect to the actual socket destination through the proxy. I made sure I set the SO_TIMEOUT parameter in HttpParams, but it did not get honored by PlainSocketFactory.
> To fix this and make HttpClient honor SO_TIMEOUT for SOCKS proxies, the following line has to be added:
> sock.setSoTimeout(HttpConnectionParams.getSoTimeout(params));
> in PlainSocketFactory.connectSocket(...).
> Heres the complete fixed method:
> PlainSocketFactory:
> public Socket connectSocket(
> final Socket socket,
> final InetSocketAddress remoteAddress,
> final InetSocketAddress localAddress,
> final HttpParams params) throws IOException, ConnectTimeoutException {
> if (remoteAddress == null) {
> throw new IllegalArgumentException("Remote address may not be null");
> }
> if (params == null) {
> throw new IllegalArgumentException("HTTP parameters may not be null");
> }
> Socket sock = socket;
> if (sock == null) {
> sock = createSocket();
> }
> if (localAddress != null) {
> sock.setReuseAddress(HttpConnectionParams.getSoReuseaddr(params));
> sock.bind(localAddress);
> }
>
> //FIX for SOCKS proxies which get stalled if they don't answer
> sock.setSoTimeout(HttpConnectionParams.getSoTimeout(params));
>
> int timeout = HttpConnectionParams.getConnectionTimeout(params);
> try {
> sock.connect(remoteAddress, timeout);
> } catch (SocketTimeoutException ex) {
> throw new ConnectTimeoutException("Connect to " + remoteAddress.getHostName() + "/"
> + remoteAddress.getAddress() + " timed out");
> }
> return sock;
> }
> Currently I've implemented this in my delegating SchemeSocketFactory, because PlainSocketFactory misses this setting.
> Dunno if there are other implementations of SocketFactory in HttpClient, which might need this fix. Anyway I hope this helps other people who get headaches about halting threads because they use SOCKS proxies. :)
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Updated: (HTTPCLIENT-1058) SO_TIMEOUT not set early enough
for SOCKS proxies in PlainSocketFactory
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski updated HTTPCLIENT-1058:
------------------------------------------
Component/s: (was: HttpClient)
HttpConn
Priority: Minor (was: Major)
> SO_TIMEOUT not set early enough for SOCKS proxies in PlainSocketFactory
> -----------------------------------------------------------------------
>
> Key: HTTPCLIENT-1058
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1058
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpConn
> Affects Versions: 4.1 Final
> Reporter: subes
> Priority: Minor
>
> I've created my own delegating SchemeSocketFactory implementation which supports setting SOCKS proxies on socket creation. In the connectSocket implementation, I previously just delegated to PlainSocketFactory.
> The problem there was, that the SO_TIMEOUT was not set on the socket before the connection was established through the SOCKS proxy. This lead to a stop on the native read0 method because the socket is endlessly waiting for a read to occur from the proxy, so it can continue with the the connect to the actual socket destination through the proxy. I made sure I set the SO_TIMEOUT parameter in HttpParams, but it did not get honored by PlainSocketFactory.
> To fix this and make HttpClient honor SO_TIMEOUT for SOCKS proxies, the following line has to be added:
> sock.setSoTimeout(HttpConnectionParams.getSoTimeout(params));
> in PlainSocketFactory.connectSocket(...).
> Heres the complete fixed method:
> PlainSocketFactory:
> public Socket connectSocket(
> final Socket socket,
> final InetSocketAddress remoteAddress,
> final InetSocketAddress localAddress,
> final HttpParams params) throws IOException, ConnectTimeoutException {
> if (remoteAddress == null) {
> throw new IllegalArgumentException("Remote address may not be null");
> }
> if (params == null) {
> throw new IllegalArgumentException("HTTP parameters may not be null");
> }
> Socket sock = socket;
> if (sock == null) {
> sock = createSocket();
> }
> if (localAddress != null) {
> sock.setReuseAddress(HttpConnectionParams.getSoReuseaddr(params));
> sock.bind(localAddress);
> }
>
> //FIX for SOCKS proxies which get stalled if they don't answer
> sock.setSoTimeout(HttpConnectionParams.getSoTimeout(params));
>
> int timeout = HttpConnectionParams.getConnectionTimeout(params);
> try {
> sock.connect(remoteAddress, timeout);
> } catch (SocketTimeoutException ex) {
> throw new ConnectTimeoutException("Connect to " + remoteAddress.getHostName() + "/"
> + remoteAddress.getAddress() + " timed out");
> }
> return sock;
> }
> Currently I've implemented this in my delegating SchemeSocketFactory, because PlainSocketFactory misses this setting.
> Dunno if there are other implementations of SocketFactory in HttpClient, which might need this fix. Anyway I hope this helps other people who get headaches about halting threads because they use SOCKS proxies. :)
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-1058) SO_TIMEOUT not set early enough
for SOCKS proxies in PlainSocketFactory
Posted by "subes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12994559#comment-12994559 ]
subes commented on HTTPCLIENT-1058:
-----------------------------------
None, besides that it is not done there :P. The current implementation of PlainSocketFactory does not set SO_TIMEOUT before connecting the socket or after creating the socket. SO_TIMEOUT needs to be set because when a SOCKS Proxy is specified, the connect method does reads which may not timeout even if a user set SO_TIMEOUT in HttpParams. It was not obvious for me that I should set SO_TIMEOUT myself before delegating to PlainSocketFactory.connect() because I thought it would take care about HttpParams for me. Thats why it caused me some headache to track down this problem.
> SO_TIMEOUT not set early enough for SOCKS proxies in PlainSocketFactory
> -----------------------------------------------------------------------
>
> Key: HTTPCLIENT-1058
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1058
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.1 Final
> Reporter: subes
>
> I've created my own delegating SchemeSocketFactory implementation which supports setting SOCKS proxies on socket creation. In the connectSocket implementation, I previously just delegated to PlainSocketFactory.
> The problem there was, that the SO_TIMEOUT was not set on the socket before the connection was established through the SOCKS proxy. This lead to a stop on the native read0 method because the socket is endlessly waiting for a read to occur from the proxy, so it can continue with the the connect to the actual socket destination through the proxy. I made sure I set the SO_TIMEOUT parameter in HttpParams, but it did not get honored by PlainSocketFactory.
> To fix this and make HttpClient honor SO_TIMEOUT for SOCKS proxies, the following line has to be added:
> sock.setSoTimeout(HttpConnectionParams.getSoTimeout(params));
> in PlainSocketFactory.connectSocket(...).
> Heres the complete fixed method:
> PlainSocketFactory:
> public Socket connectSocket(
> final Socket socket,
> final InetSocketAddress remoteAddress,
> final InetSocketAddress localAddress,
> final HttpParams params) throws IOException, ConnectTimeoutException {
> if (remoteAddress == null) {
> throw new IllegalArgumentException("Remote address may not be null");
> }
> if (params == null) {
> throw new IllegalArgumentException("HTTP parameters may not be null");
> }
> Socket sock = socket;
> if (sock == null) {
> sock = createSocket();
> }
> if (localAddress != null) {
> sock.setReuseAddress(HttpConnectionParams.getSoReuseaddr(params));
> sock.bind(localAddress);
> }
>
> //FIX for SOCKS proxies which get stalled if they don't answer
> sock.setSoTimeout(HttpConnectionParams.getSoTimeout(params));
>
> int timeout = HttpConnectionParams.getConnectionTimeout(params);
> try {
> sock.connect(remoteAddress, timeout);
> } catch (SocketTimeoutException ex) {
> throw new ConnectTimeoutException("Connect to " + remoteAddress.getHostName() + "/"
> + remoteAddress.getAddress() + " timed out");
> }
> return sock;
> }
> Currently I've implemented this in my delegating SchemeSocketFactory, because PlainSocketFactory misses this setting.
> Dunno if there are other implementations of SocketFactory in HttpClient, which might need this fix. Anyway I hope this helps other people who get headaches about halting threads because they use SOCKS proxies. :)
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-1058) SO_TIMEOUT not set early enough
for SOCKS proxies in PlainSocketFactory
Posted by "subes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12994856#comment-12994856 ]
subes commented on HTTPCLIENT-1058:
-----------------------------------
Thanks, now I'll just have to wait for the first 4.2 release so I can remove my workaround. :)
> SO_TIMEOUT not set early enough for SOCKS proxies in PlainSocketFactory
> -----------------------------------------------------------------------
>
> Key: HTTPCLIENT-1058
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1058
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpConn
> Affects Versions: 4.1 Final
> Reporter: subes
> Priority: Minor
> Fix For: 4.2 Final
>
>
> I've created my own delegating SchemeSocketFactory implementation which supports setting SOCKS proxies on socket creation. In the connectSocket implementation, I previously just delegated to PlainSocketFactory.
> The problem there was, that the SO_TIMEOUT was not set on the socket before the connection was established through the SOCKS proxy. This lead to a stop on the native read0 method because the socket is endlessly waiting for a read to occur from the proxy, so it can continue with the the connect to the actual socket destination through the proxy. I made sure I set the SO_TIMEOUT parameter in HttpParams, but it did not get honored by PlainSocketFactory.
> To fix this and make HttpClient honor SO_TIMEOUT for SOCKS proxies, the following line has to be added:
> sock.setSoTimeout(HttpConnectionParams.getSoTimeout(params));
> in PlainSocketFactory.connectSocket(...).
> Heres the complete fixed method:
> PlainSocketFactory:
> public Socket connectSocket(
> final Socket socket,
> final InetSocketAddress remoteAddress,
> final InetSocketAddress localAddress,
> final HttpParams params) throws IOException, ConnectTimeoutException {
> if (remoteAddress == null) {
> throw new IllegalArgumentException("Remote address may not be null");
> }
> if (params == null) {
> throw new IllegalArgumentException("HTTP parameters may not be null");
> }
> Socket sock = socket;
> if (sock == null) {
> sock = createSocket();
> }
> if (localAddress != null) {
> sock.setReuseAddress(HttpConnectionParams.getSoReuseaddr(params));
> sock.bind(localAddress);
> }
>
> //FIX for SOCKS proxies which get stalled if they don't answer
> sock.setSoTimeout(HttpConnectionParams.getSoTimeout(params));
>
> int timeout = HttpConnectionParams.getConnectionTimeout(params);
> try {
> sock.connect(remoteAddress, timeout);
> } catch (SocketTimeoutException ex) {
> throw new ConnectTimeoutException("Connect to " + remoteAddress.getHostName() + "/"
> + remoteAddress.getAddress() + " timed out");
> }
> return sock;
> }
> Currently I've implemented this in my delegating SchemeSocketFactory, because PlainSocketFactory misses this setting.
> Dunno if there are other implementations of SocketFactory in HttpClient, which might need this fix. Anyway I hope this helps other people who get headaches about halting threads because they use SOCKS proxies. :)
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-1058) SO_TIMEOUT not set early enough
for SOCKS proxies in PlainSocketFactory
Posted by "subes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12994566#comment-12994566 ]
subes commented on HTTPCLIENT-1058:
-----------------------------------
Also, why not support socks proxies directly in httpclient? It would be simply a check for Proxy.Type to determine whether to use the current implementation as HTTP proxy or to create the socket with the proxy as a parameter to new Socket(Proxy). Though the current design uses a HttpHost as the proxy config as i remember. To follow this you could introduce SocksHost to let users configure a SOCKS proxy. :)
> SO_TIMEOUT not set early enough for SOCKS proxies in PlainSocketFactory
> -----------------------------------------------------------------------
>
> Key: HTTPCLIENT-1058
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1058
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.1 Final
> Reporter: subes
>
> I've created my own delegating SchemeSocketFactory implementation which supports setting SOCKS proxies on socket creation. In the connectSocket implementation, I previously just delegated to PlainSocketFactory.
> The problem there was, that the SO_TIMEOUT was not set on the socket before the connection was established through the SOCKS proxy. This lead to a stop on the native read0 method because the socket is endlessly waiting for a read to occur from the proxy, so it can continue with the the connect to the actual socket destination through the proxy. I made sure I set the SO_TIMEOUT parameter in HttpParams, but it did not get honored by PlainSocketFactory.
> To fix this and make HttpClient honor SO_TIMEOUT for SOCKS proxies, the following line has to be added:
> sock.setSoTimeout(HttpConnectionParams.getSoTimeout(params));
> in PlainSocketFactory.connectSocket(...).
> Heres the complete fixed method:
> PlainSocketFactory:
> public Socket connectSocket(
> final Socket socket,
> final InetSocketAddress remoteAddress,
> final InetSocketAddress localAddress,
> final HttpParams params) throws IOException, ConnectTimeoutException {
> if (remoteAddress == null) {
> throw new IllegalArgumentException("Remote address may not be null");
> }
> if (params == null) {
> throw new IllegalArgumentException("HTTP parameters may not be null");
> }
> Socket sock = socket;
> if (sock == null) {
> sock = createSocket();
> }
> if (localAddress != null) {
> sock.setReuseAddress(HttpConnectionParams.getSoReuseaddr(params));
> sock.bind(localAddress);
> }
>
> //FIX for SOCKS proxies which get stalled if they don't answer
> sock.setSoTimeout(HttpConnectionParams.getSoTimeout(params));
>
> int timeout = HttpConnectionParams.getConnectionTimeout(params);
> try {
> sock.connect(remoteAddress, timeout);
> } catch (SocketTimeoutException ex) {
> throw new ConnectTimeoutException("Connect to " + remoteAddress.getHostName() + "/"
> + remoteAddress.getAddress() + " timed out");
> }
> return sock;
> }
> Currently I've implemented this in my delegating SchemeSocketFactory, because PlainSocketFactory misses this setting.
> Dunno if there are other implementations of SocketFactory in HttpClient, which might need this fix. Anyway I hope this helps other people who get headaches about halting threads because they use SOCKS proxies. :)
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org