users@jersey.java.net

[Jersey] Re: Jesey non-blocking client - request retry

From: Igor Skornyakov <igor.skornyakov_at_gmail.com>
Date: Wed, 18 Jan 2012 17:09:16 +0400

Thank you Alexey,
I will try again. Please note however that the same error message appears
with JDK 1.7.0_02 as well.
Regards,
Igor.


On Wed, Jan 18, 2012 at 5:04 PM, Oleksiy Stashok <oleksiy.stashok_at_oracle.com
> wrote:

> Hi Igor,
>
> don't scare, it's probably related to JDK issue [1].
> We should probably change log level to FINE(R) to not scare people :)
>
> Otherwise this warning shouldn't impact functionality.
>
> WBR,
> Alexey.
>
> [1] http://bugs.sun.com/view_bug.do?bug_id=6799574
>
>
> On 01/18/2012 01:48 PM, Igor Skornyakov wrote:
>
> Thank you Pavel,
> I've already tried 1.12-SNAPSHOT, but I was scared by a lot of messages in
> the log like the following one
>
> 18.01.2012 16:45:58 org.glassfish.grizzly.nio.transport.TCPNIOTransport
> configureChannel
> WARNING: Can not set keepAlive to false
> java.net.SocketException: Invalid argument: sun.nio.ch.Net.setIntOption
> at sun.nio.ch.Net.setIntOption0(Native Method)
> at sun.nio.ch.Net.setIntOption(Net.java:157)
> at sun.nio.ch.SocketChannelImpl$1.setInt(SocketChannelImpl.java:399)
> at sun.nio.ch.SocketOptsImpl.setBoolean(SocketOptsImpl.java:38)
> at sun.nio.ch.SocketOptsImpl.keepAlive(SocketOptsImpl.java:92)
> at sun.nio.ch.SocketOptsImpl$IP$TCP.keepAlive(SocketOptsImpl.java:268)
> at sun.nio.ch.OptionAdaptor.setKeepAlive(OptionAdaptor.java:139)
> at sun.nio.ch.SocketAdaptor.setKeepAlive(SocketAdaptor.java:322)
> at
> org.glassfish.grizzly.nio.transport.TCPNIOTransport.configureChannel(TCPNIOTransport.java:640)
> at
> org.glassfish.grizzly.nio.transport.TCPNIOConnectorHandler.onConnectedAsync(TCPNIOConnectorHandler.java:195)
> at
> org.glassfish.grizzly.nio.transport.TCPNIOConnectorHandler$1.completed(TCPNIOConnectorHandler.java:140)
> at
> org.glassfish.grizzly.nio.transport.TCPNIOConnectorHandler$1.completed(TCPNIOConnectorHandler.java:136)
> at
> org.glassfish.grizzly.nio.transport.TCPNIOConnection.onConnect(TCPNIOConnection.java:200)
> at
> org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:805)
> at
> org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:111)
> at
> org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
> at
> org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.executeIoEvent(WorkerThreadIOStrategy.java:101)
> at
> org.glassfish.grizzly.strategies.AbstractIOStrategy.executeIoEvent(AbstractIOStrategy.java:87)
> at
> org.glassfish.grizzly.nio.SelectorRunner.iterateKeyEvents(SelectorRunner.java:401)
> at
> org.glassfish.grizzly.nio.SelectorRunner.iterateKeys(SelectorRunner.java:371)
> at
> org.glassfish.grizzly.nio.SelectorRunner.doSelect(SelectorRunner.java:337)
> at
> org.glassfish.grizzly.nio.SelectorRunner.run(SelectorRunner.java:267)
> at
> org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:566)
> at
> org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:546)
> at java.lang.Thread.run(Thread.java:662)
> (it was with jdk 1.6.0_29).
> Regards,
> Igor.
>
>
> On Wed, Jan 18, 2012 at 4:37 PM, Pavel Bucek <pavel.bucek_at_oracle.com>wrote:
>
>> Hi Igor,
>>
>> I'm not aware of any retrying logic there. We recently changed underlying
>> implementation which might fix this issue - can you please try recent build
>> (version 1.12-SNAPSHOT)?
>>
>> Regards,
>> Pavel
>>
>>
>> On 1/18/12 12:56 PM, Igor Skornyakov wrote:
>>
>>> Hello,
>>> I'm migrating a stress test for my REST application to Jersey
>>> non-blocking client version 1.11. Everything works fine with one problem -
>>> some requests are sent twice and I'm pretty sure that my code does not do
>>> that (I have some retry logic but in such cases there is a corresponding
>>> message in a log). If it is a feature of client API how can I disable it
>>> (at least for POSTs)? I see in the server log both requests - the first is
>>> accepted and a valid response has been return returned, the second one -
>>> rejected (which is correct in my case). However at the client side I
>>> receive only the second (error) response.
>>>
>>> Thank you,
>>> Igor.
>>>
>>>
>>
>
>