|
| Re: JmDNSDiscoveryContainer and IDE shutdown [message #596634 is a reply to message #592064] |
Mon, 16 January 2006 16:50   |
 Bill Joy
Messages: 60
Registered: July 2009 |
Member |
|
|
Thanks Scott, my initial testing indicates that ECF 0.6.0 which delivers the
updated JmDNS jar seems to have fixed the shutdown problem.
For others out there, here is a section from a reply you sent me:
Since ECF containers (in general) can allocate system resources (like
sockets, etc) there needs to be either a) some way of explicitly freeing
those resources (e.g. dispose()) or b) some way of implicitly freeing those
resources (e.g. having ECF keep track of created containers and then calling
dispose() on any/all of them when org.eclipse.ecf stop is called...or
requiring/suggesting that provider implementations do this for any
IContainer instances that they create).
For the moment, we've chosen 'a'. This could change if appropriate, but
'a' was the initial design choice. Would appreciate feedback about this.
"Bill Joy" <bjoy@borland.com> wrote in message
news:dpm9bj$60f$1@utils.eclipse.org...
> Is it the responsibility of the plugin which creates it to dispose the
> JmDNS
> container (rather than depend on the JmDNS shutdown hook) when Eclipse is
> terminating?
>
> And if so, how can this be done reliably?
>
> If I do nothing on exit to dispose it, I get an exception like the
> following:
>
> Exception in thread "JmDNS.Shutdown" java.lang.NoClassDefFoundError:
> javax/jmdns/JmDNS$Canceler
> at javax.jmdns.JmDNS.unregisterAllServices(JmDNS.java:683)
> at javax.jmdns.JmDNS.close(JmDNS.java:2322)
> at javax.jmdns.JmDNS$Shutdown.run(JmDNS.java:2260)
> at java.lang.Thread.run(Thread.java:595)
>
> If I try to use my Plugin.stop(), most times it works, but too often the
> dispose() call never returns and so Eclipse termination hangs.
>
> I suspect there is a deadlock in JmDNS causing this hang. Here
> are what I think are the relevant stacks which I suspended to
> see where they were executing:
>
> Thread [Timer-0] (Suspended)
> JmDNS$RecordReaper.run() line: 1184
> TimerThread.mainLoop() line: 512
> TimerThread.run() line: 462
>
> Thread [JmDNS.SocketListener] (Suspended)
> JmDNS.updateRecord(long, DNSRecord) line: 887
> JmDNS.handleResponse(DNSIncoming) line: 1003
> JmDNS.access$6(JmDNS, DNSIncoming) line: 938
> JmDNS$SocketListener.run() line: 1148
> Thread.run() line: 595
>
> Thread [System Bundle Shutdown] (Suspended)
> Object.wait(long) line: not available [native method]
> Thread.join(long) line: 1095
> Thread.join() line: 1148
> JmDNS.closeMulticastSocket() line: 291
> JmDNS.close() line: 2326
> JMDNSDiscoveryContainer.disconnect() line: 228
> JMDNSDiscoveryContainer.dispose() line: 97
> <snip rest of stack>
>
> I am using 1.5.0_03-b07 and ECF 0.5.4.
>
>
>
>
>
|
|
|
| Re: JmDNSDiscoveryContainer and IDE shutdown [message #596642 is a reply to message #596634] |
Mon, 16 January 2006 21:15 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Bill/all,
Bill Joy wrote:
> Thanks Scott, my initial testing indicates that ECF 0.6.0 which delivers the
> updated JmDNS jar seems to have fixed the shutdown problem.
Terrific.
>
> For others out there, here is a section from a reply you sent me:
>
> Since ECF containers (in general) can allocate system resources (like
> sockets, etc) there needs to be either a) some way of explicitly freeing
> those resources (e.g. dispose()) or b) some way of implicitly freeing those
> resources (e.g. having ECF keep track of created containers and then calling
> dispose() on any/all of them when org.eclipse.ecf stop is called...or
> requiring/suggesting that provider implementations do this for any
> IContainer instances that they create).
>
> For the moment, we've chosen 'a'. This could change if appropriate, but
> 'a' was the initial design choice. Would appreciate feedback about this.
Yes...please do comment on this. It is easy/trivial to add support for
disposing containers automatically upon shutdown of the ECF core
plugin...is this something people think is desireable/necessary? What
say ye?
Adding it won't even require an API change...which I'm sure everyone
(especialy me) are happy to hear. The more I think about it, the more
I'm inclined to have ECF shutdown automatically trigger calling of
IContainer.dispose() on containers that have been created via the
ContainerFactory.
This would then be very much like the SWT 'dispose' rule: If you create
and SWT entity via a constructor, then you have the responsibility to
call dispose() yourself. If you get an SWT resource through some other
means (e.g. getFont()) then it's the responsibility of the owner to call
dispose().
Analogously, ECF could adopt the rule that if you create an IContainer
via the ContainerFactory that it's ECF's responsibility to call the
dispose() upon ECF shutdown. Then, if containers happen to be created
in other ways (e.g. via their constructors), the responsibility would be
back on the calling code.
How does this sound to people?
Scott
|
|
|
Powered by
FUDForum. Page generated in 0.03207 seconds
] 
Search
Help
Register
Login
Home
