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
>