C'mon, I admit we still change some details in 2.0 API, but pls. not
perf. again :)))
> to prove that Grizzly 2.0 is not slow, I've run a small echo test.
> I've compared Grizzly 1.9.19 (svn trunk) and Grizzly 2.0 (svn trunk)
> configured with different strategies. The result shows that Grizzly
> 2.0 performing better or equal to 1.9.x. The difference is more
> significant when echoing tiny packets.
> Here are server and client configs:
>
> Server:
> numberOfCpus: 4
> osName: SunOS 5.10 Generic_Patch_118844-30 i86pc i386 i86pc
> numberOfSelectorThreads: 4
> numberOfWorkerThreads: 5
>
> Client:
> numberOfCpus: 2
> numberOfThreads: 32
> osName: Mac OS X
>
> I didn't use powerful machines during the test, but I think it's
> enough to confirm that Grizzly 2.0 with all its API extensions/
> changes is not slow.
>
> Thanks.
>
> WBR,
> Alexey.
>
> http://tinyurl.com/yemhry7
On Mar 30, 2010, at 18:48 , Ray Racine wrote:
> Thanks. The work around will work nicely. If you could get it into
> trunk 1.9.19 that would be great. I'm holding off on 2.0 until it
> approaches the approx. the same stability and performance as 1.9.x.
>
> Ray
>
> On Tue, Mar 30, 2010 at 12:17 PM, Oleksiy Stashok <Oleksiy.Stashok_at_sun.com
> > wrote:
> Oh, sorry, my fault - for some reason I understood that we're
> talking about soTimeout.
>
> Currently we don't have a good way how to specify socket keepalive
> timeout, though we can easily add it to 1.9.19 version (trunk).
> If you use GWS - there is no way to customize socket keepalive
> timeout at all. In case you use SelectorThread approach - it's
> possible to gain this.
>
> selectorThread = new SelectorThread() {
> /**
> * Create {_at_link TCPSelectorHandler}
> */
> @Override
> protected TCPSelectorHandler createSelectorHandler() {
> return new SelectorThreadHandler(this) {
> @Override
> public void configureChannel(SelectableChannel channel)
> throws IOException{
> super.configureChannel(channel);
> channel.setKeepAlive(true);
> }
> }
> }
> }
>
> WBR,
> Alexey.
>
> On Mar 30, 2010, at 17:40 , Ray Racine wrote:
>
>> Oleksly,
>>
>> Thanks for the fast replies.
>>
>> From SelectorThread.java
>>
>> /**
>> * Sets the number of seconds before a keep-alive connection
>> that has
>> * been idle times out and is closed.
>> *
>> * @param timeout Keep-alive timeout in number of seconds
>> */
>> public void setKeepAliveTimeoutInSeconds(int timeout) {
>> keepAliveStats.setKeepAliveTimeoutInSeconds(timeout);
>> if (keyHandler != null) {
>> keyHandler.setTimeout(timeout == -1
>> ? SelectionKeyAttachment.UNLIMITED_TIMEOUT:
>> timeout * 1000L);
>> }
>> }
>>
>> Between the client and the server is a NATing Load Balancer. This
>> appliance _will_ timeout and sever an idle connection unless some
>> activity is induced, e.g., a zero data packet. See http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html
>> Section 2.4 as the use-case.
>>
>> Say I use the above code and setKeepAliveTimeoutInSeconds(-1) //
>> infinite
>> Will Grizzly send some sort of nuance packet to prevent the NAT/
>> Load Balancer from timing out my idle TCP connection?
>>
>> I know adjustments can be done directly on the NATing appliance but
>> I'd still like to do it at the code level.
>>
>> In other words, does setting the above achieve the same effect as http://java.sun.com/javase/6/docs/api/java/net/Socket.html#setKeepAlive(boolean)
>> ?
>>
>> Sorry for so many questions today :)
>>
>> Thanks,
>>
>> Ray
>>
>> On Tue, Mar 30, 2010 at 11:15 AM, Oleksiy Stashok <Oleksiy.Stashok_at_sun.com
>> > wrote:
>> Ok, so to set idle timeout please use:
>> gws.getSelectorThread().setKeepAliveTimeoutInSeconds(timeout);
>>
>> if you want to disable timeout - set "-1".
>>
>> WBR,
>> Alexey.
>>
>> On Mar 30, 2010, at 16:59 , Ray Racine wrote:
>>
>>> I'm configuring everything directly at the SelectorThread API
>>> using examples like GrizzlyWebServer.java,
>>> GrizzlyEmbeddedHttp.java etc.
>>>
>>> Ray
>>>
>>> On Tue, Mar 30, 2010 at 9:22 AM, Oleksiy Stashok <Oleksiy.Stashok_at_sun.com
>>> > wrote:
>>> Hi Ray,
>>>
>>> in Grizzly we don't turn on standard socket keepalive mechanism,
>>> but use our own (via SelectionKeyHandler API).
>>>
>>> If you'd share your Grizzly initialization code - I'll help to
>>> change keep alive settings.
>>>
>>> WBR,
>>> Alexey.
>>>
>>>
>>>
>>> On Mar 30, 2010, at 14:12 , Ray Racine wrote:
>>>
>>> I notice a number of KeepAlive values in Grizzly, however, I've
>>> been unable to find where in Grizzly at the socket level where
>>> Socket s, s.setKeepAlive (true) is invoked. My use case is to
>>> prevent the NAT from timing out an idle TCP/IP connection.
>>>
>>> In this case I'm seeking to sustain a dedicated connection between
>>> client and server with basic HTTP req/resp. I'd like to set the
>>> socket TCP keep alive but I don't see where to do it.
>>>
>>> Thanks,
>>>
>>> Ray
>>>
>>> --
>>> The object of life is not to be on the side of the majority, but
>>> to escape finding oneself in the ranks of the insane. - Marcus
>>> Aurelius
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>
>>>
>>>
>>>
>>> --
>>> The object of life is not to be on the side of the majority, but
>>> to escape finding oneself in the ranks of the insane. - Marcus
>>> Aurelius
>>
>>
>>
>>
>> --
>> The object of life is not to be on the side of the majority, but to
>> escape finding oneself in the ranks of the insane. - Marcus Aurelius
>
>
>
>
> --
> The object of life is not to be on the side of the majority, but to
> escape finding oneself in the ranks of the insane. - Marcus Aurelius