Hi Andrei,
the implemented behavior is side-effect of
http://tools.ietf.org/html/rfc6455#section-4.1 (see chapter 4.1.3). In
short, the RFC defines the ordering of proxies we should use (when
available).
My previous conclusion was little bit hasty, even thought I really
thought it works as I described. The problem you see is that for some
reason, windows are throwing ConnectException, which is IOException and
that is being rethrown, thus ending "connect" process. For some reason,
we handle TimeoutException differently - we just close the transport and
try next proxy.
Anyway, given that I know about some other differences in thrown
exceptions from networking stack on different platforms, I'm open to
change this, and hopefully unify the behavior by that change.
I belive that the change should be as simple as:
- remove special handling for TimeoutException
- when proxy is set, don't add "Proxy.NO_PROXY" fallback.
Can you please file an issue?
Thanks,
Pavel
On 23/01/15 15:02, Andrei Nicolau wrote:
> Hi Pavel,
>
> I am curious about the reasons behind this implementation. It seems
> strange to use direct connection as a fallback when setting a proxy.
>
> Here is the stack trace :
>
> 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)
>
> Regards,
> Andrei
>
> On 1/23/2015 11:32 AM, Pavel Bucek wrote:
>>
>> Hi Andrei,
>>
>> both our transports (grizzly and jdk 7) do try to connect to proxy
>> (when set), but if the connection fails, it will continue trying with
>> other proxies. Ultimately it will hit the fallback, which is "direct
>> connection"; meaning that if you set "fake" proxy, it will fail, but
>> Tyrus will still try to connect to the host.
>>
>> I guess we could introduce configurable option, which would try just
>> the first valid proxy and fail if we cannot connect to the proxy. Feel
>> free to file an enhancement request at
>> https://java.net/jira/browse/TYRUS.
>>
>> Interesting statement (for me) is that on windows, connection fails
>> :-) Can you please share the stack trace?
>>
>> Regards,
>> Pavel
>>
>> On 23/01/15 10:15, Andrei Nicolau wrote:
>>> Hello,
>>>
>>> I am trying to create a websocket client to connect to a server through
>>> a proxy.
>>> Everything works fine if the proxy is a valid one but whenever I use a
>>> fake proxy ( random ip / port ), instead of failing it still connects to
>>> the server.
>>>
>>> Did anyone encounter this issue and maybe knows a fix ?
>>>
>>> p.s. I've tested this on two linux machines and on a windows machine. On
>>> the windows machine it behaves as it should.
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> http://www.avast.com
>