Shutdown for rasqlinsert

[Carter Bullard]

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> 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] 
> Sent: Tuesday, June 11, 2013 10:14 AM
> To: David Edelman
> Cc: 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" <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 at qosient.com] 
> Sent: Monday, June 10, 2013 10:05 PM
> To: David Edelman
> Cc: 'Matt Brown'; 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/c9e1f0ce/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6837 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20130611/c9e1f0ce/attachment.bin>