Hi Oleksiy Stashock:
Thanks for explanation. I will do more tests to ensure Connection Object is explicitly off of being referenced once corresponding SelectionKey is canceled.
Ming Qin
Cell Phone 858-353-2839
--- On Mon, 3/15/10, Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM> wrote:
From: Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM>
Subject: Re: IOEvent.CLOSED –event handling on connection object.
To: dev_at_grizzly.dev.java.net
Date: Monday, March 15, 2010, 3:26 AM
You can correct me, but I think the only reference to a Connection object we have in SelectionKey.attachment(), so once the key get's cancelled - we clean up attachment - so there should not be any Grizzly internal ref. to the released connection object.
WBR,Alexey.
On Mar 14, 2010, at 8:45 , ming qin wrote:
Hi:
Scenario: Invoking coonection.close() in Grizzly server’s filter handleXXXXX methods Tcp/Ip client shuts down. Codes: TCPNIOTransport.java in Grizzly2dot0
public IOEventReg fireIOEvent(final IOEvent ioEvent, final Connection connection)is the one taking care of IOEvent.CLOSED event Potential Problem- memory leak When IOEvent.ClOSED is occurred, Objects such as selectionKey and channel are explicitly cleaned up by corresponding close() method. But Grizzly codes don’t release all references to the object of connection. Should we have a mechanism to clear up connection object explicitly when IOEvent.CLOSED occurs?
Ming Qin
Cell Phone 858-353-2839