Thanks Alexey.
Matt
On 16/03/10 16:36, Oleksiy Stashok wrote:
> Hi Matt,
>
>> I think that Bo is referring to the client side where this can be
>> more easily managed since connections are explicitly created and closed.
> I see.
>
>> However, I don't see any reason why this cannot be managed outside of
>> Grizzly, since the client library/app knows when a connection is
>> being opened/closed. We could bring up the transport for the first
>> connection request and shut it down when the last connection is
>> closed. This may not perform so well for cases where the client
>> application repeatedly opens and closes a single connection since the
>> transport will be continuously restarted. I think a better approach
>> is to lazily create the transport on the first connection request and
>> then keep it up and running. The only issue then is to ensure that
>> the Grizzly threads exit gracefully during application termination
>> (e.g. by making them daemon threads).
>>
>> Is it a good idea to change the Grizzly threads to be daemon threads?
> It's possible to change default thread pool implementation, so you may
> provide a ThreadFactory, which creates the daemon threads. By default
> - IMO it could be better to keep threads in non-daemon mode, because
> if thread doesn't exit gracefully - it could hide some bigger issues.
>
> Thanks.
>
> WBR,
> Alexey.
>
>
>>
>> Matt
>>
>> On 16/03/10 14:50, Oleksiy Stashok wrote:
>>> Hi Bo,
>>>
>>> don't think it's doable, or may be I just don't understand your idea
>>> completely.
>>> The reason is that transport can not create connections until it's
>>> not started.
>>>
>>> WBR,
>>> Alexey.
>>>
>>>
>>> On Mar 15, 2010, at 22:58 , ming qin wrote:
>>>
>>>> Hi Bo:
>>>> "It would be nice if Grizzly starts the transport when at least
>>>> one connection is created and stops when all the connections are
>>>> closed."
>>>>
>>>> Do you mean that Grizzly offers a daemon process which controls
>>>> Transport life cycle ( Open/Shut Down) through that daemon process
>>>> monitors number of valid connections?
>>>>
>>>> or
>>>> You just don't like Transport offers start() method to end-users
>>>>
>>>> Ming Qin
>>>> Cell Phone 858-353-2839
>>>>
>>>> --- On *Mon, 3/15/10, Bo Li /<b.li_at_sun.com <mailto:b.li_at_sun.com>>/*
>>>> wrote:
>>>>
>>>>
>>>> From: Bo Li <b.li_at_sun.com <mailto:b.li_at_sun.com>>
>>>> Subject: Transport start/stop automatically on demand?
>>>> To: users_at_grizzly.dev.java.net <mailto:users_at_grizzly.dev.java.net>
>>>> Date: Monday, March 15, 2010, 12:13 PM
>>>>
>>>> Hi Alexey
>>>>
>>>> Is there a way for the TCPNIOTransport to start and stop
>>>> automatically? In our SDK, we don't want to expose Grizzly to the
>>>> end users. It would be nice if Grizzly starts the transport when
>>>> at least one connection is created and stops when all the
>>>> connections are closed. This avoid the end users from having to
>>>> call some sort of start/stop method explicitly.
>>>>
>>>> Thanks
>>>> Bo
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>> </mc/compose?to=users-unsubscribe_at_grizzly.dev.java.net>
>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>> </mc/compose?to=users-help_at_grizzly.dev.java.net>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>