sqlrelay-discussion — Discussion of topics related to SQL Relay

Re: [Sqlrelay-discussion] trouble compiling

[tyju t. <jck...@ya...>]

It is defined in /usr/include/mysql/mysql.h
MYSQL *         STDCALL mysql_connect(MYSQL *mysql, const char *host,
                                      const char *user, const char *passwd);



________________________________
From: Claudio Freire <kla...@gm...>
To: Discussion of topics related to SQL Relay <sql...@li...>
Sent: Fri, February 12, 2010 8:51:12 AM
Subject: Re: [Sqlrelay-discussion] trouble compiling



On Thu, Feb 11, 2010 at 9:20 PM, tyju tiui <jck...@ya...> wrote:

>mysqlconnection.C:106: error: 'mysql_connect' was not declared in this scope
>

Read the includes in /usr/include/mysql and make sure they define mysql_connect.
If not, you may have to patch sqlrelay. But I suspect the includes are missing.


      

Re: [Sqlrelay-discussion] trouble compiling

[Claudio F. <kla...@gm...>]

On Thu, Feb 11, 2010 at 9:20 PM, tyju tiui <jck...@ya...> wrote:

> mysqlconnection.C:106: error: 'mysql_connect' was not declared in this
> scope
>

Read the includes in /usr/include/mysql and make sure they define
mysql_connect.
If not, you may have to patch sqlrelay. But I suspect the includes are
missing.

[Sqlrelay-discussion] trouble compiling

[tyju t. <jck...@ya...>]

Hi,

I'm trying to build sqlrealy-0.41 on RHEL5.3 64bit, gcc version 4.1.2

