That sounds great Pavel.
I filed the issue under
https://java.net/jira/browse/TYRUS-394 . If
there is anything I didn't mention in it, please let me know and I'll
update it.
Regarding the RFC you mentioned I still can't figure out why any
explicit usage of a proxy would result in a direct connection.
As I see it, if I set a proxy for a connection, I do it because I
need/expect my connection to to through that proxy ip/server, not
because I just feel like using a proxy.
Thanks a lot for your willingness to fix this issue and for your prompt
answers.
Best of wishes,
Andrei
On 01/23/2015 04:41 PM, Pavel Bucek wrote:
>
> 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
>>