Shutdown for rasqlinsert

[David Edelman]

It works :)

 

--Dave

 

From: Carter Bullard [mailto:carter at qosient.com] 
Sent: Tuesday, June 11, 2013 7:50 PM
To: David Edelman
Cc: argus-info at lists.andrew.cmu.edu
Subject: Re: Shutdown for rasqlinsert

 

Hey Dave,

Exactly the kind of info that I needed.

This simple patch will solve the problem.  I still need to go

through the closing logic to make sure all is OK, but this is works.

 

==== //depot/argus/clients/examples/ramysql/rasqlinsert.c#20 -
/Volumes/Users/carter/argus/clients/examples/ramysql/rasqlinsert.c ====

1305,1308c1305,1306

<          if (sig == SIGINT) {

<             ArgusShutDown(0);

<             exit(0);

<          }

---

>          ArgusShutDown(0);

>          exit(0);

 

I made some changes to the closing signal handler, and added

the standard set of terminating signals to call the handler, but

didn't update the test for which signals to exit on, after I finished

my testing.

 

This caused a child thread to fault with a semaphore locked.

Sorry about that !!!!!

 

Carter

 

 

On Jun 11, 2013, at 7:06 PM, "David Edelman" <dedelman at iname.com
<mailto:dedelman at iname.com> > wrote:





I set up a little test. I created a third instance of rasqlinsert that
updates a test table. I ran it in the foreground with -D 5. It hummed along
nicely and from a second window I kill -HUPed the PID. The debug output
seems to indicate that the process is stuck at RaResizeHandler(28)  That
message appeared twice about 15 seconds apart and no output since. The
process is still active as far as ps() can tell. I hit it with kill -9 and
like the Wicked Witch - now it's not only merely dead, it's really most
sincerely dead

 

Sounds like something is stuck.

 

--Dave

 

From: Carter Bullard [mailto:carter at qosient.com <http://qosient.com> ] 
Sent: Tuesday, June 11, 2013 10:14 AM
To: David Edelman
Cc: argus-info at lists.andrew.cmu.edu <mailto:argus-info at lists.andrew.cmu.edu>

Subject: Re: Shutdown for rasqlinsert

 

Hey Dave,

Always good questions.  Well, rasqlinsert() schedules writes to the
database,

for flows that it is tracking, and it can queue up a lot of operations,

depending on the load.  So when you stop rasqlinsert(), it will have to

commit the database inserts and updates that are in its scheduled queue, and

then it will have to flush any dirty flow caches that have not been
scheduled.

Depending on what its doing, it could be 100's, 1,000's, 10,000's of
database

operations that have to be done.

 

Assuming that its doing the right thing, it could take a while for
rasqlinsert()

to flush all its operations.  A -9 will just stop it in its tracks, so your

tables are going to be incomplete.  But, if your rasqlinsert() doesn't
finish,

I should look into termination, to make sure its not blocking on a
semaphore,

or one of the worker threads isn't exiting early.... can you describe the
load

and I can try to replicate, if you think there is a problem ?

 

Carter

 

 

On Jun 11, 2013, at 12:36 AM, "David Edelman" < <mailto:dedelman at iname.com>
dedelman at iname.com> wrote:






Carter,

 

Is it just me or does shutting down rasqlinsert always need a bit of cyber
violence. I can't seem to get kill(1) to stop the process even if I wait
patiently. The usual suspects like HUP bounce off harmlessly but -9 seems to
do the trick. Is there something that I am not understanding (other than the
full suite of things that I normally don't understand.) I've looked at the
signal handler and it seems to be doing quite a bit of work, how long should
I expect to wait for a clean -HUP ?

 

 

 

--Dave

 

 

From: Carter Bullard [mailto:carter@ <http://qosient.com/> qosient.com] 
Sent: Monday, June 10, 2013 10:05 PM
To: David Edelman
Cc: 'Matt Brown';  <mailto:argus-info at lists.andrew.cmu.edu>
argus-info at lists.andrew.cmu.edu
Subject: Re: [ARGUS] Rewrite of rastream

 

Hey Dave,

Ooooops, ...., lets try this version of rastream.c.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20130611/35072716/attachment.html>