On 1/23/08 5:12 PM, "Jeanfrancois Arcand" <Jeanfrancois.Arcand_at_Sun.COM>
wrote:
>
>
> Erik Svensson wrote:
>> On 1/23/08 12:06 AM, "Piotr Bazan" <bazi_at_world.pl> wrote:
>>
>>> Hola,
>>>
>>> Oleksiy Stashok wrote:
>>>> Hello,
>>>>
>>>> if you're registering callbackHandler with ConnectorHandler, it's
>>>> required to call finishConnect on onConnect event. For example:
>>>>
>>>> / public void onConnect(IOEvent<Context> ioEvent) {
>>>> SelectionKey key = ioEvent.attachment().getSelectionKey();
>>>> try{
>>>> tcpConnector.finishConnect(key);
>>>> } catch (IOException ex){
>>>> // log
>>>> }
>>>> ioEvent.attachment().getSelectorHandler().register(key,
>>>> SelectionKey.OP_READ);
>>>> }
>>>> /
>>>>
>>>> Thanks.
>>>>
>>>> WBR,
>>>> Alexey.
>>> Isn't it dangerous to just ignore the IOException? TCPConnector
>>> finishConnect wraps socketChannel's finishConnect which (probably pretty
>>> rarely but still) can throw exception leaving a socket in an unconnected
>>> state. Even better, according to SocketChannel.finishConnect() 1.5 java doc:
>>> "If a connection attempt fails, that is, if an invocation of this method
>>> throws a checked exception, then the channel will be closed."
>>>
>>> So we can end up with an unusable selectionKey (with underlaying channel
>>> closed) being put in the Selector's set.
>>>
>>> I haven't checked so it's just a theory :)
>>
>> Isn't checking TCPConnectorHandler:isConnected() enough?
>> If the connection attempt bombs it should return false.
>> Obviously you have to check it yourself but the functionality is there.
>
> Right, but at the minimum we should log the exception I think. What do
> you think?
Logging is good. There is a problem with eating the exception since we can't
programmatically determine why we didn't get the connection or if we haven't
tried yet. But that might be nit-picking.
cheers
Erik Svensson, SIX AB