sqlrelay-discussion

[Sqlrelay-discussion] a couple of patches

[Renat S. <sr...@st...>]

Hello David and others!

I made a some of patches for sqlrelay and believe that you find them useful.

09_sessioncount_correction.patch - prevents sessioncount to go below zero

10_signal_handler_exit.patch - _exit() usage instead of exit() in signal 
handlers prevents double free on exit

11_status_more_info.patch - more status (totalconnections and 
sessioncount, semaphores)

12_scale_by_fork.patch - when scaler started with -fork option, it uses 
fork() instead of system() to open new connections. When connection 
died, scaler reap it with waitpid() and maintain connection counter by 
himself, so connection counter in shm does not affect scaler.

I made this patch because connection counter in shm always get corrupted 
after two or three days running sqlrelay under heavy load with periods 
of no load at all. I'll try to find out why this happen, but i believe 
that this patch will greatly increase the stability of sqlrelay with 
dynamic scaling.

-- 
Renat Sabitov   e-mail: sr...@st...
Stack Soft         jid: sr...@ja...

[Sqlrelay-discussion] a couple of patches

[Renat S. <sr...@st...>]

Hello David and others!

I made a some of patches for sqlrelay and believe that you find them useful.

09_sessioncount_correction.patch - prevents sessioncount to go below zero

10_signal_handler_exit.patch - _exit() usage instead of exit() in signal 
handlers prevents double free on exit

11_status_more_info.patch - more status (totalconnections and 
sessioncount, semaphores)

12_scale_by_fork.patch - when scaler started with -fork option, it uses 
fork() instead of system() to open new connections. When connection 
died, scaler reap it with waitpid() and maintain connection counter by 
himself, so connection counter in shm does not affect scaler.

I made this patch because connection counter in shm always get corrupted 
after two or three days running sqlrelay under heavy load with periods 
of no load at all. I'll try to find out why this happen, but i believe 
that this patch will greatly increase the stability of sqlrelay with 
dynamic scaling.

-- 
Renat Sabitov   e-mail: sr...@st...
Stack Soft         jid: sr...@ja...

Re: [Sqlrelay-discussion] a couple of patches - one more

[Renat S. <sr...@st...>]

14.05.2010 17:34, Renat Sabitov пишет:

> 09_sessioncount_correction.patch - prevents sessioncount to go below zero

Unfortunately this patch does not work properly. I found, that testing 
connectionsinuse and totalconnections to go below zero make no sense 
since they are unsigned and decremeting zero value produces UINT32_MAX.

But in other parts of program this values are cast to signed int, wich 
goes below zero because of overloading. So I made a patch which changed 
type of them to signed int.

I hope you'll find it useful.

-- 
Renat Sabitov   e-mail: sr...@st...
Stack Soft         jid: sr...@ja...

Re: [Sqlrelay-discussion] a couple of patches - one more

[Carlos V. <cve...@em...>]

It seems there have been a number of significant bug fixes & patches rollout for 0.41 that are critical for a stable production environment implementation.  Is there any chance of getting these all rolled together into a 0.42 release?

CJ Vergara

-----Original Message-----
From: Renat Sabitov [mailto:sr...@st...] 
Sent: Wednesday, May 19, 2010 4:58 AM
To: Discussion of topics related to SQL Relay; David Muse
Subject: [SPAM] - Re: [Sqlrelay-discussion] a couple of patches - one more - Email found in subject

14.05.2010 17:34, Renat Sabitov пишет:

> 09_sessioncount_correction.patch - prevents sessioncount to go below 
> zero

Unfortunately this patch does not work properly. I found, that testing connectionsinuse and totalconnections to go below zero make no sense since they are unsigned and decremeting zero value produces UINT32_MAX.

But in other parts of program this values are cast to signed int, wich goes below zero because of overloading. So I made a patch which changed type of them to signed int.

I hope you'll find it useful.

-- 
Renat Sabitov   e-mail: sr...@st...
Stack Soft         jid: sr...@ja...