On Wed, May 6, 2009 at 4:13 PM, boB Gage <[email protected]> wrote:
> Hmmmm, the links seem to imply that the answer to my question is that you
> were talking to me and code at my level should be calling
> IoConnector.dispose() as part of my clean up for each discovery.

yep.

>
> So I put that code in.    But it had no visible impact.
>
> So I added debug logging to ensure I had placed the code properly and it was
> in the execution chain properly.    I see the debug line between each
> discovery attempt -- the log line is right before the dispose() call.    And
> still each discovery attempt leaves two more running threads than the one
> before it.

Best to create a JIRA ticket in that case.

regards,
Maarten

>
> Not taking the code out, because it certainly seems the right thing to do
> even if it didn't fix the immediate problem....   but it didn't fix the
> immediate problem.  :-(
>
> boB
>
>
> Maarten Bosteels wrote:
>>
>> The dispose method is analogous to the close method on
>> java.io.OutputStream
>>
>> http://java.sun.com/j2se/1.5.0/docs/api/java/io/OutputStream.html#close()
>> http://java.sun.com/j2se/1.5.0/docs/api/java/io/Closeable.html
>>
>> see also http://www.javapractices.com/topic/TopicAction.do?Id=24
>>
>> regards,
>> Maarten
>>
>> On Tue, May 5, 2009 at 9:06 PM, boB Gage <[email protected]> wrote:
>>
>>>
>>> I didn't dispose it???   Or Emmanuel didn't??   :-)
>>>
>>> As I understand, Java's GC should happen automagically once I stop
>>> referencing the old IoConnector object.   So, I am re-setting the same
>>> variable to a new one without doing anything special to dispose of the
>>> old
>>> one.
>>>
>>> Isn't that the Java way??
>>>
>>> boB
>>>
>>> Julien Vermillard wrote:
>>>
>>>>
>>>> Le Thu, 30 Apr 2009 22:03:46 +0200,
>>>> Emmanuel Lecharny <[email protected]> a écrit :
>>>>
>>>>
>>>>
>>>>>
>>>>> boB Gage wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> Emmanuel,
>>>>>>
>>>>>> That's kind of how the original C++ code that I'm porting worked...
>>>>>>
>>>>>> The various devices we use each have their own serial parameters
>>>>>> (baud,
>>>>>> stop/start/partity bits et al) so all have their own SerialAddress
>>>>>> objects
>>>>>> to open & close.    Each device handler (ie
>>>>>> our code) has it's own codec factory -- so there's not a single
>>>>>> shared one for all the devices to be discovered (that would be way
>>>>>> too unwieldy for words).
>>>>>>
>>>>>> I've tried re-using IoConnector objects and just change handlers,
>>>>>> but the IoConnector.setHandler() method (IoService.java) complains
>>>>>> bitterly if I assign a new handler to an existing connection.
>>>>>>
>>>>>>
>>>>>
>>>>> I would have kept the same handler, just switched the codec. Creating
>>>>> a new NioConnector is quite expensive.
>>>>>
>>>>>
>>>>>>
>>>>>> I have eliminated the synchronized clauses as a source, and had my
>>>>>> Java
>>>>>> understanding expanded in the process.  :-)   One of the two unbound
>>>>>> threads
>>>>>> *is* caught in that quoted wait() call however.    Perhaps because we
>>>>>> failed
>>>>>> to flush a failed session before closing it???  [ the notify is in a
>>>>>> flush ]
>>>>>>
>>>>>>
>>>>>
>>>>> Hmmmm... Without the code, it's difficult to say. Also, it's now 3
>>>>> weeks I didn't looked at the code, so I can't give you an decent
>>>>> advice atm...
>>>>>
>>>>>
>>>>
>>>> I think you didn't disposed (connector.dispose();) the old NioConnector.
>>>> Julien
>>>>
>>>>
>>>
>>> --
>>> boB Gage
>>> Software Engineer
>>> Merge Healthcare
>>>
>>>
>>> This message is a PRIVATE communication. This message and all
>>> attachments are a private communication and may be confidential or
>>> protected by privilege. If you are not the intended recipient, you are
>>> hereby notified that any disclosure, copying, distribution or use of the
>>> information contained in or attached to this message is strictly
>>> prohibited. Please notify the sender of the delivery error by replying
>>> to this message, and then delete it from your system. Thank you.
>>>
>>>
>>>
>
> --
> boB Gage
> Software Engineer
> Merge Healthcare
>
>
> This message is a PRIVATE communication. This message and all
> attachments are a private communication and may be confidential or
> protected by privilege. If you are not the intended recipient, you are
> hereby notified that any disclosure, copying, distribution or use of the
> information contained in or attached to this message is strictly
> prohibited. Please notify the sender of the delivery error by replying
> to this message, and then delete it from your system. Thank you.
>
>

Reply via email to