On 08/04/2014 03:42 PM, David M. Lloyd wrote:
Servlets are EE components, and as such, you should be able to establish
a @PreDestroy interceptor, which was introduced for exactly this kind of
purpose (cleanup and reclaiming of per-component resources). Also
servlets have a destroy method IIRC.
On 08/04/2014 06:27 AM, Florian Weimer wrote:
On 08/01/2014 06:39 AM, Jaroslav Tulach wrote:
Dne Út 29. července 2014 14:13:25, Florian Weimer napsal(a):
On 07/29/2014 10:05 AM, Jaroslav Tulach wrote:
Plus, because there is a single classloader which loads all the classes
from a WAR, by keepin
On 08/01/2014 06:39 AM, Jaroslav Tulach wrote:
Dne Út 29. července 2014 14:13:25, Florian Weimer napsal(a):
On 07/29/2014 10:05 AM, Jaroslav Tulach wrote:
Plus, because there is a single classloader which loads all the classes
from a WAR, by keeping the activerReferenceQueue thread alive and ho
Dne Út 29. července 2014 14:13:25, Florian Weimer napsal(a):
> On 07/29/2014 10:05 AM, Jaroslav Tulach wrote:
> > Plus, because there is a single classloader which loads all the classes
> > from a WAR, by keeping the activerReferenceQueue thread alive and holding
> > reference to the queue, we hold
On 07/29/2014 10:05 AM, Jaroslav Tulach wrote:
Plus, because there is a single classloader which loads all the classes from a
WAR, by keeping the activerReferenceQueue thread alive and holding reference
to the queue, we hold reference to its class and the classloader and thus all
classes referenc
Hi Jaroslav,
On 29/07/2014 7:24 PM, Jaroslav Tulach wrote:
Hello David,
the following suggestions are hard to argue with as they touch philosophical
aspects of software engineering. In spite of that I will attempt to analyze
and argue:
Always happy to get philosophical about software design :)
On 07/29/2014 11:06 AM, Jaroslav Tulach wrote:
> >This is basically a re-implementation of ReferenceQueue.remove(int
> >timeout) instance method in terms of a static method, which only briefly
> >"touches" the queue instance wrapped in a Reference but majority of time
> >it waits for notification
Hello David,
the following suggestions are hard to argue with as they touch philosophical
aspects of software engineering. In spite of that I will attempt to analyze
and argue:
Dne Út 29. července 2014 18:16:24, David Holmes napsal(a):
> I think the fundamental flaw of activeReferenceQueue is in
Dne Út 29. července 2014 18:16:24, David Holmes napsal(a):
> Thanks for the detailed explanation. It is an interesting problem.
Good. I am glad it attracted your attention. I am also glad Peter came with
his static method...
> On 29/07/2014 6:03 PM, Peter Levart wrote:
> > On 07/29/2014 04:16 A
On 07/29/2014 10:18 AM, Jaroslav Tulach wrote:
Thanks Peter,
I had a feeling that two threads might address the issue and your work
indicates they really can. I am sort of worried about the overhead of
a single thread (~1MB?), but certainly using two threads is better
than having our curren
Thanks Peter,
I had a feeling that two threads might address the issue and your work
indicates they
really can. I am sort of worried about the overhead of a single thread (~1MB?),
but
certainly using two threads is better than having our current reflection which
works on
JDK7, JDK8, but is br
Hi Peter,
Thanks for the detailed explanation. It is an interesting problem. But
at this stage my only conclusion is that we are nowhere near the point
of deciding to add a new method to a public API.
I think the fundamental flaw of activeReferenceQueue is in trying to
hide the thread manage
Hi Jaroslav,
Please don't keep creating new email threads as yu are making it very
hard to track the discussion.
On 29/07/2014 6:05 PM, Jaroslav Tulach wrote:
Hello David.
Dne Út 29. července 2014 12:16:33, David Holmes napsal(a):
So ... activeReferenceQueue is a reference queue that embodi
Hello David.
Dne Út 29. července 2014 12:16:33, David Holmes napsal(a):
> So ... activeReferenceQueue is a reference queue that embodies a thread
> that does the polling and implements a psuedo-finalization mechanism.
> This works fine in the normal case where the lifetime of the queue is
> the li
On 07/29/2014 04:16 AM, David Holmes wrote:
Hi Jaroslav,
So ... activeReferenceQueue is a reference queue that embodies a
thread that does the polling and implements a psuedo-finalization
mechanism. This works fine in the normal case where the lifetime of
the queue is the lifetime of the "ap
Hi Jaroslav,
So ... activeReferenceQueue is a reference queue that embodies a thread
that does the polling and implements a psuedo-finalization mechanism.
This works fine in the normal case where the lifetime of the queue is
the lifetime of the "application". In the WAR case (and I don't know
Hello Jaroslav,
Regardless of where it is implemented (in JDK or in NetBeans) it would
be impossible to create something that doesn't do polling in a single
thread and yet wait for two ReferenceQueues at the same time - one is
the queue of Runnable references which you run() and the other is t
Hello David,
thanks for being patient with me. I'll do my best to describe the original
context.
Dne Po 28. července 2014 21:07:45, David Holmes napsal(a):
> I read the issue and still did not understand the nature of the problem.
> The netbeans bugs also did not shed any light on things for me.
18 matches
Mail list logo
