On Sat, 17 Jul 2010, Darren Govoni wrote:
I wonder why attach locks under processes but not threads though? Is it jcc
related or JVM?
If you're running things in sub-processes, I don't think it makes any sense
to call attachCurrentThread() into the parent JVM at all, nor do I expect
calls i
On Fri, 16 Jul 2010, Darren Govoni wrote:
I corrected some things with my threads, so I'm sure they are being reused
now.
But I was using python's multiprocessing module and my worker threads were
actually processes.
This is where I saw the lock up after a period of time.
Ah ha, so nothing t
On Sat, 17 Jul 2010, Andi Vajda wrote:
On Jul 16, 2010, at 23:14, Darren Govoni wrote:
btw. I have a timer thread that watches a message queue and then
performs lucene lookups, so every time
that timer thread invokes my object, its a new thread.
Don't do that. Instead, pool your threads a
On Jul 16, 2010, at 23:14, Darren Govoni wrote:
btw. I have a timer thread that watches a message queue and then
performs lucene lookups, so every time
that timer thread invokes my object, its a new thread.
Don't do that. Instead, pool your threads and reuse them.
Andi..
I tried calling
On Jul 16, 2010, at 18:48, Darren Govoni wrote:
Hi,
I have a situation where I have multiple (4) python objects that use
pylucene and initVM's and attach to their own threads.
It works fine for a bit, but eventually calls to
vm.attachCurrentThread() hangs and never returns across those
obj
Hi,
I have a situation where I have multiple (4) python objects that use
pylucene and initVM's and attach to their own threads.
It works fine for a bit, but eventually calls to
vm.attachCurrentThread() hangs and never returns across those objects -
each in a separate thread. I only call getVMEnv
