[Swift-devel] [Bug 72] Campaign for scaling wf up to 244 molecules

[bugzilla-daemon at mcs.anl.gov]

http://bugzilla.mcs.anl.gov/swift/show_bug.cgi?id=72





------- Comment #12 from iraicu at cs.uchicago.edu  2007-07-01 10:49 -------
(In reply to comment #10)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > (In reply to comment #4)
> > > 
> > > There were two.
> > > 
> > I meant to say "issues"... from the discussion I had with Yong, I believe he
> > addressed both of them.
> 
> Ok. Got confused.
> 
> > > > We also fixed a badly handled exception we had [...]
> > > Can you be more specific? [...]
> > > 
> > Sure.  Double check file SubmissionThread.java, notice that the thread will
> > live as long as exit is not set...
> > Also, check the StatusThread.java, 
> 
> Right. Missed that.
> 
> > 
> > > > note that Swift was setting the set status of submitted tasks to the Falkon
> > > > provider in a separate thread,
> > > 
> > > Swift does not set status of tasks. That's what the provider is supposed to do.
> > > 
> > OK, there are several separate threads, one that sets the status of the task
> > for Swift, another that performs the submit, another that receives
> > notifications, etc.  The common data structure between the set status thread
> > and the submit thread is a queue; if the submission thread dies, the queue is
> > still valid, and the set status thread could still insert tasks into the queue
> > and set the status to submitted, although there would be no submission thread
> > alive to perform the submission itself to Falkon.
> 
> That sounds like the provider, not Swift. Maybe I misunderstood something?
> 

Right, the provider has multiple threads, and if any one of them exit
prematurely, then it cannot function correctly.  
Ioan


-- 
Configure bugmail: http://bugzilla.mcs.anl.gov/swift/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.