Hello Alexey,
I've tried 1.12-SNAPSHOT again and encountered a lot of IOExceptions with
the "An existing connection was forcibly closed by the remote host"
message. I do have such exceptions with version 1.11 but far less of them.
It is not a showstopper in my case - just irritating. It also seems that
the performance is not as good as with 1.11 (not sure about this - just an
impression).
BTW: I've discovered that AHC-1.65 indeed performs requests retry - see
NettyAsyncHttpProvider.remotelyClosed() method. It is possible of course
use "com.ning.http.client.providers.netty.maxRetry" Java system property
or AsyncHttpClientConfigBean to suppress this behavior, but this will
affect all HTTP methods (including idempotent ones where automatic retry
can be acceptable or even desirable). May be it makes sense just to change
NettyResponseFuture.canRetry() method and suppress retrying for
non-idempotent requests regardless of the value of "maxRetry"?
Regards,
Igor.
On Wed, Jan 18, 2012 at 5:09 PM, Igor Skornyakov
<igor.skornyakov_at_gmail.com>wrote:
> 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.
>>>>
>>>>
>>>
>>
>>
>