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
>