[TYRUS-397] Client try to connect directly to the server when a proxy (which is down) is configured Created: 24/Apr/15  Updated: 24/Apr/15  Resolved: 24/Apr/15

Status: Resolved
Project: tyrus
Component/s: client
Affects Version/s: 1.9
Fix Version/s: 1.11

Type: Bug Priority: Major
Reporter: david.regnier Assignee: Pavel Bucek
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour

Issue Links:
Duplicate
duplicates TYRUS-394 Proxy bypassed on Linux but not on Wi... Resolved
Tags: proxy

 Description   

Context: use the JdkClientContainer

How to reproduce:

client <> proxy down <> server
(with client which can reach server directly).

Result: the client communicates directly with the server.

If we have configured the client with a proxy, we do not want the client to communicate with the server even if the proxy is down/unreachable.

Related code: JdkClientContainer#processProxy():

addProxies(proxySelector, uri, "socket", proxies);
addProxies(proxySelector, uri, "https", proxies);
addProxies(proxySelector, uri, "http", proxies);
proxies.add(Proxy.NO_PROXY);

(line 387)

Proxy.NO_PROXY is always added whatever the proxy configuration is.

Possible fix:

if(proxies.isEmpty())

{ proxies.add(Proxy.NO_PROXY); }

 Comments   
Comment by Pavel Bucek [ 24/Apr/15 ]

isn't this already fixed by https://github.com/tyrus-project/tyrus/commit/963c5159e4f884b43918cb2a323a4865074788c0 ? (which is in 1.10)

Comment by david.regnier [ 24/Apr/15 ]

OK cool thank you -> i will use 1.10 (invalid issue -> sorry)

Comment by Pavel Bucek [ 24/Apr/15 ]

no problem





[TYRUS-394] Proxy bypassed on Linux but not on Windows Created: 23/Jan/15  Updated: 24/Apr/15  Resolved: 29/Jan/15

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: None
Fix Version/s: 1.10

Type: Bug Priority: Major
Reporter: anbb Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by TYRUS-397 Client try to connect directly to the... Resolved
Tags: proxy

 Description   

Same implementation of a websocket client that uses an invalid proxy behaves differently on different operating systems.

On Linux operating systems it connects directly after 30 seconds but on Windows operating system it throws a "java.net.ConnectException: Connection timed out: no further information ".

Stack trace from Windows platform :

java.net.ConnectException: Connection timed out: no further information
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at sun.nio.ch.SocketChannelImpl.finishConnect(Unknown Source)
at org.glassfish.grizzly.nio.transport.TCPNIOConnectorHandler.onConnectedAsync(TCPNIOConnectorHandler.java:206)
at org.glassfish.grizzly.nio.transport.TCPNIOConnectorHandler$1.connected(TCPNIOConnectorHandler.java:154)
at org.glassfish.grizzly.nio.transport.TCPNIOConnection.onConnect(TCPNIOConnection.java:258)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:552)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.executeIoEvent(WorkerThreadIOStrategy.java:103)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.executeIoEvent(AbstractIOStrategy.java:89)
at org.glassfish.grizzly.nio.SelectorRunner.iterateKeyEvents(SelectorRunner.java:414)
at org.glassfish.grizzly.nio.SelectorRunner.iterateKeys(SelectorRunner.java:383)
at org.glassfish.grizzly.nio.SelectorRunner.doSelect(SelectorRunner.java:347)
at org.glassfish.grizzly.nio.SelectorRunner.run(SelectorRunner.java:278)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Unknown Source)



 Comments   
Comment by Pavel Bucek [ 27/Jan/15 ]

the change fixing this issue has been committed and snapshot published to maven.java.net repo - can you please verify the current behaviour?

Thanks!

Comment by Pavel Bucek [ 29/Jan/15 ]

fixed in master branch (963c5159e4f884b43918cb2a323a4865074788c0)





Generated at Sat Apr 25 07:03:05 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.