sqlrelay-discussion Mailing List for SQL Relay (Page 8)
Brought to you by:
mused
Menu
▾
▴
sqlrelay-discussion — Discussion of topics related to SQL Relay
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
(20) |
Mar
(27) |
Apr
(17) |
May
(32) |
Jun
(45) |
Jul
(49) |
Aug
(68) |
Sep
(44) |
Oct
(29) |
Nov
(64) |
Dec
(25) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(61) |
Feb
(22) |
Mar
(25) |
Apr
(31) |
May
(18) |
Jun
(28) |
Jul
(19) |
Aug
(16) |
Sep
(8) |
Oct
(17) |
Nov
(32) |
Dec
(4) |
| 2007 |
Jan
(20) |
Feb
(25) |
Mar
(5) |
Apr
(12) |
May
(11) |
Jun
(18) |
Jul
(16) |
Aug
(22) |
Sep
(37) |
Oct
(20) |
Nov
(11) |
Dec
(2) |
| 2008 |
Jan
(11) |
Feb
(33) |
Mar
(12) |
Apr
(18) |
May
(22) |
Jun
(31) |
Jul
(23) |
Aug
(6) |
Sep
|
Oct
(10) |
Nov
(22) |
Dec
|
| 2009 |
Jan
(12) |
Feb
(8) |
Mar
(11) |
Apr
(20) |
May
(18) |
Jun
(7) |
Jul
(27) |
Aug
(2) |
Sep
(10) |
Oct
(5) |
Nov
(2) |
Dec
(1) |
| 2010 |
Jan
(11) |
Feb
(18) |
Mar
(10) |
Apr
(28) |
May
(28) |
Jun
|
Jul
(27) |
Aug
(9) |
Sep
(21) |
Oct
(2) |
Nov
(2) |
Dec
(11) |
| 2011 |
Jan
|
Feb
(2) |
Mar
(4) |
Apr
(2) |
May
(2) |
Jun
(44) |
Jul
(9) |
Aug
(2) |
Sep
(12) |
Oct
(7) |
Nov
(11) |
Dec
(7) |
| 2012 |
Jan
(5) |
Feb
|
Mar
(9) |
Apr
(9) |
May
(12) |
Jun
|
Jul
(13) |
Aug
(3) |
Sep
(3) |
Oct
(1) |
Nov
(1) |
Dec
(10) |
| 2013 |
Jan
(21) |
Feb
(3) |
Mar
(4) |
Apr
|
May
(3) |
Jun
(2) |
Jul
(3) |
Aug
(3) |
Sep
(3) |
Oct
|
Nov
|
Dec
(4) |
| 2014 |
Jan
(7) |
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
|
Jul
(4) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Andrew L <akl...@ya...> - 2011-07-29 03:41:57
|
Hi,
I'm using rudiments-0.32 and sqlrelay-0.39.4 .
I have the following Perl code:
1 ....
2 $stmt = 'begin :cursor := my_func; end;';
3 $curs->prepareQuery ($stmt);
4 $curs->defineOutputBindCursor("cursor");
5 $curs->executeQuery() || die "Can't retrieve data from database: " . $curs->errorMessage();
7 ....
The script dies at line 5 with "Can't retrieve data from database: Too many listeners" error message.
Here's what I have in my sqlrelay.conf file:
<instance id="my_id" port="9000" dbase="oracle8"
connections="5" maxconnections="30" maxqueuelength="5"
growby="1" ttl="600" endofsession="rollback" sessiontimeout="600"
runasuser="spock" runasgroup="vulcan" cursors="10"
authtier="listener" handoff="pass" deniedips="" allowedips=""
debug="listener_and_connection" maxquerysize="65536" maxstringbindvaluelength="4000"
maxlobbindvaluelength="71680" idleclienttimeout="5"
maxlisteners="10" listenertimeout="0"
reloginatstart="false">
What settings do i need to change to fix the error?
Thanks
--Andrew |
|
From: Andrew L <akl...@ya...> - 2011-07-28 22:17:34
|
additional info... After seeing: Debugging to: /my/path/to/SQLRELAY/var/sqlrelay/debug/sqlr-listener.24999 I took a look at /my/path/to/SQLRELAY/var/sqlrelay/debug/sqlr-listener.24999 but saw no errors: 07/28/2011 14:06:28 PDT listener [24999] : getting authentication... 07/28/2011 14:06:28 PDT listener [24999] : listener-based authentication succeeded 07/28/2011 14:06:28 PDT listener [24999] : incrementing session count... 07/28/2011 14:06:28 PDT listener [24999] : waiting for exclusive access... 07/28/2011 14:06:28 PDT listener [24999] : done waiting for exclusive access... 1 07/28/2011 14:06:28 PDT listener [24999] : waiting for the scaler... 07/28/2011 14:06:28 PDT listener [24999] : done waiting for the scaler... 07/28/2011 14:06:28 PDT listener [24999] : done incrementing session count 07/28/2011 14:06:28 PDT listener [24999] : getting a connection... 07/28/2011 14:06:28 PDT listener [24999] : acquiring exclusive shm access 07/28/2011 14:06:28 PDT listener [24999] : done acquiring exclusive shm access 07/28/2011 14:06:28 PDT listener [24999] : waiting for an available connection 07/28/2011 14:06:28 PDT listener [24999] : done waiting for an available connection 07/28/2011 14:06:28 PDT listener [24999] : handoff=pass 07/28/2011 14:06:28 PDT listener [24999] : signalling connection that we've read 07/28/2011 14:06:28 PDT listener [24999] : done signalling connection that we've read 07/28/2011 14:06:28 PDT listener [24999] : releasing exclusive shm access 07/28/2011 14:06:28 PDT listener [24999] : done releasing exclusive shm access 07/28/2011 14:06:28 PDT listener [24999] : done getting a connection 07/28/2011 14:06:28 PDT listener [24999] : passing descriptor... 07/28/2011 14:06:28 PDT listener [24999] : done passing descriptor 07/28/2011 14:06:28 PDT listener [24999] : decrementing busy listeners 07/28/2011 14:06:28 PDT listener [24999] : done decrementing busy listeners ________________________________ From: Andrew L <akl...@ya...> To: "sql...@li..." <sql...@li...> Sent: Thursday, July 28, 2011 2:47 PM Subject: [Sqlrelay-discussion] Cannot fetch from bind cursor.... hi I just installed sqlrelay-0.42 and rudiments-0.33 on my Linux system and ran: $SQLRELAYHOME/bin/sqlr-start -id ire -config $SQLRELAYHOME/etc/sqlrelay.conf Everything starts up successfully: Starting listener: sqlr-listener -id ire -config /my/path/to/SQLRELAY/etc/sqlrelay.conf -debug Debugging to: /my/path/to/SQLRELAY/var/sqlrelay/debug/sqlr-listener.30342 Starting 1 connections to ire : sqlr-connection-oracle8 -id ire -connectionid ire -config /my/path/to/SQLRELAY/etc/sqlrelay.conf -debug Debugging to: /my/path/to/SQLRELAY/var/sqlrelay/debug/sqlr-connection.30346 Starting scaler: sqlr-scaler -id ire -debug -config /my/path/to/SQLRELAY/etc/sqlrelay.conf Starting cache manager: sqlr-cachemanager Warning: using default id. Thanks to MP3.com for sponsoring: Clustered/Replicated database support. Perl API. Thanks to FeedLounge for sponsoring: Query routing and filtering. However, when I try to run the following Perl code: 1 ..... 2 $stmt = 'begin :cursor := my_function; end;'; 3 $curs->prepareQuery ($stmt); 4 $curs->defineOutputBindCursor("cursor"); 5 $curs->executeQuery() || 6 die "Can't retrieve data from database: " . $curs->errorMessage(); 7 my $bindcur=$curs->getOutputBindCursor("cursor") || die "getOutputBindCursor() failed: " . $curs->errorMessage(); 8 $bindcur->fetchFromBindCursor() || die "Can't fetch from bind cursor: " . $bindcur->errorMessage(); 9 ..... my Perl script dies while trying to invoke fetchFromBindCursor at line 8. The window where I ran sqlr-start command immediately shows: Debugging to: /my/path/to/SQLRELAY/var/sqlrelay/debug/sqlr-listener.24999 (pid=24781) Abnormal termination: signal 11 received Couldn't open debug file: (null) Couldn't open debug file: (null) Couldn't open debug file: (null) Couldn't open debug file: (null) Couldn't open debug file: (null) Couldn't open debug file: (null) Couldn't open debug file: (null) Couldn't open debug file: (null) I could NOT find sqlr-listener.24781 or sqlr-connection.24781 in the /my/path/to/SQLRELAY/var/sqlrelay/debug directory. Also, the output from the "ps" does not show the sqlr-connection-oracle8 process. It looks like sqlr-connection-oracle8 died when 'Abnormal termination: signal 11 received' message appeared. Is this a known issue and how do I resolve the problem? My Perl script runs without any problems when I use rudiments-0.32 and sqlrelay-0.39.4 version. Thanks --Andrew ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey _______________________________________________ Sqlrelay-discussion mailing list Sql...@li... https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion |
|
From: Andrew L <akl...@ya...> - 2011-07-28 21:48:03
|
hi I just installed sqlrelay-0.42 and rudiments-0.33 on my Linux system and ran: $SQLRELAYHOME/bin/sqlr-start -id ire -config $SQLRELAYHOME/etc/sqlrelay.conf Everything starts up successfully: Starting listener: sqlr-listener -id ire -config /my/path/to/SQLRELAY/etc/sqlrelay.conf -debug Debugging to: /my/path/to/SQLRELAY/var/sqlrelay/debug/sqlr-listener.30342 Starting 1 connections to ire : sqlr-connection-oracle8 -id ire -connectionid ire -config /my/path/to/SQLRELAY/etc/sqlrelay.conf -debug Debugging to: /my/path/to/SQLRELAY/var/sqlrelay/debug/sqlr-connection.30346 Starting scaler: sqlr-scaler -id ire -debug -config /my/path/to/SQLRELAY/etc/sqlrelay.conf Starting cache manager: sqlr-cachemanager Warning: using default id. Thanks to MP3.com for sponsoring: Clustered/Replicated database support. Perl API. Thanks to FeedLounge for sponsoring: Query routing and filtering. However, when I try to run the following Perl code: 1 ..... 2 $stmt = 'begin :cursor := my_function; end;'; 3 $curs->prepareQuery ($stmt); 4 $curs->defineOutputBindCursor("cursor"); 5 $curs->executeQuery() || 6 die "Can't retrieve data from database: " . $curs->errorMessage(); 7 my $bindcur=$curs->getOutputBindCursor("cursor") || die "getOutputBindCursor() failed: " . $curs->errorMessage(); 8 $bindcur->fetchFromBindCursor() || die "Can't fetch from bind cursor: " . $bindcur->errorMessage(); 9 ..... my Perl script dies while trying to invoke fetchFromBindCursor at line 8. The window where I ran sqlr-start command immediately shows: Debugging to: /my/path/to/SQLRELAY/var/sqlrelay/debug/sqlr-listener.24999 (pid=24781) Abnormal termination: signal 11 received Couldn't open debug file: (null) Couldn't open debug file: (null) Couldn't open debug file: (null) Couldn't open debug file: (null) Couldn't open debug file: (null) Couldn't open debug file: (null) Couldn't open debug file: (null) Couldn't open debug file: (null) I could NOT find sqlr-listener.24781 or sqlr-connection.24781 in the /my/path/to/SQLRELAY/var/sqlrelay/debug directory. Also, the output from the "ps" does not show the sqlr-connection-oracle8 process. It looks like sqlr-connection-oracle8 died when 'Abnormal termination: signal 11 received' message appeared. Is this a known issue and how do I resolve the problem? My Perl script runs without any problems when I use rudiments-0.32 and sqlrelay-0.39.4 version. Thanks --Andrew |
|
From: Andy C. <ac...@ii...> - 2011-07-14 00:17:04
|
Thanks, David! You're right, of course. I had build-related errors that
I had not noticed. Now, I've gotten a bit farther: I've downloaded,
built, and installed Rudiments, Python, and SQL Relay, and created
sqlrelay.conf, following the example. When I attempt to run "sqlr-start
-id postgresqltest", however, I get this error:
sh: sqlr-connection-postgresql: command not found
What am I missing this time? When I ran "configure", I used the
"--enable-postgresql" and "--with-postgresql-prefix" flags.
Thanks for your continuing help,
Andy
On 7/12/2011 6:48 AM, David Muse wrote:
> Hello Andy,
>
> After building SQL Relay, you should see the file under the
> src/start/.libs directory and after installing, you should see it in
> /usr/local/firstworks/bin.
>
> It's possible that the build failed early and it never got created.
>
> If you're still having trouble, please send me the output of the
> configure and make and I'll look through it. From that, it should be
> possible to figure out what happened.
>
> David Muse
> dav...@fi...
>
> On 07/06/2011 06:03 PM, Andy Cohen wrote:
>> Hi! I'm an absolute newcomer to SQL Relay. I've followed the
>> directions to build and install both Rudiments and SQL Relay, and
>> that seems to have run successfully. Now, I'd like to run
>> "sqlr-start", as described on this page:
>>
>> http://sqlrelay.sourceforge.net/sqlrelay/running.html
>>
>> Unfortunately, I can't find the "sqlr-start" program, either in
>> /usr/local/firstworks or my own "sqlrelay-0.42" directory, where I
>> ran the build and install.
>>
>> Can anyone tell me where to find that program? I'm sure I'm just
>> missing something that's right in front of my face - it wouldn't be
>> the first time.
>>
>> Thanks for any help,
>>
>> Andy
>>
>>
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>>
>>
>> _______________________________________________
>> Sqlrelay-discussion mailing list
>> Sql...@li...
>> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion
>
> _______________________________________________________
> Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting
> http://www.doteasy.com
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
>
>
> _______________________________________________
> Sqlrelay-discussion mailing list
> Sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion
|
|
From: David M. <dav...@fi...> - 2011-07-12 13:48:36
|
Hello Andy, After building SQL Relay, you should see the file under the src/start/.libs directory and after installing, you should see it in /usr/local/firstworks/bin. It's possible that the build failed early and it never got created. If you're still having trouble, please send me the output of the configure and make and I'll look through it. From that, it should be possible to figure out what happened. David Muse dav...@fi... On 07/06/2011 06:03 PM, Andy Cohen wrote: > Hi! I'm an absolute newcomer to SQL Relay. I've followed the > directions to build and install both Rudiments and SQL Relay, and that > seems to have run successfully. Now, I'd like to run "sqlr-start", as > described on this page: > > http://sqlrelay.sourceforge.net/sqlrelay/running.html > > Unfortunately, I can't find the "sqlr-start" program, either in > /usr/local/firstworks or my own "sqlrelay-0.42" directory, where I ran > the build and install. > > Can anyone tell me where to find that program? I'm sure I'm just > missing something that's right in front of my face - it wouldn't be > the first time. > > Thanks for any help, > > Andy > > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > > > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion _______________________________________________________ Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting http://www.doteasy.com |
|
From: Andy C. <ac...@ii...> - 2011-07-06 22:19:14
|
Hi! I'm an absolute newcomer to SQL Relay. I've followed the directions
to build and install both Rudiments and SQL Relay, and that seems to
have run successfully. Now, I'd like to run "sqlr-start", as described
on this page:
http://sqlrelay.sourceforge.net/sqlrelay/running.html
Unfortunately, I can't find the "sqlr-start" program, either in
/usr/local/firstworks or my own "sqlrelay-0.42" directory, where I ran
the build and install.
Can anyone tell me where to find that program? I'm sure I'm just missing
something that's right in front of my face - it wouldn't be the first time.
Thanks for any help,
Andy
|
|
From: Stephen B. <st...@ca...> - 2011-07-01 15:17:42
|
David, All, I am a user who is very dependent on SQL Relay and I just want to give a *HUGE* Thank you to everyone who has been working with David and testing and submitting code/patches and ideas. SQL Relay has saved me a lot of heartache and I am excited to see the project continue to grow and the developer interest. Respectfully, Stephen Barclay On 6/30/2011 12:55 PM, David Muse wrote: > Hello all, > > SQL Relay 0.42 is out (finally). This is mainly a bug-fix, stability > and compatibility release. > > Highlights include: > * Java api should work on 64-bit machines now > * Updated configure script to detect modern versions of db's and languages > * Oracle CLOB fixes > * Oracle cursor bind fixes > * A fix for the bug that caused address="" in the config file to prevent > the listener from starting. > * The maxsessioncount parameter defaults to 0 (disabled) now. > * Many, many fixes for obscure bugs, race conditions, memory leaks and > other stability-related issues > > Thanks to everyone who contacted me about issues or submitted patches > that went into this release. There were quite a few. Big thanks go out > to Renat Sabitov for submitting a dozen or more patches and doing lots > of testing. > > A new release of rudiments, which SQL Relay depends on is out too. A > bunch of bugs were fixed in it as well, some of which were the ultimate > cause of some SQL Relay bugs. > > Grab them both at http://sqlrelay.sourceforge.net and > http://rudiments.sourceforge.net > > As always, report any issues you run into. > > David Muse > dav...@fi... > > > The complete changelog for this release follows: > > 0.42 - fixed a bug causing cursor id's not to get set for some db's > updated configure script to look for client64 in addition to client > for oracle intantclient on x86_64 > added setTimeout to all API's > applied some patches from Alexey Leontev > bumped BINDVARLENGTH up to 64 > applied Renat Sabitov's scaler -debug patch and 11g configure patch > applied Stephan van Egmond's sqlrsh history patch > added configure test for gmake, use it to find ruby.h > applied mi...@ta...'s scaler patch for -debug > added getting started notes for Oracle 11.2 on Fedora Core 12 > added test for mdb_sql_run_query and code to use it if it's there > fixed a bug that caused ping to fail after reconnecting to sybase > added configure test for xsubpp > fixed perl dbi inout bind problem > fixed code that was adding a NULL terminator to oracle clob values > applied several patches from Renat Sabitov > applied dynamic cursor patch from Cal Heldenbrand > applied Claudio Freire's normalized matching and xmlparsing patches > fixed sqlite connection to use sqlite3_malloc/free > update freetds connection to get tds version with ct_config if > TDS_VERSION_NO doesn't exist > applied a fix for a bug that could cause a crash when a cursor is > reused > fixed a shutdown race condition in connection daemons > moved common startup/shutdown code for connection daemons up into > static methods/variables of the sqlrconnection_svr class > fixed a crash in the oracle connection daemon where OCIHandleFree > was getting called on define handles that weren't created by > OCIHandleAlloc > removed rebuild target from Makefiles > updated tests > refactored main() method for connections > added searches for ruby1.8, ruby19 and ruby1.9 in configure script > fixed a bug that caused addresses="" to cause the sqlr-listener not to > start > added entries to FAQ about oracle instantclient and ubunu /bin/dash > updated postgresql tests to use bpchar rather than char(20) for > fetching results of stored procedure > renamed interbase.create.sh to firebird.create.sh > fixed a bug that could overrun the postgresql bind array > fixed bug that caused connection daemon sockets to be double-freed on > shutdown after a suspended session > precision/scale in output bind buffers is initialized now > debugstring buffers are no longer build when debug is turned off > fixed id vs. index bug when requesting a cursor and binding a cursor > refactored JNI code a bit, fixed getIntField/getLongField problem that > caused problems on 64-bit machines > applied patch to make python api return decimals and integers, not > just strings, refactored some of it > fixed dump tran docs in getting started with sybase to use sa > updated sybase connection to use length of cursor name rather than > CS_NULLTERM to work around an odd, inconsistent bug that would > cause the connection to hang sometimes > connections not spawned by scaler don't signal on the semaphore used > by the scaler to wait for a connection to start now > updated bind var docs > updated faq > fixed a bug where binding an oracle cursor didn't reset some values > and would cause subsequent cursor binds to fail > added note to docs about configuring sybase to dump transactions at > each checkpoint > applied Renat Sabitov's patch to kill scaler-started connections which > fail to signal on sem(8) because they either crashed or got > hung up trying to start > fixed a bug in the mysql drop-in lib that could cause the client to > run out of cursors > added a mapping between sqlite3_free and sqlite_freemem > added a fix for a race condition in the scaler > fixed a postgresql bind memory leak > applied Renat's ruby DESTDIR patch and updated helper scripts to > remove $(DESTDIR) from all the variables that it outputs > applied Renat's patch to handle semaphore failures in forked listeners > during shutdown > applied Renat's patch to move connection counting for scaler-spawned > connections entirely into scaler itself > applied Renat's patch to reap children more regularly and refactored > it a little > fixed distclean to remove perl .pm files > changed maxsessioncount default to 0, updated docs, examples > > > _______________________________________________________ > Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting > http://www.doteasy.com > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion |
|
From: Renat S. <sr...@st...> - 2011-07-01 14:20:27
|
> SQL Relay 0.42 is out (finally). This is mainly a bug-fix, stability > and compatibility release. Thank you, David! It is nice to work with you. -- Renat Sabitov e-mail: sr...@st... Stack Soft jid: sr...@ja... |
|
From: David M. <dav...@fi...> - 2011-06-30 17:55:23
|
Hello all, SQL Relay 0.42 is out (finally). This is mainly a bug-fix, stability and compatibility release. Highlights include: * Java api should work on 64-bit machines now * Updated configure script to detect modern versions of db's and languages * Oracle CLOB fixes * Oracle cursor bind fixes * A fix for the bug that caused address="" in the config file to prevent the listener from starting. * The maxsessioncount parameter defaults to 0 (disabled) now. * Many, many fixes for obscure bugs, race conditions, memory leaks and other stability-related issues Thanks to everyone who contacted me about issues or submitted patches that went into this release. There were quite a few. Big thanks go out to Renat Sabitov for submitting a dozen or more patches and doing lots of testing. A new release of rudiments, which SQL Relay depends on is out too. A bunch of bugs were fixed in it as well, some of which were the ultimate cause of some SQL Relay bugs. Grab them both at http://sqlrelay.sourceforge.net and http://rudiments.sourceforge.net As always, report any issues you run into. David Muse dav...@fi... The complete changelog for this release follows: 0.42 - fixed a bug causing cursor id's not to get set for some db's updated configure script to look for client64 in addition to client for oracle intantclient on x86_64 added setTimeout to all API's applied some patches from Alexey Leontev bumped BINDVARLENGTH up to 64 applied Renat Sabitov's scaler -debug patch and 11g configure patch applied Stephan van Egmond's sqlrsh history patch added configure test for gmake, use it to find ruby.h applied mi...@ta...'s scaler patch for -debug added getting started notes for Oracle 11.2 on Fedora Core 12 added test for mdb_sql_run_query and code to use it if it's there fixed a bug that caused ping to fail after reconnecting to sybase added configure test for xsubpp fixed perl dbi inout bind problem fixed code that was adding a NULL terminator to oracle clob values applied several patches from Renat Sabitov applied dynamic cursor patch from Cal Heldenbrand applied Claudio Freire's normalized matching and xmlparsing patches fixed sqlite connection to use sqlite3_malloc/free update freetds connection to get tds version with ct_config if TDS_VERSION_NO doesn't exist applied a fix for a bug that could cause a crash when a cursor is reused fixed a shutdown race condition in connection daemons moved common startup/shutdown code for connection daemons up into static methods/variables of the sqlrconnection_svr class fixed a crash in the oracle connection daemon where OCIHandleFree was getting called on define handles that weren't created by OCIHandleAlloc removed rebuild target from Makefiles updated tests refactored main() method for connections added searches for ruby1.8, ruby19 and ruby1.9 in configure script fixed a bug that caused addresses="" to cause the sqlr-listener not to start added entries to FAQ about oracle instantclient and ubunu /bin/dash updated postgresql tests to use bpchar rather than char(20) for fetching results of stored procedure renamed interbase.create.sh to firebird.create.sh fixed a bug that could overrun the postgresql bind array fixed bug that caused connection daemon sockets to be double-freed on shutdown after a suspended session precision/scale in output bind buffers is initialized now debugstring buffers are no longer build when debug is turned off fixed id vs. index bug when requesting a cursor and binding a cursor refactored JNI code a bit, fixed getIntField/getLongField problem that caused problems on 64-bit machines applied patch to make python api return decimals and integers, not just strings, refactored some of it fixed dump tran docs in getting started with sybase to use sa updated sybase connection to use length of cursor name rather than CS_NULLTERM to work around an odd, inconsistent bug that would cause the connection to hang sometimes connections not spawned by scaler don't signal on the semaphore used by the scaler to wait for a connection to start now updated bind var docs updated faq fixed a bug where binding an oracle cursor didn't reset some values and would cause subsequent cursor binds to fail added note to docs about configuring sybase to dump transactions at each checkpoint applied Renat Sabitov's patch to kill scaler-started connections which fail to signal on sem(8) because they either crashed or got hung up trying to start fixed a bug in the mysql drop-in lib that could cause the client to run out of cursors added a mapping between sqlite3_free and sqlite_freemem added a fix for a race condition in the scaler fixed a postgresql bind memory leak applied Renat's ruby DESTDIR patch and updated helper scripts to remove $(DESTDIR) from all the variables that it outputs applied Renat's patch to handle semaphore failures in forked listeners during shutdown applied Renat's patch to move connection counting for scaler-spawned connections entirely into scaler itself applied Renat's patch to reap children more regularly and refactored it a little fixed distclean to remove perl .pm files changed maxsessioncount default to 0, updated docs, examples _______________________________________________________ Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting http://www.doteasy.com |
|
From: David M. <dav...@fi...> - 2011-06-30 16:07:59
|
Ok, I updated it.
I'm going to start making the release now. Let me know if you see any
last minute issues.
Dave
On 06/30/2011 03:49 AM, Renat Sabitov wrote:
> 23.06.2011 07:32, David Muse пишет:
>> Nevermind patching against current CVS, I got it figured out :)
> Just a little correction
> scaler.C, 518
>
> // try 3 times - in the first use SIGTERM and on the next 2 use SIGKILL
>
> Should be as follows:
>
> // try 3 times - in the first check whever it is already dead, then use
> SIGTERM and at last use SIGKILL
>
_______________________________________________________
Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting
http://www.doteasy.com
|
|
From: Renat S. <sr...@st...> - 2011-06-30 07:49:18
|
23.06.2011 07:32, David Muse пишет: > Nevermind patching against current CVS, I got it figured out :) Just a little correction scaler.C, 518 // try 3 times - in the first use SIGTERM and on the next 2 use SIGKILL Should be as follows: // try 3 times - in the first check whever it is already dead, then use SIGTERM and at last use SIGKILL -- Renat Sabitov e-mail: sr...@st... Stack Soft jid: sr...@ja... |
|
From: David M. <dav...@fi...> - 2011-06-29 17:59:02
|
Yeah, that is tricky. Let's wait and do something like that for the next release. On 06/29/2011 01:55 PM, Renat Sabitov wrote: > On 29.06.2011 21:25, David Muse wrote: >> Renat, >> >> This will definitely improve things, but maybe we should just make >> the scaler call reapChildren when it receives a SIGCHLD. Can you >> think of any reason why we shouldn't do that? > > The problem is with signal handler rules. It could set only one type > of static variable - sig_atomic_t. So I think it is possible to count > reaped children in signal handler in variable n_reaped and then (since > semset->wait(6) would exit and set EINTR) in the main code block > SIGCHLD, change shm and set n_reaped to 0 . A little bit tricky, but > should work. > > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > > _______________________________________________________ > Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting > http://www.doteasy.com > > > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > _______________________________________________________ > Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting > http://www.doteasy.com _______________________________________________________ Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting http://www.doteasy.com |
|
From: Renat S. <sr...@st...> - 2011-06-29 17:55:25
|
On 29.06.2011 21:25, David Muse wrote: > Renat, > > This will definitely improve things, but maybe we should just make the > scaler call reapChildren when it receives a SIGCHLD. Can you think of > any reason why we shouldn't do that? The problem is with signal handler rules. It could set only one type of static variable - sig_atomic_t. So I think it is possible to count reaped children in signal handler in variable n_reaped and then (since semset->wait(6) would exit and set EINTR) in the main code block SIGCHLD, change shm and set n_reaped to 0 . A little bit tricky, but should work. |
|
From: David M. <dav...@fi...> - 2011-06-29 17:27:25
|
Actually, it would be a little tricky to code because it would need to be a static method accessing members of an instance of scaler, but other than that? On 06/29/2011 01:25 PM, David Muse wrote: > Renat, > > This will definitely improve things, but maybe we should just make the > scaler call reapChildren when it receives a SIGCHLD. Can you think of > any reason why we shouldn't do that? > > Dave > > On 06/29/2011 11:34 AM, Renat Sabitov wrote: >> Hi David, >> >> Did you mention that zombie connections hanging around when scaler >> does not receive signal(6) for some time? I made a patch that use >> timed wait() on sem(6) and reap dead children every 5 seconds. >> >> This patch solve one more issue. Did you know that undo information >> on semaphore operations processed after process completely dies, i.e. >> after the father executes waitpid(). For this reason it is very >> important to reap children in time. >> >> >> ------------------------------------------------------------------------------ >> All of the data generated in your IT infrastructure is seriously valuable. >> Why? It contains a definitive record of application performance, security >> threats, fraudulent activity, and more. Splunk takes this data and makes >> sense of it. IT sense. And common sense. >> http://p.sf.net/sfu/splunk-d2d-c2 >> >> _______________________________________________________ >> Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting >> http://www.doteasy.com >> >> >> _______________________________________________ >> Sqlrelay-discussion mailing list >> Sql...@li... >> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion >> >> >> _______________________________________________________ >> Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting >> http://www.doteasy.com > _______________________________________________________ Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting http://www.doteasy.com |
|
From: David M. <dav...@fi...> - 2011-06-29 17:26:01
|
Renat, This will definitely improve things, but maybe we should just make the scaler call reapChildren when it receives a SIGCHLD. Can you think of any reason why we shouldn't do that? Dave On 06/29/2011 11:34 AM, Renat Sabitov wrote: > Hi David, > > Did you mention that zombie connections hanging around when scaler > does not receive signal(6) for some time? I made a patch that use > timed wait() on sem(6) and reap dead children every 5 seconds. > > This patch solve one more issue. Did you know that undo information on > semaphore operations processed after process completely dies, i.e. > after the father executes waitpid(). For this reason it is very > important to reap children in time. > > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > > _______________________________________________________ > Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting > http://www.doteasy.com > > > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > _______________________________________________________ > Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting > http://www.doteasy.com _______________________________________________________ Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting http://www.doteasy.com |
|
From: David M. <dav...@fi...> - 2011-06-29 17:18:58
|
Actually, now that I look at it, the only other semaphore that could be a problem is 8, and I already did the same thing in the scaler to reset that one. Yay! On 06/29/2011 01:14 PM, David Muse wrote: > Yeah, this is definitely an issue. I wonder if the same issue exists > with other semaphores, depending on exactly where sqlr-connection exits. > > I think it would be ok just to reset the semaphore to 0 though, no > need to check its value first. > > On 06/29/2011 10:17 AM, Renat Sabitov wrote: >> Hi David, >> >> I am continue testing and generating ideas :) >> >> If sqlr-connection is killed between signalListenerToRead() and >> waitForListenerToFinishReading(), sem(3) starts growing above one. >> This consequently breaks listener-connection communication and leads >> to hanging listener processes under high load. >> >> The patch changes wait points for sem(3) and sem(2) so the values of >> this semaphores is set to 0 after wait() completed. Since we can not >> use "WithUndo" on inter-process communication semaphores, I suppose >> it is a good idea in general to check the state and revert it to normal. >> >> >> ------------------------------------------------------------------------------ >> All of the data generated in your IT infrastructure is seriously valuable. >> Why? It contains a definitive record of application performance, security >> threats, fraudulent activity, and more. Splunk takes this data and makes >> sense of it. IT sense. And common sense. >> http://p.sf.net/sfu/splunk-d2d-c2 >> >> _______________________________________________________ >> Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting >> http://www.doteasy.com >> >> >> _______________________________________________ >> Sqlrelay-discussion mailing list >> Sql...@li... >> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion >> >> >> _______________________________________________________ >> Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting >> http://www.doteasy.com > _______________________________________________________ Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting http://www.doteasy.com |
|
From: David M. <dav...@fi...> - 2011-06-29 17:14:46
|
Yeah, this is definitely an issue. I wonder if the same issue exists with other semaphores, depending on exactly where sqlr-connection exits. I think it would be ok just to reset the semaphore to 0 though, no need to check its value first. On 06/29/2011 10:17 AM, Renat Sabitov wrote: > Hi David, > > I am continue testing and generating ideas :) > > If sqlr-connection is killed between signalListenerToRead() and > waitForListenerToFinishReading(), sem(3) starts growing above one. > This consequently breaks listener-connection communication and leads > to hanging listener processes under high load. > > The patch changes wait points for sem(3) and sem(2) so the values of > this semaphores is set to 0 after wait() completed. Since we can not > use "WithUndo" on inter-process communication semaphores, I suppose it > is a good idea in general to check the state and revert it to normal. > > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > > _______________________________________________________ > Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting > http://www.doteasy.com > > > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > _______________________________________________________ > Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting > http://www.doteasy.com _______________________________________________________ Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting http://www.doteasy.com |
|
From: Renat S. <sr...@st...> - 2011-06-29 15:34:17
|
Hi David, Did you mention that zombie connections hanging around when scaler does not receive signal(6) for some time? I made a patch that use timed wait() on sem(6) and reap dead children every 5 seconds. This patch solve one more issue. Did you know that undo information on semaphore operations processed after process completely dies, i.e. after the father executes waitpid(). For this reason it is very important to reap children in time. -- Renat Sabitov e-mail: sr...@st... Stack Soft jid: sr...@ja... |
|
From: Renat S. <sr...@st...> - 2011-06-29 14:18:08
|
Hi David, I am continue testing and generating ideas :) If sqlr-connection is killed between signalListenerToRead() and waitForListenerToFinishReading(), sem(3) starts growing above one. This consequently breaks listener-connection communication and leads to hanging listener processes under high load. The patch changes wait points for sem(3) and sem(2) so the values of this semaphores is set to 0 after wait() completed. Since we can not use "WithUndo" on inter-process communication semaphores, I suppose it is a good idea in general to check the state and revert it to normal. -- Renat Sabitov e-mail: sr...@st... Stack Soft jid: sr...@ja... |
|
From: Renat S. <sr...@st...> - 2011-06-29 03:00:45
|
On 29.06.2011 06:41, David Muse wrote: > Ahh, I remember this now. Ok, sounds good. I'll apply the patch. Let > me know if there's anything else you want to get into this release. > I've done a bunch of testing here, but my tests didn't reveal the > problems you found yesterday, so there might be other issues that I'm > not aware of. > > Thanks, David. I'll test the current CVS version today and will write back if there would be any problems. |
|
From: David M. <dav...@fi...> - 2011-06-29 02:41:38
|
Ahh, I remember this now. Ok, sounds good. I'll apply the patch. Let me know if there's anything else you want to get into this release. I've done a bunch of testing here, but my tests didn't reveal the problems you found yesterday, so there might be other issues that I'm not aware of. Dave On 06/28/2011 10:35 PM, Renat Sabitov wrote: > On 29.06.2011 01:00, David Muse wrote: >> Wouldn't it be better if the sqlr-connection processes increment and >> decrement the value in the shm in all cases, and the scaler just reads >> the value from the shm? The code would be simpler. >> > It was done this way before the "fork" patch and cause counter to > dispair with reality when sqlr-connection dies with SIGSEGV, for > example. I saw situations when scaler would not start new connection > because it would think that many connections were already started but > there were none. >> The only issue I could see with that is if the sqlr-connections are >> killed with a SIGKILL, then they would fail to decrement the counter, >> though I think the same thing would happen if the scaler were >> incrementing and decrementing the counter. If you kill a process with >> SIGKILL, does it create a zombie until the parent waits on it? > If scaler would be responsible for the counter, it would increment after > fork and decrement in reapChildren in all and every cases. It would be > more stable scaling system. > > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > _______________________________________________________ > Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting > http://www.doteasy.com _______________________________________________________ Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting http://www.doteasy.com |
|
From: Renat S. <sr...@st...> - 2011-06-29 02:36:00
|
On 29.06.2011 01:00, David Muse wrote: > Wouldn't it be better if the sqlr-connection processes increment and > decrement the value in the shm in all cases, and the scaler just reads > the value from the shm? The code would be simpler. > It was done this way before the "fork" patch and cause counter to dispair with reality when sqlr-connection dies with SIGSEGV, for example. I saw situations when scaler would not start new connection because it would think that many connections were already started but there were none. > The only issue I could see with that is if the sqlr-connections are > killed with a SIGKILL, then they would fail to decrement the counter, > though I think the same thing would happen if the scaler were > incrementing and decrementing the counter. If you kill a process with > SIGKILL, does it create a zombie until the parent waits on it? If scaler would be responsible for the counter, it would increment after fork and decrement in reapChildren in all and every cases. It would be more stable scaling system. |
|
From: David M. <dav...@fi...> - 2011-06-28 21:01:03
|
Yeah, I noticed that there could potentially be an issue with that, but the fix looked fairly invasive and I didn't want to mess anything up at the last minute before the release. Looking at it now though, we probably should fix it. Wouldn't it be better if the sqlr-connection processes increment and decrement the value in the shm in all cases, and the scaler just reads the value from the shm? The code would be simpler. The only issue I could see with that is if the sqlr-connections are killed with a SIGKILL, then they would fail to decrement the counter, though I think the same thing would happen if the scaler were incrementing and decrementing the counter. If you kill a process with SIGKILL, does it create a zombie until the parent waits on it? Dave On 06/27/2011 09:47 AM, Renat Sabitov wrote: > Hi David, > > I am afraid there is an issue with counting currentconnections. From > one perspective it is counted with countConnections() from shm. From > another this variable is changed by incConnections() and > decConnections(). > > I made the patch with fork() to have 100% correct information on how > many connections are started by scaler, because connection processes > not always incremented and decremented currentconnections value in > shared memory. With my patch, scaler do not look on shm, but do > counting by itself. > > There is a problem in my patch: scaler do not care about connections > started manually or by the sqlr-start. > > With your adoption of the patch currentconnections in scaler is > changed by two ways, and this is actually an issue. > > I think that scaler should take control under shm->totalconnections > for dynamically spawned connections. I've created a patch against > current CVS, please take a look and write your thoughts. > > I tested patch by killing connections with SIGKILL. Only the first > connection (= not spawned) was unable to decrement counter, therefore > status shows 2 connections in scaler's view with only 1 process > started. Please notice buggy status of open connections/cursors, this > is the result of my massacre. > > Open Server Connections: 13 > Opened Server Connections: 57 > > Open Client Connections: 34203 > Opened Client Connections: 34203 > > Open Server Cursors: 65 > Opened Server Cursors: 294 > > Times New Cursor Used: 68578 > Times Cursor Reused: 68592 > > Total Queries: 68587 > Total Errors: 0 > > Forked Listeners: 0 > > Scaler's view: > Connections: 2 > Sessions: 2 > > Semaphores: > +---------------------------------------------+ > | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | > +---+---+---+---+---+---+---+---+---+---+-----+ > | 1 | 1 | 1 | 3 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | > +---------------------------------------------+ > > > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > > _______________________________________________________ > Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting > http://www.doteasy.com > > > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > _______________________________________________________ > Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting > http://www.doteasy.com _______________________________________________________ Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting http://www.doteasy.com |
|
From: Renat S. <sr...@st...> - 2011-06-28 19:30:17
|
On 28.06.2011 20:54, David Muse wrote: > This patch looks good. I applied it. Also, just for good measure, I > added code to handle the other semaphore failures in the same method > in the same way. > > I don't think waiting on sem(2) is an issue though, if a connection is > immediately available, then the listener will just hand off to it, > otherwise, it will fork a child to wait on sem(2) while it loops back > to handle more client connections. I agree. It was my fault with the test system configuration. Clients were connected through apache+php limited to max 5 workers. New requests simply did not reach main sqlrelay listener and it could not start new connection. Thanks for your analysis. |
|
From: Renat S. <sr...@st...> - 2011-06-28 18:57:33
|
On 28.06.2011 20:35, David Muse wrote: > Thanks, I removed the files that were getting created from the .in > files. Oops :) > > I'm not sure about the Makefile patch though, the init script looks in > the file /etc/sqlrelay for a list of instances to start at boot, or at > least that's what it's supposed to do. We could move that file to > /etc/sqlrelay/sqlrelay but it would require that the init script be > modified too. > There is another init script from the debian directory and it looks to /etc/sqlrelay/sqlrelay. Let Makefile stay as is and the debian build goes its way. > A long time ago, some guys got SQL Relay into the debian repository > and submitted similar debian directories for rudiments and sqlrelay. > I initially incorporated them into CVS, but later they asked me to > pull them back out. Apparently the debian package archive maintainers > prefer to add them as patches rather than have them in the software > distro. I think it's so they can tweak on them without having to > coordinate with anyone. > I agree, separate debian directory is a better way. |
16 messages has been excluded from this view by a project administrator.