Here is the tail end of the build output
============================================
g++ -Wall -pipe -pthread -I./ -I../../../ -I../../../src/common -I../../../src/util -I../../../src/connection -I/usr/local/firstworks/include -pthread -I/usr/kerberos/include -I/usr/include/mysql -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fwrapv -I../../../src/api/c++/include -c mysqlconnection.C  -fPIC -DPIC -o .libs/mysqlconnection.o
mysqlconnection.C: In member function 'virtual bool mysqlconnection::logIn(bool)':
mysqlconnection.C:106: error: 'mysql_connect' was not declared in this scope
mysqlconnection.C:74: warning: unused variable 'dbval'
../../../src/common/datatypes.h: At global scope:
../../../src/common/datatypes.h:394: warning: 'bool isBitTypeChar(const char*)' defined but not used
../../../src/common/datatypes.h:399: warning: 'bool isBoolTypeChar(const char*)' defined but not used
../../../src/common/datatypes.h:403: warning: 'bool isFloatTypeChar(const char*)' defined but not used
../../../src/common/datatypes.h:417: warning: 'long int bitStringToLong(const char*)' defined but not used
make[3]: *** [mysqlconnection.lo] Error 1
make[3]: Leaving directory `/home/ty/downloads/sqlrelay-0.41/src/connections/mysql'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/ty/downloads/sqlrelay-0.41/src/connections'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/ty/downloads/sqlrelay-0.41/src'
make: *** [all] Error 2
============================================


Any help or advice would be appreciated.

Thanks!

Ty


      

Re: [Sqlrelay-discussion] Sybase/Perl performance - Email found in subject

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

I separated connection time from query run time.  The ping was included in connection time but was negligible so I wasn't concerned with the connection process.  I did run some tests without the ping in place just for apples to apples comparison.  Again connection time was fast enough to not be a concern.   I was more concerned with the query time as those were growing by an order of magnitude with every 1000 rows selected.  The patch has successfully fixed this issue.

Thanks,

CJ Vergara

From: David Muse [mailto:dav...@fi...]
Sent: Tuesday, February 09, 2010 12:42 PM
To: sql...@li...
Subject: [SPAM] - Re: [Sqlrelay-discussion] Sybase/Perl performance - Email found in subject

Very interesting.  I'll run some tests, but I think this is a good patch.

The only other thing...

I saw in your initial test script that you were doing a ping right after connecting.  Does your ctlib test do that as well?  That ping will add additional overhead.

David Muse
dm...@4a...<mailto:dm...@4a...>

On 02/05/2010 09:50 AM, Claudio Freire wrote:
On Fri, Feb 5, 2010 at 11:48 AM, Carlos Vergara <cve...@em...<mailto:cve...@em...>> wrote:
Thank you very much.  I will apply it and let you know how everything turns out.

I forgot to mention, this patch should be applied on the server side too.

(ie: so that the sqlrelay process uses the patched rudiments)







------------------------------------------------------------------------------

The Planet: dedicated and managed hosting, cloud storage, colocation

Stay online with enterprise data centers and the best network in the business

Choose flexible plans and management services without long-term contracts

Personal 24x7 support from experience hosting pros just a phone call away.

http://p.sf.net/sfu/theplanet-com



_______________________________________________________

Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting

              http://www.doteasy.com





_______________________________________________

Sqlrelay-discussion mailing list

Sql...@li...<mailto: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

Re: [Sqlrelay-discussion] Sybase/Perl performance

[Claudio F. <kla...@gm...>]

On Tue, Feb 9, 2010 at 3:49 PM, David Muse <dav...@fi...>wrote:

> This fix will mainly improve performance on the client side, but the
> server side uses the same class for managing bind variables, so it could
> improve performance on the server side for any database backend.  I
> think you'd see more of a performance improvement on the client side,
> but if you use a lot of bind variables then you would see an improvement
> on the server side too.
>

Actually, I measured the performance hit on the server side. My theory being
that, when implementing load balancing, the server uses both interfaces, so
the hit applies to the server side as well while relaying data between the
routing processes.

Re: [Sqlrelay-discussion] Sybase/Perl performance

[David M. <dav...@fi...>]

This fix will mainly improve performance on the client side, but the 
server side uses the same class for managing bind variables, so it could 
improve performance on the server side for any database backend.  I 
think you'd see more of a performance improvement on the client side, 
but if you use a lot of bind variables then you would see an improvement 
on the server side too.

Dave
dav...@fi...

On 02/06/2010 05:19 AM, Benoit Cattié wrote:
> Hi,
>
> is this affecting also other database backend ?
> I'm using oracle and i'm wondering if I had to recompile rudiments.
>
> Best regards
>
> Benoit
>
>
> Claudio Freire a écrit :
>    
>> Ok, it turned out that only a very small patch to rudiments is enough.
>> I'll try to push it into rudiments, but in the meanwhile, just apply
>> this patch to your rudiments installation:
>>
>> diff -wur rudiments-0.32.orig/src/memorypool.C
>> rudiments-0.32/src/memorypool.C
>> --- rudiments-0.32.orig/src/memorypool.C    2006-08-05
>> 01:34:47.000000000 -0300
>> +++ rudiments-0.32/src/memorypool.C    2009-08-31 18:54:28.000000000 -0300
>> @@ -88,8 +88,11 @@
>>       // if we didn't find a node with enough memory remaining,
>>       // create a new one at the end of the list
>>       if (!node) {
>> -        memnode=new memorypoolnode((length>pvt->_increment)?
>> -                        length:pvt->_increment);
>> +        size_t incr = pvt->_increment;
>> +        size_t tot = pvt->_totalusedsize;
>> +        if (incr<  (tot/10))
>> +            incr = (tot/10);
>> +        memnode=new memorypoolnode((length>incr)?length:incr);
>>           pvt->_nodelist.append(memnode);
>>       }
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------
>> The Planet: dedicated and managed hosting, cloud storage, colocation
>> Stay online with enterprise data centers and the best network in the business
>> Choose flexible plans and management services without long-term contracts
>> Personal 24x7 support from experience hosting pros just a phone call away.
>> http://p.sf.net/sfu/theplanet-com
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Sqlrelay-discussion mailing list
>> Sql...@li...
>> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion
>>
>>      
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-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 

Re: [Sqlrelay-discussion] Sybase/Perl performance

[David M. <dav...@fi...>]

Very interesting.  I'll run some tests, but I think this is a good patch.

The only other thing...

I saw in your initial test script that you were doing a ping right after 
connecting.  Does your ctlib test do that as well?  That ping will add 
additional overhead.

David Muse
dm...@4a...

On 02/05/2010 09:50 AM, Claudio Freire wrote:
> On Fri, Feb 5, 2010 at 11:48 AM, Carlos Vergara 
> <cve...@em... <mailto:cve...@em...>> wrote:
>
>     Thank you very much.  I will apply it and let you know how
>     everything turns out.
>
>
> I forgot to mention, this patch should be applied on the server side too.
>
> (ie: so that the sqlrelay process uses the patched rudiments)
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
>
> _______________________________________________________
> 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 

Re: [Sqlrelay-discussion] Sybase/Perl performance

[Benoit C. <ben...@fr...>]

Hi,

is this affecting also other database backend ?
I'm using oracle and i'm wondering if I had to recompile rudiments.

Best regards

Benoit


Claudio Freire a écrit :
> Ok, it turned out that only a very small patch to rudiments is enough. 
> I'll try to push it into rudiments, but in the meanwhile, just apply 
> this patch to your rudiments installation:
>
> diff -wur rudiments-0.32.orig/src/memorypool.C 
> rudiments-0.32/src/memorypool.C
> --- rudiments-0.32.orig/src/memorypool.C    2006-08-05 
> 01:34:47.000000000 -0300
> +++ rudiments-0.32/src/memorypool.C    2009-08-31 18:54:28.000000000 -0300
> @@ -88,8 +88,11 @@
>      // if we didn't find a node with enough memory remaining,
>      // create a new one at the end of the list
>      if (!node) {
> -        memnode=new memorypoolnode((length>pvt->_increment)?
> -                        length:pvt->_increment);
> +        size_t incr = pvt->_increment;
> +        size_t tot = pvt->_totalusedsize;
> +        if (incr < (tot/10))
> +            incr = (tot/10);
> +        memnode=new memorypoolnode((length>incr)?length:incr);
>          pvt->_nodelist.append(memnode);
>      }
>  
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> ------------------------------------------------------------------------
>
> _______________________________________________
> Sqlrelay-discussion mailing list
> Sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion
>   

Re: [Sqlrelay-discussion] Sybase/Perl performance

[Claudio F. <kla...@gm...>]

On Fri, Feb 5, 2010 at 11:48 AM, Carlos Vergara <cve...@em...
> wrote:

>  Thank you very much.  I will apply it and let you know how everything
> turns out.
>

I forgot to mention, this patch should be applied on the server side too.

(ie: so that the sqlrelay process uses the patched rudiments)

Re: [Sqlrelay-discussion] Sybase/Perl performance

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

Thank you very much.  I will apply it and let you know how everything turns out.

CJ Vergara

From: Claudio Freire [mailto:kla...@gm...]
Sent: Friday, February 05, 2010 8:26 AM
To: Discussion of topics related to SQL Relay
Cc: Carlos Vergara
Subject: Re: [Sqlrelay-discussion] Sybase/Perl performance

Ok, it turned out that only a very small patch to rudiments is enough. I'll try to push it into rudiments, but in the meanwhile, just apply this patch to your rudiments installation:

diff -wur rudiments-0.32.orig/src/memorypool.C rudiments-0.32/src/memorypool.C
--- rudiments-0.32.orig/src/memorypool.C    2006-08-05 01:34:47.000000000 -0300
+++ rudiments-0.32/src/memorypool.C    2009-08-31 18:54:28.000000000 -0300
@@ -88,8 +88,11 @@
     // if we didn't find a node with enough memory remaining,
     // create a new one at the end of the list
     if (!node) {
-        memnode=new memorypoolnode((length>pvt->_increment)?
-                        length:pvt->_increment);
+        size_t incr = pvt->_increment;
+        size_t tot = pvt->_totalusedsize;
+        if (incr < (tot/10))
+            incr = (tot/10);
+        memnode=new memorypoolnode((length>incr)?length:incr);
         pvt->_nodelist.append(memnode);
     }

Re: [Sqlrelay-discussion] Sybase/Perl performance

[Claudio F. <kla...@gm...>]

Ok, it turned out that only a very small patch to rudiments is enough. I'll
try to push it into rudiments, but in the meanwhile, just apply this patch
to your rudiments installation:

diff -wur rudiments-0.32.orig/src/memorypool.C
rudiments-0.32/src/memorypool.C
--- rudiments-0.32.orig/src/memorypool.C    2006-08-05 01:34:47.000000000
-0300
+++ rudiments-0.32/src/memorypool.C    2009-08-31 18:54:28.000000000 -0300
@@ -88,8 +88,11 @@
     // if we didn't find a node with enough memory remaining,
     // create a new one at the end of the list
     if (!node) {
-        memnode=new memorypoolnode((length>pvt->_increment)?
-                        length:pvt->_increment);
+        size_t incr = pvt->_increment;
+        size_t tot = pvt->_totalusedsize;
+        if (incr < (tot/10))
+            incr = (tot/10);
+        memnode=new memorypoolnode((length>incr)?length:incr);
         pvt->_nodelist.append(memnode);
     }

Re: [Sqlrelay-discussion] Sybase/Perl performance

[Claudio F. <kla...@gm...>]

On Thu, Feb 4, 2010 at 1:20 PM, Carlos Vergara
<cve...@em...>wrote:

>
>
> I have determined the lag of SQLRelay compared to ctLib is directly related
> to the size of the query result set.
>
>
>
> For anything under 1000 rows returned, the performance is comparable, for
> results with more than 1000 rows returned SQLRelay starts to lag.
>
>
>
> It seems to be nearly doubling the time to return with every 1000 rows
> returned.
>

That stems from a poor asymptotic order in one of Rudiments classes (the
memory pool IIRC).

I had patched rudiments and sqlrelay to overcome that. I'll prepare a patch
for it.

Re: [Sqlrelay-discussion] Sybase/Perl performance

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

I have determined the lag of SQLRelay compared to ctLib is directly related to the size of the query result set.



For anything under 1000 rows returned, the performance is comparable, for results with more than 1000 rows returned SQLRelay starts to lag.



It seems to be nearly doubling the time to return with every 1000 rows returned.



Test 1


i10

i100

i1000

i2000

i3000

i4000

i5000

i6000

i7000

i8000

i9000

# of rows selected

ctLib

3

4

4

5

5

5

5

6

6

6

6

time in seconds

SqlRelay

3

4

6

12

21

40

83

181

369

620

950






Any ideas what is going on?  I do not have results caching on.  Here is my configuration:



<instance id="test" port="9000" socket="/tmp/sybasetest.socket" dbase="sybase" connections="5"   maxconnections="5" maxqueuelength="1" growby="1" ttl="60" endofsession="commit" sessiontimeout="600" runasuser="nobody" runasgroup="nobody" cursors="5" authtier="listener" handoff="pass">

    <users>

      <user user="dev" password="syb"/>

    </users>

    <connections>

      <connection connectionid="test" string="server=dev_prop;db=prop;user=dev;password=syb;port=4125"  metric="1" behindloadbalancer="no"/>

    </connections>

  </instance>



My test is very basic it just runs the query it doesn't try and print results out or manipulate it.



  my $time2 = new Benchmark;

       $ss->sendQuery($sql);

  my $time3 = new Benchmark;

  my $runtime2 = timestr(timediff($time3,$time2));



Thank you for any help in this matter, I really want to use SQLRelay but I will not be able to unless I can get its performance up to par with ctLib.



CJ Vergara





-----Original Message-----
From: Carlos Vergara
Sent: Monday, February 01, 2010 3:25 PM
To: 'Discussion of topics related to SQL Relay'
Subject: Sybase/Perl performance



  I have a perl use question.  I am implementing SQLRelay with Sybase and Perl.  I want to replace my use of Sybase::CTlib



However just with initial tests, it seems the first query through SQLRelay takes substantially longer that through CTlib.  I have compiled SQLRelay to use the native Sybase C libraries.  I am not sure why the query takes what looks like a whole 1/2 second longer than through ctlib.



I have checked to make sure SQLRelay results caching is off, I am using the local unix socket, is there any other option I can configure?



Is there a way to run queries without setting up a cursor?



my $sc=SQLRelay::Connection->new("localhost",9000," /tmp/sybasetest.socket", "dev","devsyb",0,1);

  if($sc->ping()){ print "DB PING! Successful connection!\n"; } else { print "FAILED PING!  QUITING NOW\n"; exit; }

  my $ss=SQLRelay::Cursor->new($sc);



[1129]./test4.pl dev 10

Sending Query 10 times

ctStub:   x.........

SqlRelay: x.........



Connect 1:  0 wallclock secs ( 0.01 usr +  0.00 sys =  0.01 CPU)

 RunTime1:  1 wallclock secs ( 1.06 usr +  0.05 sys =  1.11 CPU)



Connect 2:  0 wallclock secs ( 0.00 usr +  0.00 sys =  0.00 CPU)

 RunTime2:  4 wallclock secs ( 2.64 usr +  0.02 sys =  2.66 CPU)



Printing Results RowCount|517|

Test Complete!





If I run the same query 1000 times, sqlrelay seems to out perform ctlib because after the first two queries subsequent ones run much faster than ctlib which has the same performance query after query.  Whereas sqlrelay is slow the first two times, then super fast.



My application is not going to run the same query 1000 times though, each query will be different, so I need the first query to be as fast as using ctlib.  Any suggestions would be helpful?



CJ Vergara

[Sqlrelay-discussion] Sybase/Perl performance

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

  I have a perl use question.  I am implementing SQLRelay with Sybase and Perl.  I want to replace my use of Sybase::CTlib

However just with initial tests, it seems the first query through SQLRelay takes substantially longer that through CTlib.  I have compiled SQLRelay to use the native Sybase C libraries.  I am not sure why the query takes what looks like a whole 1/2 second longer than through ctlib.

I have checked to make sure SQLRelay results caching is off, I am using the local unix socket, is there any other option I can configure?

Is there a way to run queries without setting up a cursor?

my $sc=SQLRelay::Connection->new("localhost",9000," /tmp/sybasetest.socket", "dev","devsyb",0,1);
  if($sc->ping()){ print "DB PING! Successful connection!\n"; } else { print "FAILED PING!  QUITING NOW\n"; exit; }
  my $ss=SQLRelay::Cursor->new($sc);

[1129]./test4.pl dev 10
Sending Query 10 times
ctStub:   x.........
SqlRelay: x.........

Connect 1:  0 wallclock secs ( 0.01 usr +  0.00 sys =  0.01 CPU)
 RunTime1:  1 wallclock secs ( 1.06 usr +  0.05 sys =  1.11 CPU)

Connect 2:  0 wallclock secs ( 0.00 usr +  0.00 sys =  0.00 CPU)
 RunTime2:  4 wallclock secs ( 2.64 usr +  0.02 sys =  2.66 CPU)

Printing Results RowCount|517|
Test Complete!


If I run the same query 1000 times, sqlrelay seems to out perform ctlib because after the first two queries subsequent ones run much faster than ctlib which has the same performance query after query.  Whereas sqlrelay is slow the first two times, then super fast.

My application is not going to run the same query 1000 times though, each query will be different, so I need the first query to be as fast as using ctlib.  Any suggestions would be helpful?

CJ Vergara

Re: [Sqlrelay-discussion] rails and sqlrelay

[David M. <dav...@fi...>]

I haven't gotten much into rails programming myself, so I'm not totally 
sure.

There is a Ruby DBI driver for SQL Relay.  So a program written to use 
Ruby's DBI interface will work with SQL Relay.  I've heard that there is 
a rails has it's own database driver interface, but that there is a DBI 
bridge.  So, in theory you could do:

rails -> rails-db-interface -> ruby-dbi -> SQLRelay driver -> SQLRelay

Ideally you'd do:

rails -> rails-db-interface -> SQLRelay  driver -> SQLRelay

But that doesn't currently exist.

Hopefully my understanding of all of this is accurate.  I haven't done 
much with rails.

David Muse
dav...@fi...

On 01/31/2010 02:20 PM, joel wrote:
> Looking to get rails working with sqlrelay without having my dev team to
> do any code rework.  Is there an adapter out there to work with
> sqlrelay.  I have the setup I want working so far but it's kind of
> useless to me unless I can have this for an easy drop in replacement for
> the current traditional setup of a master db that's taking all the
> traffic.
>
> Thanks
>
> ~joel
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-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 

[Sqlrelay-discussion] rails and sqlrelay

[joel <jo...@sa...>]

Looking to get rails working with sqlrelay without having my dev team to 
do any code rework.  Is there an adapter out there to work with 
sqlrelay.  I have the setup I want working so far but it's kind of 
useless to me unless I can have this for an easy drop in replacement for 
the current traditional setup of a master db that's taking all the 
traffic.

Thanks

~joel

Re: [Sqlrelay-discussion] Building SQLRelay for 64 bit

[David M. <dav...@fi...>]

There shouldn't be, as long as you use 0.37 or newer.  My primary 
development platform, for a while, was 64 bit Fedora Core 9.  I've run 
plenty of tests on a mix of 64 and 32 bit clients and servers.

A long time ago there were some issues.  I'd used "short" and "long" 
datatypes in my code, then found out on intel 64 bit platforms a long 
was 64 bits and on 32 bit platforms it was 32 bits.  So there were 
issues sending data between the 2 platforms.  But that was fixed in 
version 0.37.

It should be ok now.

David Muse
dav...@fi...

On 01/28/2010 12:42 PM, Rob Tanner wrote:
> Hi,
>
> We use SQL Relay currently on our web servers and it works wonderfully 
> for us.  But now we are looking to redesign our front-end using load 
> balanced 64 bit systems.  Are there any problem building and running 
> SQL Relay on 64 bit Red Hat Enterprise 5 servers?
>
> Thanks,
> Rob
>
>
>
>
> *Rob Tanner
> *UNIX Services Manager
> Linfield College, McMinnville Oregon
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
>
> _______________________________________________________
> 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 

[Sqlrelay-discussion] Building SQLRelay for 64 bit

[Rob T. <rt...@li...>]

Hi,

We use SQL Relay currently on our web servers and it works wonderfully for
us.  But now we are looking to redesign our front-end using load balanced 64
bit systems.  Are there any problem building and running SQL Relay on 64 bit
Red Hat Enterprise 5 servers?

Thanks,
Rob




Rob Tanner
UNIX Services Manager
Linfield College, McMinnville Oregon

Re: [Sqlrelay-discussion] Manifold FreeTDS symptoms

[Cameron L. <cla...@gm...>]

On Wed, Jan 27, 2010 at 2:27 PM, David Muse <dav...@fi...>wrote:

>  The only introspection that's available in SQL Relay is to turn on
> server-side debugging and dig through the logs.  There's no dashboard or
> anything like that.  I'm not sure how useful it would be if there was,
> queries would go flying by too quickly to make sense of them.  There is a
> stats monitor that shows how many connections and cursors and such are open,
> but there's a bug in it now and it's not reliable.
>
> Freetds only supports 1 cursor per database connection, but Zope and other
> frameworks use multiple cursors to handle nested queries.  SQL Relay
> provides a multi-cursor interface to
>
...

> Also, what version of freetds are you using?
>
> A quick, reliable solution would be to build SQL Relay against sybase
> client libs rather than freetds and use that.  It supports multiple cursors
> per connection.  But, there could certainly be licensing issues there.
>    ...
>

 sqlrelay-freetds 1:0.38-3ubuntu1; that's the version, as near as I can
tell.

"A quick, reliable solution ...":  at one level is this quick?  I currently
am running against Debian packages, as you can see.  Is "to build SQL Relay
..." something *I* would do, or a change you're proposing for the reference
sources of SQL Relay, or ...?  I'm happy to work in C, and to generate
libraries myself; I just want to be sure I understand your description.

Many thanks, by the way, for these valuable details.

Re: [Sqlrelay-discussion] Manifold FreeTDS symptoms

[David M. <dav...@fi...>]

The only introspection that's available in SQL Relay is to turn on 
server-side debugging and dig through the logs.  There's no dashboard or 
anything like that.  I'm not sure how useful it would be if there was, 
queries would go flying by too quickly to make sense of them.  There is 
a stats monitor that shows how many connections and cursors and such are 
open, but there's a bug in it now and it's not reliable.

Freetds only supports 1 cursor per database connection, but Zope and 
other frameworks use multiple cursors to handle nested queries.  SQL 
Relay provides a multi-cursor interface to Zope by caching result sets 
and sharing the one freetds cursor across multiple sqlrelay cursors.  
The setResultSetBufferSize() option can kink this up though, and cause 
this error.  Is it possible that somebody modified your copy of the Zope 
API, or the Python API that it relies on to use setResultSetBufferSize()?

If so, I'd expect you'd see problems when running nested queries and an 
outer query returns more rows than setResultSetBufferSize() is set to 
accommodate.

Also, what version of freetds are you using?

A quick, reliable solution would be to build SQL Relay against sybase 
client libs rather than freetds and use that.  It supports multiple 
cursors per connection.  But, there could certainly be licensing issues 
there.

Dave
dm...@4a...

On 01/26/2010 05:56 PM, Cameron Laird wrote:
> I'm in the middle of a collection of people pointing fingers at each 
> other, and looking for a shortcut to some saner place.  Help would be 
> welcome.
>
> Our 0.38-based (is there a canonical way to tell version?  
> /usr/bin/sqlrclient-config mentions "version=0.38") SQL Relay is 
> connected to a Sybase instance.  One of our developers is reporting 
> all sorts of errors in a Zope application, including frequent but 
> poorly-reproducible "No server-side cursors were available ..." and 
> "Attempt to initiate a new SQL Server operation with results 
> pending".  As I read the FAQ, 0.37 should have eliminated the latter, 
> and the former makes no sense to me, as the application is a 
> Zope-based one, and therefore should use only a single connection, right?
>
> What introspection does SQL Relay offer?  Is there a practical way to 
> ask it which cursors and threads are running, and what they're 
> currently doing?  Is there any reason to think an update of SQL Relay 
> itself will help?  I'm open to suggestion on where to start with this 
> tangle.
>
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
>
> _______________________________________________________
> 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 

[Sqlrelay-discussion] Manifold FreeTDS symptoms

[Cameron L. <cla...@gm...>]

I'm in the middle of a collection of people pointing fingers at each other,
and looking for a shortcut to some saner place.  Help would be welcome.

Our 0.38-based (is there a canonical way to tell version?
/usr/bin/sqlrclient-config mentions "version=0.38") SQL Relay is connected
to a Sybase instance.  One of our developers is reporting all sorts of
errors in a Zope application, including frequent but poorly-reproducible "No
server-side cursors were available ..." and "Attempt to initiate a new SQL
Server operation with results pending".  As I read the FAQ, 0.37 should have
eliminated the latter, and the former makes no sense to me, as the
application is a Zope-based one, and therefore should use only a single
connection, right?

What introspection does SQL Relay offer?  Is there a practical way to ask it
which cursors and threads are running, and what they're currently doing?  Is
there any reason to think an update of SQL Relay itself will help?  I'm open
to suggestion on where to start with this tangle.

Re: [Sqlrelay-discussion] sqlr-listener

[Alberto C. <aca...@pu...>]

2010/1/21 Cameron Laird <cla...@gm...>:
> On Thu, Jan 21, 2010 at 1:18 AM, Alberto Cabello <aca...@pu...> wrote:
>>
>> Hi, Jerome
>>
>> IIRC, the standard workaround to solve this known bug is to add a
>> dummy instance at the start of the conf file, just to make the parser
>> happy.
>
> ...
> Now I'm curious:  what's the bug?  I don't understand the symptom as Mr.
> Macaranas reported it.

I don't know what is exactly the bug, but my experience is that
sqlr-scaler wont start unless you have an instance placed before the
actual instance you want to start.

I unsuccessfully tried to solve the issue in the code in a hurry (it
is a bug in the configuration parser, I guess), but was more pressed
to get the thing working so I gave up as the dummy instance worked
like a charm.

Re: [Sqlrelay-discussion] sqlr-listener

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

I had encountered the same issue and the dummy instance resolved the problem.

When working with the provided conf example that only has 1 instance defined, the bug presents itself in the startup.
1 sql-listener process is started.
3 sql-connection processes are started.
Right after the 3rd sql-connection is started the listener dies or is shut-down somehow before the scaler and cachemanger processes are started.
The last two processes fail to start (scaler,cachemanger) because there is no longer an sql-listener process running.

After adding the dummy instance to the conf file all 5 processes are started normally.  Most have attributed this to a bug in the Parser of the conf file but I haven't tried to track down the lines of code causing the issue.

I am working with SQL Relay version: 0.41

CJ Vergara

From: Cameron Laird [mailto:cla...@gm...]
Sent: Thursday, January 21, 2010 7:31 AM
To: Discussion of topics related to SQL Relay
Subject: [SPAM] - Re: [Sqlrelay-discussion] sqlr-listener - Email found in subject

On Thu, Jan 21, 2010 at 1:18 AM, Alberto Cabello <aca...@pu...<mailto:aca...@pu...>> wrote:
Hi, Jerome

IIRC, the standard workaround to solve this known bug is to add a
dummy instance at the start of the conf file, just to make the parser
happy.
...

Now I'm curious:  what's the bug?  I don't understand the symptom as Mr. Macaranas reported it.

Re: [Sqlrelay-discussion] sqlr-listener

[Cameron L. <cla...@gm...>]

On Thu, Jan 21, 2010 at 1:18 AM, Alberto Cabello <aca...@pu...> wrote:

> Hi, Jerome
>
> IIRC, the standard workaround to solve this known bug is to add a
> dummy instance at the start of the conf file, just to make the parser
> happy.
>
...

Now I'm curious:  what's the bug?  I don't understand the symptom as Mr.
Macaranas reported it.

Re: [Sqlrelay-discussion] sqlr-listener

[Alberto C. <aca...@pu...>]

Hi, Jerome

IIRC, the standard workaround to solve this known bug is to add a
dummy instance at the start of the conf file, just to make the parser
happy.
Hope that helps.

2010/1/20 Jerome Macaranas <jer...@gm...>:
> sqlr-listener wont start...
>
> did a debug..
> ....
>
> creating shared memory and semaphores
> id filename:
> /usr/local/firstworks/var/sqlrelay/tmp/ipc/staging
> creating shared memory...
> creating semaphores...
>
>
>
> --------------------
> conf..
>
> <?xml version="1.0"?>
> <!DOCTYPE instances SYSTEM "sqlrelay.dtd">
> <instances>
>         <instance id="staging" port="9000" socket="/tmp/mysqltest.socket"
> dbase="mysql" connections="3" maxconnections="5" maxqueuelength="0"
> growby="1" ttl="60" endofsession="commit" sessiontimeout="600"
> runasuser="nobody" runasgroup="nobody" cursors="5" authtier="listener"
> handoff="pass" debug="listener_and_connection">
>                 <users>
>                         <user user="stagingconn" password="testdd"/>
>                 </users>
>                 <connections>
>                         <connection connectionid="staging"
> string="host=testbox;user=staginguser;password=test;db=staging" metric="1"/>
>                 </connections>
>         </instance>
> </instances>
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for
> Conference
> attendees to learn about information security's most important issues
> through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> Sqlrelay-discussion mailing list
> Sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion
>
>