rasqlinsert disconnect issues

[Carter Bullard]

In the earlier code we actually did a “use database” call after we established the
db connection.  new code doesn’t do that, we use the database reference
in each call to avoid the problem where we lose the connection and subsequent
mysql_real_query() calls, don’t  have the database reference.

If you have any other problems, don’t hesitate to email !!
Carter


> On Sep 28, 2014, at 11:36 AM, John T. Myers <myersj0 at gmail.com> wrote:
> 
> Carter,
> 
> It turned out we were running 3.0.6 version (even though we pulled from the 3.0.8 link a bit ago). Now that we re-compiled with 3.0.8 it appears to be fixed, was the below code changes what caused it? 
> 
> Something to do with not using my_bool originally?
> 
> 3.0.6:
> int retn = 0, x, reconnect = 1;
> mysql_options(RaMySQL, MYSQL_OPT_RECONNECT, &reconnect);
> 
> 3.0.8:
> my_bool reconnectbuf = 1, *reconnect = &reconnectbuf;
> mysql_options(RaMySQL, MYSQL_OPT_RECONNECT, reconnect);
> 
> On September 28, 2014 at 11:34:14 AM, Carter Bullard (carter at qosient.com <mailto:carter at qosient.com>) wrote:
> 
>> Well the earlier rasqlinsert.1 code does have a problem that the new one tried
>> to fix.  I’ll try to see what may be up with mysql_real_query() error messages,
>> and see if we missed something there.
>> 
>> But in the OP, the problem is that rasqlinsert.1 is running, but not updating
>> the database, in this second report, rasqlinsert.1 is failing ??
>> 
>> Carter
>> 
>> 
>> On Sep 25, 2014, at 8:11 PM, David Edelman <dedelman at iname.com <mailto:dedelman at iname.com>> wrote:
>> 
>>> Carter,
>>>  
>>> I am seeing something similar with Netflow data processed by Radium (labels added) and rasqlinsert reading the processed radium data from port 561. In my case the rasqlinsert process dies without any error messages (it is built with .debug and .devel) It isn’t practical for me to enable debuigger output since the failure can be many hours into the run.
>>>  
>>> The one clue that I do have it that the release candidate set (3.0.8-rc1) worked fine.
>>>  
>>> I haven’t had time to do much more than go back to the working release.
>>>  
>>> --Dave
>>>  
>>> From: argus-info-bounces+dedelman=iname.com at lists.andrew.cmu.edu <mailto:argus-info-bounces+dedelman=iname.com at lists.andrew.cmu.edu> [mailto:argus-info-bounces+dedelman=iname.com at lists.andrew.cmu.edu <mailto:argus-info-bounces+dedelman=iname.com at lists.andrew.cmu.edu>] On Behalf Of Carter Bullard
>>> Sent: Thursday, September 25, 2014 1:34 PM
>>> To: John T. Myers
>>> Cc: Argus
>>> Subject: Re: [ARGUS] rasqlinsert disconnect issues
>>>  
>>> Hey John,
>>> rasqlinsert() is multi-threaded, and its possible that
>>> the cache concurrency thread, the one that is managing the
>>> database cache, exited if the database fails.  
>>>  
>>> rasqlinsert() should close, if that thread is done.
>>>  
>>> So you are seeing rasqlinsert() is still running, but
>>> not updating the database ??  Is rasqlinsert() getting
>>> bigger ???  (should be generating INSERT and UPDATE 
>>> requests, but the DB thread is not processing them ???)
>>>  
>>> Carter
>>>  
>>>  
>>> On Sep 25, 2014, at 10:35 AM, John T. Myers <myersj0 at gmail.com <mailto:myersj0 at gmail.com>> wrote:
>>> 
>>> 
>>> Hello,
>>>  
>>> I was wondering if it’s normal behavior for rasqlinsert to cease inserting netflow into the database if the connection becomes interrupted? It seems if the mysql database is restarted or any part of the connection between rasqlinsert and the db is broken, it will not attempt to re-connect and continue flow insertion.
>>>  
>>> Thanks!
>>> John

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