Hi Pavel,
We tested the 1.10-SNAPSHOT jar and the issues are fixed.
We see the same behavior both on Linux and Win . Also the proxy is not
bypassed anymore.
Thanks a lot for taking care of this .
Best regards,
Andrei
On 01/23/2015 06:51 PM, Andrei Nicolau wrote:
> 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
>>>
>