oodt-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Foster <holeno...@me.com>
Subject Re: PushPull DaemonLauncher
Date Tue, 03 Dec 2013 19:41:37 GMT
Hey Cameron,

can you attach the logs when you come across another case where the pushpull gets stuck?

i was doing a quick pass through the code... it looks like the DaemonController stays up all
the time... wait() is called on it... i thought there was a notify() call when daemon queue
became empty, which would cause the DaemonController to wake up and terminate, but i don't
see it... i will see if i can get a fix in for that sometime this week.


On Nov 30, 2013, at 03:08 PM, Cameron Goodale <sigep311@gmail.com> wrote:

Hey Brian and Jordan,

I have a similar issue with trying to run pushpull within a cron because
for some reason (i need to sort out) my pushpull daemon will just hang
after running and sleeping successfully using
the org.apache.oodt.cas.protocol.ftp.CommonsNetFtpProtocol. I haven't
taken the time to find out how many sleep/wake cycles it takes to
eventually hang, but I have seen it happen several times now.

I looked into the code and it seems like updating the runInfo tag so
period="" should short circuit the code from re-running, but when I have
done this in testing I get a message like this:

Nov 30, 2013 10:07:32 AM
org.apache.oodt.cas.pushpull.protocol.ProtocolHandler disconnect
INFO: Disconnecting protocol
Nov 30, 2013 10:07:32 AM org.apache.oodt.cas.pushpull.daemon.Daemon$1 run
INFO: Daemon with ID = 90111 on RMI registry port 9011 is shutting down

but the process doesn't actually stop. Looking at Daemon.java I see that:
Daemon.this.unregister(); is called right after that log message, but it
doesn't seem to quit the process. That command is run within a Java Thread
object, but nothing seems to stop the Thread, so the daemon will never exit.

If you guys have made any progress on this I would love to hear about it.
I am also not an expert on Java Threads, so I could have missed something
in the code, but it seems like the Thread is started and never terminated.

Thanks for reading,


On Thu, Nov 21, 2013 at 1:43 PM, Brian Foster <holenoter@me.com> wrote:

Hey Jordan,
Try not specifying the <runInfo> element for your daemons in
RemoteSpecs.xml file. It should just run once through for those sites. I
believe the pushpull shuts down automatically when all deamons have
terminated, so after you run one pass it should just terminate. It's been
a while since i've worked with push-pull code, if that doesn't work i'll
have to dig further into the code.
if you looking to do just a on off download a given file, then you might
consider just using cas-protocol directly. Take a look at:
You can run cas-protocol via this bin script:
Just build and deploy like all other cas products and that script will end
up in the bin directory. If you would like to add custom action to
cas-protocol there is documentation for this at:
On Nov 07, 2013, at 05:31 PM, Jordan Padams <jordan.padams@gmail.com>
Hello all,
I am trying to develop a pretty simple wrapper for the PushPull where I
call the DaemonLauncher to run through the daemons in my config once and
then shut down altogether. We currently don't have a need to have the
software running at intervals.
On that note, here are a few of the methods I've tried but haven't worked:
1. DaemonLauncher.main() - The software hangs because of the wait() waiting
for a notify().
2. DaemonLauncher.viewDaemonWaitingList() - I've tried monitoring the
daemon waiting list, and quit() the DaemonLauncher once it gets to 0, but
then it misses the last daemon in my config.
Is there a way for me to wait on the DaemonLauncher until all daemons have
completed, then quit?
I've implemented a quick workaround by creating the following method so I
can see if daemons are still running:
public boolean hasRunningDaemons() {
return this.dm.hasRunningDaemons();
I don't have a lot of experience with daemon processes so this may just be
something I'm blatantly missing. Appreciate the help.
Jordan Padams
Software Engineer
NASA Jet Propulsion Laboratory


Sent from a Tin Can attached to a String

  • Unnamed multipart/alternative (inline, None, 0 bytes)
    • Unnamed multipart/related (inline, None, 0 bytes)
View raw message