dev@grizzly.java.net

Re: IOEvent.CLOSED –event handling on connection object.

From: ming qin <mingqin1_at_yahoo.com>
Date: Mon, 15 Mar 2010 07:00:51 -0700 (PDT)

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