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 into the parent JVM to work.
If, on the other hand, you create a new JVM in each sub-process (something I
don't expect to work well either, if at all), then these sub-processes are
the 'main' thread for the JVM and thus don't need attachCurrentThread()
at all.
There are advantages to using heavy-weight processes over threads though,
one being tighter integration with SMP and multicore CPUs under linux.
Of course, but then don't think of them as threads but rather as processes
and start a JVM for each and every one of them, something pretty heavy.
Andi..
On Sat, 2010-07-17 at 03:16 -0700, Andi Vajda wrote:
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_pid
23
> 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 objec
ts
> >>>>> 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 stil
l
> >>>> 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
> >>>
> >>>
> >>
> >
>
>
>
>
