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 to do with attachCurrentThread() after all.
I switch my workers to just plain threads and I don't get the lockup.
Not sure what it means though.
I tried to do something similar, use Python's multiprocessing from a
jcc-embedded Python VM inside a Tomcat Java VM and also had lock-up
problems. I eventually gave up and just used threads, not as GIL-happy but
good enough and without any lock-ups.
Andi..
Darren
On Fri, 2010-07-16 at 16:29 -0700, Andi Vajda wrote:
On Sat, 17 Jul 2010, Andi Vajda wrote:
>
> On Jul 16, 2010, at 23:14, Darren Govoni <dar...@ontrenet.com> 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.
Another thing you could do is create your threads by instantiating Java's
java.lang.Thread class instead of Python's. No attachCurrentThread()
call then is needed since the OS thread is created by the JVM.
Andi..
>
> Andi..
>
>>
>> I tried calling detachCurrentThread in the object's method after the
>> attach and the detach threw a java compiler exception right away.
>>
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> # SIGSEGV (0xb) at pc=0x00522e51, pid=23974, tid=3075853168
>> #
>> # JRE version: 6.0_20-b02
>> # Java VM: Java HotSpot(TM) Client VM (16.3-b01 mixed mode, sharing
>> linux-x86 )
>> # Problematic frame:
>> # C [libjcc.so+0x9e51] _ZN6JCCEnv15deleteGlobalRefEP8_jobjecti+0x171
>> #
>> # An error report file with more information is saved as:
>> #
>> /home/darren/Gridwave/product/trunk/symphony/server/software/hs_err_pid23
974.log
>> #
>> # If you would like to submit a bug report, please visit:
>> # http://java.sun.com/webapps/bugreport/crash.jsp
>>
>> It seems I can't use the pylucene object as a singleton because new
>> instances are created by new threads that need to be attached.
>>
>> Tricky this is.
>>
>> On Fri, 2010-07-16 at 16:59 -0400, Darren Govoni wrote:
>>
>>> Ok, thanks Andi.
>>>
>>> On Fri, 2010-07-16 at 20:04 +0200, Andi Vajda wrote:
>>>
>>>> On Jul 16, 2010, at 18:48, Darren Govoni <dar...@ontrenet.com> 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
>>>>> objects -
>>>>> each in a separate thread. I only call getVMEnv() once in each objects
>>>>> init.
>>>>>
>>>>> I guess I'd like to know if this is something I'm doing wrong or can
>>>>> fix?
>>>>>
>>>>> I'm on the latest build (but this problem occurred before updating)
>>>>
>>>> Try calling attachCurrentThread() only once per thread and reusing
>>>> these threads instead of creating and throwing them away. If you still
>>>> must dispose of threads, try calling detachCurrentThread() but it's
>>>> not guaranteed to work safely if anything in Python is still holding
>>>> any java object references.
>>>>
>>>> Andi..
>>>>
>>>>>
>>>>> thanks,
>>>>> Darren
>>>
>>>
>>
>
