sqlrelay-discussion — Discussion of topics related to SQL Relay

Re: [Sqlrelay-discussion] Mysql auto reconnect problem

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

In the sqlrelay source distribution, open the file 
src/connections/mysql/mysqlconnection.cpp and search for ::errorMessage.

If an error occurs, the errorMessage method fetches the error from mysql 
and returns it to the client.  It interprets certain messages as meaning 
"I've lost my db connection" and this causes SQL Relay to re-log-in to 
the db.

SQL Relay doesn't currently recognize "Lost connection to MySQL server 
during query."  Apparently I added it at some point, but then commented 
it out.  I don't actually remember doing either, but if you uncomment 
that code, rebuild and reinstall, it should cause relay to reconnect 
when it sees that error.

It's very odd that code to recognize that error is in there but 
commented out.  I guess there might have been some issue with it but I 
don't have any specific memory if it at all.  Please let me know if you 
run into any issues.

Dave
dav...@fi...

On 12/03/2012 11:25 PM, lee angus wrote:
> Dear all:
> We are using sqlrelay for php connection pool.
> There are some problem about mysql's MYSQL_OPT_RECONNECT.
> When sqlrelay's conneciotn exceed Mysql's interactive_timeout,or Mysql
> server daemon restarted.
> We will always get Error "Lost connection to MySQL server during query"
> unless we restart sqlrelay.
>
> Env infomantion:
> OS:centos6.2
> Sqlrelay:0.47
> Mysql lib:5.1.59
>
>
> Test plan as below.
> 1.Start sqlrelay -> Mysql connection,sqlrelay,conf as below
> =========================================
> sqlrealy
> <instances>
>          <instance       id="test_mysql"
>                          dbase="mysql"
>                          addresses=""
>                          port=""
>                          socket="/opt/sqlrelay/socket/test_mysql.socket"
>                          connections="1"
>                          maxconnections="20"
>                          maxqueuelength="0"
>                          cursors="1"
>                          maxcursors="100"
>                          maxlisteners="20"
>                          listenertimeout="1"
>                          waitfordowndatabase="no"
>                          runasuser="nobody"
>                          runasgroup="nobody"
>                          authtier="connection"
>                          handoff="pass"
>                          endofsession="rollback"
>                          ignoreselectdatabase="yes"
>                          timequeriessec="-1"
>                          timequeriesusec="-1"
>                          debug="none">
>                  <users><user user="user" password="password"/></users>
>                  <connections>
>                          <connection connectionid="test_mysql"
>
> string="user=test_mysql;password=test_mysql;host=172.16.30.211;port=3307;db=test_mysql;fakebinds=yes">
>                  </connections>
>          </instance>
> </instances>
> =========================================
> 2.Useing sqlrsh test connection,work functionally.
> =========================================
> # sqlrsh -id test_mysql
> SQLRShell - Version 0.22
>          Connected to: localhost:0 as user
>
>          type help; for a help.
>
> 0> select now();
> now()
> ===================
> 2012-12-03 14:21:50
>          Rows Returned   : 1
>          Fields Returned : 1
>          System time     : 50000
> =========================================
> 3.Then,kill client process from mysql server.(Here we using kill process
> to emulate Mysql's interactive_timeout )
>    We got "Lost connection to MySQL server during query" log.
> =========================================
> sqlrsh -id test_mysql
> SQLRShell - Version 0.22
>          Connected to: localhost:0 as user
>
>          type help; for a help.
>
> 0> select now();
> 2013:
> Lost connection to MySQL server during query
>
>          Rows Returned   : 0
>          Fields Returned : 0
>          System time     : 60000
>
> 0>
> =========================================
>
> This connection wont work unless we restart sqlrelay.
> We have checked sqlrelay's ChangeLog,MYSQL_OPT_RECONNECT have been
> applied  after sqlrelay-0.40.
>
>
> Any suugestion or advice will be appreciated!!
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
>
> _______________________________________________________
> 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
>

[Sqlrelay-discussion] Hibernate & sqlrelay

[<dw...@ca...>]

Hi,
I have sqlrelay installed, and configured for splitting reads & writes between MySQL master and slave databases. I can run sqlrsh, and that works fine.

What I need to do, though, is have my web application use sqlrelay.  It runs under Tomcat and uses Hibernate, which uses the MySQL JDBC driver. I found this email in the archive about doing that:
  http://sourceforge.net/mailarchive/message.php?msg_id=18563755
which suggested using a PostgreSQL JDBC driver and the sqlrelay drop-in library for PostgreSQL. Is that still the best/only solution?

Thanks,
Dwight

[Sqlrelay-discussion] Mysql auto reconnect problem

[lee a. <an...@gm...>]

Dear all:
We are using sqlrelay for php connection pool.
There are some problem about mysql's MYSQL_OPT_RECONNECT.
When sqlrelay's conneciotn exceed Mysql's interactive_timeout,or Mysql
server daemon restarted.
We will always get Error "Lost connection to MySQL server during query"
unless we restart sqlrelay.

Env infomantion:
OS:centos6.2
Sqlrelay:0.47
Mysql lib:5.1.59


Test plan as below.
1.Start sqlrelay -> Mysql connection,sqlrelay,conf as below
=========================================
sqlrealy
<instances>
        <instance       id="test_mysql"
                        dbase="mysql"
                        addresses=""
                        port=""
                        socket="/opt/sqlrelay/socket/test_mysql.socket"
                        connections="1"
                        maxconnections="20"
                        maxqueuelength="0"
                        cursors="1"
                        maxcursors="100"
                        maxlisteners="20"
                        listenertimeout="1"
                        waitfordowndatabase="no"
                        runasuser="nobody"
                        runasgroup="nobody"
                        authtier="connection"
                        handoff="pass"
                        endofsession="rollback"
                        ignoreselectdatabase="yes"
                        timequeriessec="-1"
                        timequeriesusec="-1"
                        debug="none">
                <users><user user="user" password="password"/></users>
                <connections>
                        <connection connectionid="test_mysql"

string="user=test_mysql;password=test_mysql;host=172.16.30.211;port=3307;db=test_mysql;fakebinds=yes">
                </connections>
        </instance>
</instances>
=========================================
2.Useing sqlrsh test connection,work functionally.
=========================================
# sqlrsh -id test_mysql
SQLRShell - Version 0.22
        Connected to: localhost:0 as user

        type help; for a help.

0> select now();
now()
===================
2012-12-03 14:21:50
        Rows Returned   : 1
        Fields Returned : 1
        System time     : 50000
=========================================
3.Then,kill client process from mysql server.(Here we using kill process to
emulate Mysql's interactive_timeout )
  We got "Lost connection to MySQL server during query" log.
=========================================
sqlrsh -id test_mysql
SQLRShell - Version 0.22
        Connected to: localhost:0 as user

        type help; for a help.

0> select now();
2013:
Lost connection to MySQL server during query

        Rows Returned   : 0
        Fields Returned : 0
        System time     : 60000

0>
=========================================

This connection wont work unless we restart sqlrelay.
We have checked sqlrelay's ChangeLog,MYSQL_OPT_RECONNECT have been applied
 after sqlrelay-0.40.


Any suugestion or advice will be appreciated!!

[Sqlrelay-discussion] Lusaka auto reconnection problem

[lee a. <an...@gm...>]

Dear all:
We are using sqlrelay for php connection
pool.
There are some problem about mysql's
MYSQL_OPT_RECONNECT.
When sqlrelay's conneciotn exceed Mysql's
interactive_timeout,or Mysql server
daemon restarted.
We will always get Error "Lost connection
to MySQL server during query" unless we
restart sqlrelay.

Env infomantion:
OS:centos6.2
Sqlrelay:0.47
Mysql lib:5.1.59

Test plan as below.
1.Start sqlrelay -> Mysql
connection,sqlrelay,conf as below
==============================
===========
sqlrealy
<instances>
<instance id="test_mysql"
dbase="mysql"
addresses=""
port=""
socket="/opt/sqlrelay/socket/t
est_mysql.socket"
connections="1"
maxconnections="20"
maxqueuelength="0"
cursors="1"
maxcursors="100"
maxlisteners="20"
listenertimeout="1"
waitfordowndatabase="no"
runasuser="nobody"
runasgroup="nobody"
authtier="connection"
handoff="pass"
endofsession="rollback"
ignoreselectdatabase="yes"
timequeriessec="-1"
timequeriesusec="-1"
debug="none">
<users><user user="user"
password="password"/></users>
<connections>
<connection
connectionid="test_mysql"
string="user=test_mysql;passwo
rd=test_mysql;host=172.16.30.
211;port=3307;db=test_mysql;
fakebinds=yes">
</connections>
</instance>
</instances>
==============================
===========
2.Useing sqlrsh test connection,work
functionally.
==============================
===========
# sqlrsh -id test_mysql
SQLRShell - Version 0.22
Connected to: localhost:0 as user

type help; for a help.

0> select now();
now()
===================
2012-12-03 14:21:50
Rows Returned : 1
Fields Returned : 1
System time : 50000
==============================
===========
3.Then,kill client process from mysql
server.(Here we using kill process to
emulate Mysql's interactive_timeout )
We got "Lost connection to MySQL server
during query" log.
==============================
===========
sqlrsh -id test_mysql
SQLRShell - Version 0.22
Connected to: localhost:0 as user

type help; for a help.

0> select now();
2013:
Lost connection to MySQL server during
query

Rows Returned : 0
Fields Returned : 0
System time : 60000

0>
==============================
===========

This connection wont work unless we
restart sqlrelay.
We have checked sqlrelay's
ChangeLog,MYSQL_OPT_RECONNECT
have been applied after sqlrelay-0.40.

Any suugestion or advice will be
appreciated!!

[Sqlrelay-discussion] SQL Relay - 0.47 is out

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

Hello all,

SQL Relay 0.47 is now available.

This release mainly features the ability to use Oracle's Statement Cache 
feature. Code for this was contributed by Neowiz.

To enable the statement cache, simply add:

     stmtcachesize=20

(Or some size other than 20)

...to the connect string for your instance of SQL Relay that talks to 
Oracle in your sqlrelay.conf file. Note also that there are a few quirks 
when using the statement cache which appear to be either bugs in OCI or 
issues with the way SQL Relay uses OCI. They may be resolved in a future 
release of OCI or SQL Relay. See Configuring SQL Relay on the 
Documentation page of the SQL Relay website for more information.

Note also that I haven't finished integrating all of the contributed 
code yet, so if something doesn't work as expected, that could be why.

Also in this release, I updated the SQL Relay command line clients to 
have a consistent command-line parameter interface and renamed a few of 
them.

All command line programs now have the following parameters:

     -host
     -port
     -socket
     -user
     -password

So, for example, to connect to localhost, port 9000 using user test with 
password test, you now use:

     sqlrsh -host localhost -port 9000 -user test -password test

Whereas in the past, you would have used:

     sqlrsh localhost 9000 "" test test

In addition, sqlrsh now has -script and -command arguments to run 
scripts or commands non-interactively.

I also renamed the query and fields commands sqlr-query and sqlr-fields.

In addition to those updates and changes, the following new features and 
bug fixes have also been implemented:

     fixed bug that caused sqlr-export to output negative xml-entity values
     fixed single-quote-escaping in sqlr-export
     forced handoff="reconnect" for Cygwin and Linux<2.2
     added a "fields" command to sqlrsh
     improved readline detection in the configure script
     added getDatabase/Table/ColumnList support to odbc and mdbtools 
connections
     added detection and support for openjdk
     integrated patches from Neowiz for:
         using -g3 if available when --enable-debug is specified
         fixing an oracle column-resource-related memory leak
         eliminating sqlr-start delay
         "using namespace rudiments" declaration fixes
     added a faq entry about common OCIEnvCreate errors
     removed default id warning from sqlr-cachemanager
     removed coloration from sqlrsh
     updated begin, commit and rollback to return errors if they fail
     updated firebird docs
     added parsing of standalone constraints in a create table query

[Sqlrelay-discussion] Problems in setting up sqlrelay in rw-splitting mode. Using two mysql servers

[Abhijeet <abh...@gm...>]

Hi ,

My sqlrelay.conf file is as follows


<?xml version="1.0"?>
<!DOCTYPE instances SYSTEM "sqlrelay.dtd">
<instances>
        <instance id="master" port="9001" socket="/tmp/master.lock"
dbase="mysql" connections="1" maxconnections="15" maxqueuelength="5"
growby="1" ttl="60" endofsession="commit" sessiontimeout="600"
runasuser="asane" runasgroup="asane" cursors="5" authtier="listener"
handoff="pass" deniedips="" allowedips="" debug="none"
maxquerysize="65536" maxstringbindvaluelength="4000"
maxlobbindvaluelength="71680" idleclienttimeout="-1">

                <users>
                        <user user="root" password="root"/>
                </users>
                <connections>
                        <connection connectionid="master"
string="user=root;password=root;db=tango_dev;host=a.b.c.d;port=3306;fakebinds=yes"
metric="1" behindloadbalancer="no"/>
                </connections>
        </instance>
        <instance id="slave" port="9002" socket="/tmp/slave.lock"
dbase="mysql" connections="1" maxconnections="15" maxqueuelength="5"
growby="1" ttl="60" endofsession="commit" sessiontimeout="600"
runasuser="asane" runasgroup="asane" cursors="5" authtier="listener"
handoff="pass" deniedips="" allowedips="" debug="none"
maxquerysize="65536" maxstringbindvaluelength="4000"
maxlobbindvaluelength="71680" idleclienttimeout="-1">

                <users>
                        <user user="root" password=""/>
                </users>
                <connections>
                        <connection connectionid="slave"
string="user=root;password=root;db=tango_dev;host=a.b.c.d;port=3307;fakebinds=yes"
metric="2" behindloadbalancer="no"/>
                </connections>
        </instance>
        <instance id="router" port="9000" socket="/tmp/slave.lock"
dbase="router" connections="1" maxconnections="15" maxqueuelength="5"
growby="1" ttl="60" endofsession="commit" sessiontimeout="600"
runasuser="asane" runasgroup="asane" cursors="5" authtier="listener"
handoff="pass" deniedips="" allowedips="" debug="none"
maxquerysize="65536" maxstringbindvaluelength="4000"
maxlobbindvaluelength="71680" idleclienttimeout="-1">
                <users>
                        <user user="root" password="root"/>
                </users>
                <router>
                        <route host="" port=""
socket="/tmp/master.lock" user="root" password="root">
                               <query pattern="^\s*create\s+table\s+"/>
                               <query pattern="^\s*drop\s+table\s+"/>
                               <query pattern="^\s*insert\s+into\s+"/>
                               <query pattern="^\s*delete\s+from\s+"/>
                               <query pattern="^\s*update\s+"/>
                        </route>
                        <route host="" port=""
socket="/tmp/slave.lock" user="root" password="root">
                               <query pattern=".*"/>
                        </route>
                </router>
        </instance>

</instances>


I am trying to setup sqlrelay in a rw-splitting mode. I have two mysql
databases which I am using in rw-splitting mode for performance
scaling .
It seems to me that when i configure only one database in the config
file and start sqlr-stat -id master  the connection is working as
expected .
( sqlrsh -id master   and select count(*) from tablename is working
correctly) ( No scaling possible)

But the moment i use the sqlr-start -id router . All process start but
sqlrsh is not showing me any data in fact it hangs.

> sqlrsh -id router
SQLRShell - Version 0.22
        Connected to: localhost:9000 as root

        type help; for a help.

0> use db;select count(*) from table_name;

(nothing  happens)


Please guide where my setting is going wrong .

Thanks in advance.

Abhijeet Anant Sane

Re: [Sqlrelay-discussion] Multiple sqlr-listener processes and no connections

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

Hi Ville,

Sorry for not responding earlier.

SQL Relay should automatically re-log in if it loses connection to the 
database.  I recently added a parameter to disable that behavior, but it 
should do it by default.

It sounds like the sqlr-connection-mysql process is crashing for some 
reason but the semaphores are in such a state that the sqlr-scaler 
doesn't realize this and doesn't spawn any new processes.

I've actually tried to reproduce this and gone through the code, looking 
for some semi-obvious thing that could cause it, but I can't find 
anything.  My guess is that there is some particular query that crashes 
the process.

The last time I encountered a problem like this, it was with oracle and 
the problem was that I misinterpreted characters for bytes and if OCI 
said "allocate 100 characters", I'd allocate a buffer of 100 bytes, 
which was fine until somebody started using unicode and the query 
returned multi-byte characters.  Something like that.  I looked again 
for that kind of thing, but I didn't see anything.

Nevertheless, I suspect something like that is the problem.  It would be 
helpful if you could find the query or condition that's causing the 
connections to crash, though I imagine that would be like looking for a 
needle in a haystack.

I'll be out of town for the next few days, but I can look into it again 
when I get back.

Dave
dav...@fi...

On 09/25/2012 06:00 AM, Ville Silventoinen wrote:
> Hi,
>
> Just few more details on this:
>
> - I run SQL Relay 0.46 with two different instances configured in
> sqlrelay.conf; one for Oracle and one for MySQL.
>
> - When the problem happens, it's always with the MySQL connections. All
> the sqlr-connection-mysql processes have stopped/crashed and there are
> several sqlr-listener processes for the MySQL instance. They seem to be
> unable to start any sqlr-connection-mysql processes.
>
> - Just guesswork, but could the problem be caused if for whatever reason
> SQL Relay fails to login to MySQL? Would that stop the
> sqlr-connection-mysql process? I've asked the MySQL admin, but we don't
> log the failed login attempts. I could turn on the connection debug mode
> in SQL Relay, but last time we did that, it filled the /var filesystem
> very fast, so I'd need to find some disk space for that.
>
> - I'm waiting when the problem happens next time so I can run the
> "sqlr-status -id INSTANCE" command to see what the raw semaphore numbers
> are. I saw an old thread that seems quite similar to this, but I'm not
> sure if it's related.
>
> Cheers,
> Ville
>
> On 4 September 2012 12:15, Ville Silventoinen
> <vil...@gm... <mailto:vil...@gm...>> wrote:
>
>     Hi,
>
>     I'm using SQL Relay 0.45 on RedHat 6. Sometimes SQL Relay goes into
>     a state where it starts several sqlr-listener processes, but there
>     are no sqlr-connection processes. The application that uses SQL
>     Relay hangs. There may be a problem with RedHat and the network card
>     we are using, which can cause temporary loss of network
>     connectivity. The only cure that I've found is to restart SQL Relay.
>
>     Today I decided to try SQL Relay 0.46. As I was running tests, our
>     DBAs shutdown the test Oracle database (I wasn't aware of this).
>     Again, the same situation happened: Several sqlr-listener processes
>     and no connections.
>
>     I'm looking for some insight into how I could configure SQL Relay so
>     it would automatically recover from the temporary loss of network
>     connectivity or database availability. Is this possible? Would it
>     help if I set maxlisteners to 0, listenertimeout to 60, or tweak
>     some other configuration variable?
>
>     Thanks for any advice,
>     Ville
>
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
> _______________________________________________________
> 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
>

Re: [Sqlrelay-discussion] Multiple sqlr-listener processes and no connections

[Ville S. <vil...@gm...>]

Hi,

Just few more details on this:

- I run SQL Relay 0.46 with two different instances configured in
sqlrelay.conf; one for Oracle and one for MySQL.

- When the problem happens, it's always with the MySQL connections. All the
sqlr-connection-mysql processes have stopped/crashed and there are several
sqlr-listener processes for the MySQL instance. They seem to be unable to
start any sqlr-connection-mysql processes.

- Just guesswork, but could the problem be caused if for whatever reason
SQL Relay fails to login to MySQL? Would that stop the
sqlr-connection-mysql process? I've asked the MySQL admin, but we don't log
the failed login attempts. I could turn on the connection debug mode in SQL
Relay, but last time we did that, it filled the /var filesystem very fast,
so I'd need to find some disk space for that.

- I'm waiting when the problem happens next time so I can run the
"sqlr-status -id INSTANCE" command to see what the raw semaphore numbers
are. I saw an old thread that seems quite similar to this, but I'm not sure
if it's related.

Cheers,
Ville

On 4 September 2012 12:15, Ville Silventoinen
<vil...@gm...>wrote:

> Hi,
>
> I'm using SQL Relay 0.45 on RedHat 6. Sometimes SQL Relay goes into a
> state where it starts several sqlr-listener processes, but there are no
> sqlr-connection processes. The application that uses SQL Relay hangs. There
> may be a problem with RedHat and the network card we are using, which can
> cause temporary loss of network connectivity. The only cure that I've found
> is to restart SQL Relay.
>
> Today I decided to try SQL Relay 0.46. As I was running tests, our DBAs
> shutdown the test Oracle database (I wasn't aware of this). Again, the same
> situation happened: Several sqlr-listener processes and no connections.
>
> I'm looking for some insight into how I could configure SQL Relay so it
> would automatically recover from the temporary loss of network connectivity
> or database availability. Is this possible? Would it help if I set
> maxlisteners to 0, listenertimeout to 60, or tweak some other configuration
> variable?
>
> Thanks for any advice,
> Ville
>
>
>

[Sqlrelay-discussion] Multiple sqlr-listener processes and no connections

[Ville S. <vil...@gm...>]

Hi,

I'm using SQL Relay 0.45 on RedHat 6. Sometimes SQL Relay goes into a state
where it starts several sqlr-listener processes, but there are no
sqlr-connection processes. The application that uses SQL Relay hangs. There
may be a problem with RedHat and the network card we are using, which can
cause temporary loss of network connectivity. The only cure that I've found
is to restart SQL Relay.

Today I decided to try SQL Relay 0.46. As I was running tests, our DBAs
shutdown the test Oracle database (I wasn't aware of this). Again, the same
situation happened: Several sqlr-listener processes and no connections.

I'm looking for some insight into how I could configure SQL Relay so it
would automatically recover from the temporary loss of network connectivity
or database availability. Is this possible? Would it help if I set
maxlisteners to 0, listenertimeout to 60, or tweak some other configuration
variable?

Thanks for any advice,
Ville

[Sqlrelay-discussion] SQL Relay - 0.46 is out

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

Hello all,

SQL Relay 0.46 is now available!

The biggest new feature in this release is a native windows ADO.NET data 
provider. Yes, you can now aim your Windows .NET applications at SQL Relay.

To accomplish this, I ported most of Rudiments and the client-side 
components of SQL Relay to MSVC, wrote a C# wrapper for the client API 
and wrote an ADO.NET data provider using the C# wrapper.

A binary distribution will be available soon, but for now, see the 
documentation for how to build, install and use the data provider.

In addition to the ADO.NET data provider, the following new features 
have also been added:

     A begin() method has been added to the client API's to compliment 
the commit() and rollback() methods.
     A waitfordowndatabase parameter has been added to sqlrelay.conf to 
control SQL Relay's behavior when the database it's talking to has gone 
down.

The following bugs have also been fixed:

     Applied Georgiy Kirichenko's missing flushWriteBuffer() patch.
     Some subtle bugs in the Ruby DBI adapter that modern versions of 
Ruby DBI reveal.
     Fixed a race condition in the sqlr-scaler that could occur when 
connections="0" is set in the sqlrelay.conf file.
     Applied some ODBC fixes from Chae Young-ku.
     Fixed the debug option to the query command line client.
     Fixed an outstanding TCL api bug that caused cursors not to get 
created.
     Fixed several outstanding bugs regarding escaping of quotes.

Try it out and report any problems you have!

David Muse
dav...@fi...

Re: [Sqlrelay-discussion] Bug in SQLRelay.pm

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

Yeah, I discovered the same bug a while back and it's fixed in CVS but 
not in any release yet.  Here's the code for that function in CVS if you 
want to patch your version:

sub last_insert_id {

	# get parameters
	my ($dbh)=@_;

	# get the last insert id
	return $dbh->FETCH('driver_connection')->getLastInsertId();
}

It's an obscure function.  Only a few databases support it.  I think it 
returns the internal row id of the most recent insert done in the 
current transaction.  Something like that.

I'm probably a week or so out from the next release and it should have 
this fix in it.

David Muse
dav...@fi...

On 08/09/2012 06:46 PM, Stephen Carville wrote:
> In sqlrelay version 0.45, the function last_insert_id is missing the
> declaration for $dbh;
>
> sub last_insert_id {
>
>      # ignore parameters
>
>      # get the last insert id
>      return $dbh->FETCH('driver_connection')->getLastInsertId();
> }
>
>
> I'm not sure what uses it.
>

[Sqlrelay-discussion] Bug in SQLRelay.pm

[Stephen C. <sca...@le...>]

In sqlrelay version 0.45, the function last_insert_id is missing the 
declaration for $dbh;

sub last_insert_id {

    # ignore parameters

    # get the last insert id
    return $dbh->FETCH('driver_connection')->getLastInsertId();
}


I'm not sure what uses it.

-- 
Stephen

Non est salvatori salvator.
Neque defensori vir.
Nec pater, nec mater,
nihil supernum.

Re: [Sqlrelay-discussion] Client killed during transaction

[Ville S. <vil...@gm...>]

Hi Dave,

Sounds like that will solve the issue. Thanks for your time!

Ville

On 27 July 2012 17:43, David Muse <dav...@fi...> wrote:

> If the client process is killed, then SQL Relay's behavior is determined
> by the endofsession paramter in the sqlrelay.conf file:
>
> <instance id="oracleexample" ... endofsession="commit" ...>
>     ...
> </instance>
>
> If it is set to "commit" then SQL Relay will issue a commit when the
> client disconnects.  If it is set to "rollback" then SQL Relay will
> issue a rollback when the client disconnects.  Currently, SQL Relay
> doesn't check to see whether the client disconnected on purpose or not
> though.
>
> To get the behavior you're looking for, you could probably set
> endofsession="rollback" in sqlrelay.conf and then make sure that your
> app issues commit()'s itself for any transactions that it doesn't want
> automatically rolled-back.
>
> Let me know if this answers your question or not.
>
> Dave
> dav...@fi...
>
> On 07/11/2012 11:26 AM, Ville Silventoinen wrote:
> > Hi,
> >
> > What does SQL Relay connection do if the client process is killed
> > (either with SIGTERM or SIGKILL) during a transaction?
> >
> > I realize that this is probably database specific. I've run couple of
> > tests using SQL Relay 0.43 (C API) and Oracle 11.2.0. My client program
> > does this:
> >
> > 1. Start a transaction (auto-commit off).
> > 2. Delete a row.
> > 3. Sleep 60 seconds.
> > 4. Commit.
> >
> > During the 60 seconds I have killed the program either using "kill" and
> > "kill -9". In both cases the transaction has been committed. I also
> > tried shutting down SQL Relay. Again, the transaction is committed. I
> > found this slightly surprising, I thought the transaction would be
> > rolled back.
> >
> > This may be how Oracle behaves. I'd just like to understand what SQL
> > Relay connection does when the client process is killed. Does it close
> > the connection? In Oracle documentation
> > (http://docs.oracle.com/cd/B28359_01/server.111/b28318/transact.htm), it
> > says:
> >
> > ---
> > A transaction ends when any of the following occurs:
> >
> > - A user issues a COMMIT or ROLLBACK statement without a SAVEPOINT
> clause.
> >
> > - A user runs a DDL statement such as CREATE, DROP, RENAME, or ALTER. If
> > the current transaction contains any DML statements, Oracle Database
> > first commits the transaction, and then runs and commits the DDL
> > statement as a new, single statement transaction.
> >
> > - A user disconnects from Oracle Database. The current transaction is
> > committed.
> >
> > - A user process terminates abnormally. The current transaction is
> > rolled back.
> > ---
> >
> > So if SQL Relay disconnects from Oracle when the client is killed, the
> > current transaction is committed. Would there be a way to configure SQL
> > Relay to do a rollback instead if it notices that auto-commit is off and
> > commit hasn't been done?
> >
> > I guess Oracle would actually do a rollback if the SQL Relay connection
> > process would terminate "abnormally".
> >
> > Many thanks for any advice,
> > Ville
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond. Discussions
> > will include endpoint security, mobile security and the latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >
> >
> >
> > _______________________________________________
> > Sqlrelay-discussion mailing list
> > Sql...@li...
> > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion
> >
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Sqlrelay-discussion mailing list
> Sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion
>

Re: [Sqlrelay-discussion] Problems with Database

[Diemisom M. <dca...@gm...>]

Thank's David,
I realised that my procedure was printing some debug infos.

I just inserted a comment statement and it was solved.

-- 
Diemisom Melo

Re: [Sqlrelay-discussion] Fail over for SQL relay - release 0.45

[David D. <dav...@gm...>]

I had the same problem about a year ago, asked basically the same question,
and got no response.

Good luck to you though.


On Wed, May 30, 2012 at 4:43 AM, findjaimin <fin...@gm...> wrote:

> Hi,
>   I am using SQL relay between my php app and Mysql database*s*.
> Following is the configuration file.
>
> <?xml version="1.0"?>
> <!DOCTYPE instances SYSTEM "sqlrelay.dtd">
>
> <instances>
>
>         <!-- Regular SQL Relay Instance -->
>         <instance id="example" port="7000"
> socket="/home/Jaimin/relay.sock" dbase="mysql" connections="10"
> maxconnections="25" maxqueuelength="5" growby="5" ttl="1"
> maxsessioncount="10000" endofsession="commit" sessiontimeout="600"
> runasuser="Jaimin" runasgroup="Jaimin" cursors="5" maxcursors="10"
> cursors_growby="10" authtier="listener" handoff="pass" deniedips=""
> allowedips="" debug="none" maxquerysize="65536"
> maxstringbindvaluelength="4000" maxlobbindvaluelength="71680"
> idleclienttimeout="-1" maxlisteners="-1" listenertimeout="0"
> reloginatstart="no" timequeriessec="-1" timequeriesusec="-1"
> fakeinputbindvariables="no" translatebindvariables="no"
> isolationlevel="read committed" ignoreselectdatabase="no">
>                 <users>
>                         <user user="jaimin" password="password"/>
>                 </users>
>                 <connections>
>                         <connection connectionid="db1"
> string="user=jaimin;password=password;db=schema;host=172.29.5.169"
> metric="1" behindloadbalancer="no"/>
>                         <connection connectionid="db2"
> string="user=jaimin;password=password;db=schema;host=172.29.5.169;port=3308"
> metric="1" behindloadbalancer="no"/>
>                 </connections>
>         </instance>
> </instances>
>
>  My problem is : When mysql referenced by connectionid db2 goes down,
> every second request sent by php gets error "Can't connect to MySQL server
> on '172.29.5.169' (111)" . However as mentioned in this (
> http://sqlrelay.sourceforge.net/sqlrelay/loadbalfailover.html ) link it
> should just *mark* connection(s) of db2 as *unavailable to clients*.
> Means, my php app will never get error..instead it will have smaller pool
> of connections so may be some performance impact. I am using release # 0.45.
>
> Am I missing something in achieving following behaviour as mentioned in
> http://sqlrelay.sourceforge.net/sqlrelay/loadbalfailover.html ? :
> "Currently, if an SQL Relay connection daemon notices that the database
> server it is connected to has gone down it will mark itself unavailable to
> clients, log out and loop, attempting to re-connect to that database
> server. If that connection daemon is configured with the *
> behindloadbalancer* attribute set to "no", then it will also raise a flag
> and all connection daemons connected to that database server mark
> themselves unavailable to clients, close their connections and loop,
> attempting to re-connect to that database server. When the database server
> comes back up, as each connection daemon successfully re-connects to the
> database server, it marks itself available to clients again. While one
> database server is down, client sessions are still distributed over the
> servers that are still up, albiet through a smaller pool of persistent
> database connections."
>
>
> Thanks,
> Jaimin
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Sqlrelay-discussion mailing list
> Sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion
>
>

Re: [Sqlrelay-discussion] sqlrelay 0.45 and mysql 5.1.62 C++ -- bind problem

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

I believe that MySQL uses ?'s as placeholders for bind variables.

So, you would need to write your queries like:

cur->prepareQuery("select * from testtable2 where id=?");
cur->inputBind("1",1);
cur->executeQuery();

Note the use of "1" rather than "id1".  When using ?'s, you must use 
1,2,3, etc. for the variable name.

Alternatively, there is a parameter in the sqlrelay.conf file called 
"translatebindvariables" which defaults to no, but if you set 
translatebindvariables="yes" then it will basically allow you to use any 
style of bind variables you like and dynamically rewrite the queries on 
the server-side as appropriate.  There is a performance penalty for 
this, but it's not very large.

Let me know if this helps or not.

David Muse
dav...@fi...

On 07/27/2012 01:22 AM, Vishal Shah (GDC) wrote:
> hello,
>
> I am new to sqlrelay and have the following query on using the bind
> variables of mysql using sqlrelay. the version of distributions i am
> using is mentioned in the subject
>
> I am using the C++ api of sqlrelay.
>
> I prepare a mysql statement as below (please not that I use `@'
> instead of `:' mentioned in the tutorial, as `:' was giving MySQL
> errors)
>
> cur->prepareQuery ("select * from testtable2 where id=@id1");
> cur->inputBind("id1",1);
> cur->executeQuery ();
>
> While the above three statements don't generate any errors, I don't
> get the results.
>
> If I did
>
>
> cur->prepareQuery ("select * from testtable2 where id=:id1");
> cur->inputBind("id1",1);
> cur->executeQuery ();
>
> MySQL generated errors as in Wrong Syntax.
>
> Anything that I would have missed? sqlrconnection, sqlrcursor are
> properly initialized and if I do:
>
> cur->prepareQuery ("select * from testtable2 where id=1");
> cur->executeQuery ();
>
> i do get the results.
>
> SQLRelay Experts, please guide.
>
> Regards,
>
> BIC
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Sqlrelay-discussion mailing list
> Sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion
>

Re: [Sqlrelay-discussion] maxcursors size

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

Hi Sagar,

No, unfortunately there is currently no way to change it dynamically.  I 
have recently gotten several requests to be able to change parameters 
like that at runtime, but the internal SQL Relay architecture makes it a 
little difficult at present.  I have plans to fix this, but have not 
implemented them yet.

If being able to modify that (or other) parameters on the fly is very 
important to you, then I'd be happy to implement a method for changing 
them on a contract basis.  Feel free to contact me directly about this.

David Muse
dav...@fi...

On 07/27/2012 12:57 AM, sagar salian wrote:
> hi,
>
> In SQL relay can we dynamically change the "maxcursors" size. is there
> any apis
> available for that.
>
> thank you
>
> --
> with regards,
> SAGAR
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
>
> _______________________________________________
> Sqlrelay-discussion mailing list
> Sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion
>

Re: [Sqlrelay-discussion] Problems with Database answer

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

Yes, I can help.

Are you testing with your own program or sqlrsh?

If you are testing with your own program, then try sqlrsh.  If it works 
properly, then could you post the code and your sqlrelay.conf file?

If sqlrsh doesn't work, then could you copy/paste your sqlrsh session, 
including the command line you used to run sqlrsh and your sqlrelay.conf 
file?

 From that info, I should be able to figure out what's going on.

Thanks,

David Muse
dav...@fi...

On 07/17/2012 11:10 AM, Diemisom Melo wrote:
> Hi all,
>
> I can't receive the answer of the database. It sends one row with 2
> cols but the debug in sqlrelay shows some messages like:
>
> commit or rollback check...
> commit or rollback needed
> done with commit or rollback check
> processing query failed
> done processing query
> handling error...
> returning error...
> failed to handle query: error
> done returning error
> done handling error...
> getting command...
> done getting command
>
> Could you help me?
>

Re: [Sqlrelay-discussion] Client killed during transaction

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

If the client process is killed, then SQL Relay's behavior is determined 
by the endofsession paramter in the sqlrelay.conf file:

<instance id="oracleexample" ... endofsession="commit" ...>
    ...
</instance>

If it is set to "commit" then SQL Relay will issue a commit when the 
client disconnects.  If it is set to "rollback" then SQL Relay will 
issue a rollback when the client disconnects.  Currently, SQL Relay 
doesn't check to see whether the client disconnected on purpose or not 
though.

To get the behavior you're looking for, you could probably set 
endofsession="rollback" in sqlrelay.conf and then make sure that your 
app issues commit()'s itself for any transactions that it doesn't want 
automatically rolled-back.

Let me know if this answers your question or not.

Dave
dav...@fi...

On 07/11/2012 11:26 AM, Ville Silventoinen wrote:
> Hi,
>
> What does SQL Relay connection do if the client process is killed
> (either with SIGTERM or SIGKILL) during a transaction?
>
> I realize that this is probably database specific. I've run couple of
> tests using SQL Relay 0.43 (C API) and Oracle 11.2.0. My client program
> does this:
>
> 1. Start a transaction (auto-commit off).
> 2. Delete a row.
> 3. Sleep 60 seconds.
> 4. Commit.
>
> During the 60 seconds I have killed the program either using "kill" and
> "kill -9". In both cases the transaction has been committed. I also
> tried shutting down SQL Relay. Again, the transaction is committed. I
> found this slightly surprising, I thought the transaction would be
> rolled back.
>
> This may be how Oracle behaves. I'd just like to understand what SQL
> Relay connection does when the client process is killed. Does it close
> the connection? In Oracle documentation
> (http://docs.oracle.com/cd/B28359_01/server.111/b28318/transact.htm), it
> says:
>
> ---
> A transaction ends when any of the following occurs:
>
> - A user issues a COMMIT or ROLLBACK statement without a SAVEPOINT clause.
>
> - A user runs a DDL statement such as CREATE, DROP, RENAME, or ALTER. If
> the current transaction contains any DML statements, Oracle Database
> first commits the transaction, and then runs and commits the DDL
> statement as a new, single statement transaction.
>
> - A user disconnects from Oracle Database. The current transaction is
> committed.
>
> - A user process terminates abnormally. The current transaction is
> rolled back.
> ---
>
> So if SQL Relay disconnects from Oracle when the client is killed, the
> current transaction is committed. Would there be a way to configure SQL
> Relay to do a rollback instead if it notices that auto-commit is off and
> commit hasn't been done?
>
> I guess Oracle would actually do a rollback if the SQL Relay connection
> process would terminate "abnormally".
>
> Many thanks for any advice,
> Ville
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
>
> _______________________________________________
> Sqlrelay-discussion mailing list
> Sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion
>

Re: [Sqlrelay-discussion] sqlrelay 0.45 and php 5.3.X don't mix

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

Interesting.  The line that the error is occurring on is:

	return stmt->result->sqlrcur->affectedRows();

My guess is that stmt, result or sqlrcur is NULL, but I'm not sure why 
it would be.  If you could you post a short PHP program that causes the 
error and the exact set of steps that you used to run it through GDB, 
then I can find out what's happening and fix it.

David Muse
dav...@fi...

On 07/11/2012 08:47 AM, mailing lists wrote:
> Hello,
>
> I'm testing sqlrelay 0.45 (compiled against MySQL 5.1.63) with php 5.3.14 and all that I got is an apache coredump. The sqlrelay installation itself seems work appropriately as mysql client with LD_PRELOAD executes all SQL queries and returns the results.
>
> Below I post some fragments so list members can help to determine the problem, it seems something related with mysql command response.
>
> any hint about this case?
>
>
>
> # ldd /usr/lib64/php5/extensions/mysql.so
> ldd: warning: you do not have execution permission for `/usr/lib64/php5/extensions/mysql.so'
>          linux-vdso.so.1 =>  (0x00007fff3ab02000)
>          libmysql50sqlrelay-0.45.so.1 => /usr/lib64/libmysql50sqlrelay-0.45.so.1 (0x00007fa1494e3000)
>          libsqlrclient-0.45.so.1 => /usr/lib64/libsqlrclient-0.45.so.1 (0x00007fa1492c5000)
>          librudiments-0.36.1.so.1 => /usr/lib64/librudiments-0.36.1.so.1 (0x00007fa149044000)
>          libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa148e27000)
>          libssl.so.1.0.0 => /lib64/libssl.so.1.0.0 (0x00007fa148bca000)
>          libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 (0x00007fa148818000)
>          libz.so.1 => /lib64/libz.so.1 (0x00007fa148600000)
>          libpcre.so.0 => /lib64/libpcre.so.0 (0x00007fa1483c9000)
>          librt.so.1 => /lib64/librt.so.1 (0x00007fa1481c0000)
>          libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fa147f86000)
>          libdl.so.2 => /lib64/libdl.so.2 (0x00007fa147d81000)
>          libc.so.6 => /lib64/libc.so.6 (0x00007fa147a14000)
>          libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fa14770b000)
>          libm.so.6 => /lib64/libm.so.6 (0x00007fa1474b3000)
>          libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fa14729d000)
>          /lib64/ld-linux-x86-64.so.2 (0x00007fa149912000)
>
>
> # cat /etc/sqlrelay.conf
> <?xml version="1.0"?>
> <!DOCTYPE instances SYSTEM "sqlrelay.dtd">
>
> <instances>
>
>      <instance id="test-sqlrelay"
>                    port="9000"
>                    dbase="mysql"
>                    connections="2"
>                    maxconnections="15"
>                    maxqueuelength="5"
>                    growby="1"
>                    ttl="60"
>                    maxsessioncount="1000"
>                    endofsession="commit"
>                    sessiontimeout="600"
>                    runasuser="sqlrelay"
>                    runasgroup="sqlrelay"
>                    cursors="5"
>                    maxcursors="10"
>                    cursors_growby="1"
>                    authtier="listener"
>                    handoff="reconnect"
>                    deniedips=""
>                    allowedips=".*"
>                    debug="listener_and_connection_and_sqltranslation"
>                    maxquerysize="65536"
>                    maxstringbindvaluelength="4000"
>                    maxlobbindvaluelength="71680"
>                    idleclienttimeout="-1"
>                    maxlisteners="-1"
>                    listenertimeout="10"
>                    reloginatstart="yes"
>                    timequeriessec="0"
>                    timequeriesusec="0"
>                    fakeinputbindvariables="no"
>                    translatebindvariables="no"
>                    isolationlevel="read committed"
>                    ignoreselectdatabase="yes">
>           <users>
>                    <user user="user1" password="password1"/>
>                    <user user="user2" password="password2"/>
>                    <user user="user3" password="password3"/>
>           </users>
>           <connections>
>                    <connection connectionid="test" string="host=dbserver;user=test;password=12345678;db=testdb;" metric="1" behindloadbalancer="no"/>
>            </connections>
>       </instance>
> </instances>
>
>
>
> # cat sqlr-connection.25113
> 07/11/2012 12:04:10 CEST connection [25113] : attaching to shared memory and semaphores
> 07/11/2012 12:04:10 CEST connection [25113] : id filename:
> 07/11/2012 12:04:10 CEST connection [25113] : /var/sqlrelay/tmp/ipc/test-sqlrelay
> 07/11/2012 12:04:10 CEST connection [25113] :   attaching to shared memory...
> 07/11/2012 12:04:10 CEST connection [25113] :   attaching to semaphores...
> 07/11/2012 12:04:10 CEST connection [25113] : done attaching to shared memory and semaphores
> 07/11/2012 12:04:10 CEST connection [25114] : logging in...
> 07/11/2012 12:04:10 CEST connection [25114] : done logging in
> 07/11/2012 12:04:10 CEST connection [25114] : setting autocommit...
> 07/11/2012 12:04:10 CEST connection [25114] : done setting autocommit
> 07/11/2012 12:04:10 CEST connection [25114] : initializing cursors...
> 07/11/2012 12:04:10 CEST connection [25114] :   0
> 07/11/2012 12:04:10 CEST connection [25114] :   1
> 07/11/2012 12:04:10 CEST connection [25114] :   2
> 07/11/2012 12:04:10 CEST connection [25114] :   3
> 07/11/2012 12:04:10 CEST connection [25114] :   4
> 07/11/2012 12:04:10 CEST connection [25114] : done initializing cursors
> 07/11/2012 12:04:10 CEST connection [25114] : incrementing connection count...
> 07/11/2012 12:04:10 CEST connection [25114] :   acquiring connection count mutex
> 07/11/2012 12:04:10 CEST connection [25114] :   done acquiring connection count mutex
> 07/11/2012 12:04:10 CEST connection [25114] :   1
> 07/11/2012 12:04:10 CEST connection [25114] :   releasing connection count mutex
> 07/11/2012 12:04:10 CEST connection [25114] :   done releasing connection count mutex
> 07/11/2012 12:04:10 CEST connection [25114] : done incrementing connection count
> 07/11/2012 12:04:10 CEST connection [25114] :                           creating /var/sqlrelay/tmp/ipc/test-sqlrelay-host4
> 07/11/2012 12:04:10 CEST connection [25114] : waiting for available database...
> 07/11/2012 12:04:10 CEST connection [25114] : database is available
> 07/11/2012 12:04:10 CEST connection [25114] : database is available
> 07/11/2012 12:04:10 CEST connection [25114] : initializing session...
> 07/11/2012 12:04:10 CEST connection [25114] : done initializing session...
> 07/11/2012 12:04:10 CEST connection [25114] : announcing availability...
> 07/11/2012 12:04:10 CEST connection [25114] : registering for handoff...
> 07/11/2012 12:04:10 CEST connection [25114] :   handoffsockname: /var/sqlrelay/tmp/sockets/host4-sqlrelay-handoff
> 07/11/2012 12:04:10 CEST connection [25114] :   trying...
> 07/11/2012 12:04:10 CEST connection [25114] : done registering for handoff
> 07/11/2012 12:04:10 CEST connection [25114] :   acquiring announce mutex
> 07/11/2012 12:04:10 CEST connection [25114] :   done acquiring announce mutex
> 07/11/2012 12:04:10 CEST connection [25114] :   handoff=pass
> 07/11/2012 12:04:10 CEST connection [25114] :   signalling listener to read
> 07/11/2012 12:04:10 CEST connection [25114] :   done signalling listener to read
> 07/11/2012 12:04:10 CEST connection [25114] :   waiting for listener
> 07/11/2012 12:06:24 CEST connection [25114] :   done waiting for listener
> 07/11/2012 12:06:24 CEST connection [25114] :   releasing announce mutex
> 07/11/2012 12:06:24 CEST connection [25114] :   done releasing announce mutex
> 07/11/2012 12:06:24 CEST connection [25114] : done announcing availability...
> 07/11/2012 12:06:24 CEST connection [25114] : waiting for client...
> 07/11/2012 12:06:24 CEST connection [25114] :   pass succeeded
> 07/11/2012 12:06:24 CEST connection [25114] : done waiting for client
> 07/11/2012 12:06:24 CEST connection [25114] : client session...
> 07/11/2012 12:06:24 CEST connection [25114] : incrementing client session count...
> 07/11/2012 12:06:24 CEST connection [25114] : done incrementing client session count...
> 07/11/2012 12:06:24 CEST connection [25114] :   getting command...
> 07/11/2012 12:06:24 CEST connection [25114] :   done getting command
> 07/11/2012 12:06:24 CEST connection [25114] :   authenticate
> 07/11/2012 12:06:24 CEST connection [25114] :   authenticate...
> 07/11/2012 12:06:24 CEST connection [25114] :   authentication was done on listener
> 07/11/2012 12:06:24 CEST connection [25114] :   getting command...
> 07/11/2012 12:06:24 CEST connection [25114] :   done getting command
> 07/11/2012 12:06:24 CEST connection [25114] :   select database
> 07/11/2012 12:06:24 CEST connection [25114] :   getting command...
> 07/11/2012 12:06:24 CEST connection [25114] :   done getting command
> 07/11/2012 12:06:24 CEST connection [25114] :   getting a cursor...
> 07/11/2012 12:06:24 CEST connection [25114] :           available cursor:
> 07/11/2012 12:06:24 CEST connection [25114] :                   0
> 07/11/2012 12:06:24 CEST connection [25114] :   done getting a cursor
> 07/11/2012 12:06:24 CEST connection [25114] :   new query
> 07/11/2012 12:06:24 CEST connection [25114] :   handling query...
> 07/11/2012 12:06:24 CEST connection [25114] :           getting query...
> 07/11/2012 12:06:24 CEST connection [25114] :                   querylength:
> 07/11/2012 12:06:24 CEST connection [25114] :                           18
> 07/11/2012 12:06:24 CEST connection [25114] :                   query:
> 07/11/2012 12:06:24 CEST connection [25114] : SHOW CHARACTER SET
> 07/11/2012 12:06:24 CEST connection [25114] :           getting query succeeded
> 07/11/2012 12:06:24 CEST connection [25114] :           getting input binds...
> 07/11/2012 12:06:24 CEST connection [25114] :           done getting input binds
> 07/11/2012 12:06:24 CEST connection [25114] :           getting output binds...
> 07/11/2012 12:06:24 CEST connection [25114] :           done getting output binds
> 07/11/2012 12:06:24 CEST connection [25114] :           getting send column info...
> 07/11/2012 12:06:24 CEST connection [25114] :                   send column info
> 07/11/2012 12:06:24 CEST connection [25114] :           done getting send column info...
> 07/11/2012 12:06:24 CEST connection [25114] :           processing query...
> 07/11/2012 12:06:24 CEST connection [25114] :                   preparing/executing...
> 07/11/2012 12:06:24 CEST connection [25114] :           commit or rollback check...
> 07/11/2012 12:06:24 CEST connection [25114] :                   commit or rollback needed
> 07/11/2012 12:06:24 CEST connection [25114] :           done with commit or rollback check
> 07/11/2012 12:06:24 CEST connection [25114] :           processing query succeeded
> 07/11/2012 12:06:24 CEST connection [25114] :           done processing query
> 07/11/2012 12:06:24 CEST connection [25114] :           returning result set header...
> 07/11/2012 12:06:24 CEST connection [25114] :                   returning row counts...
> 07/11/2012 12:06:24 CEST connection [25114] :           sending row counts...
> 07/11/2012 12:06:24 CEST connection [25114] :                   actual rows: 36
> 07/11/2012 12:06:24 CEST connection [25114] :                   affected rows: -1
> 07/11/2012 12:06:24 CEST connection [25114] :           done sending row counts
> 07/11/2012 12:06:24 CEST connection [25114] :                   done returning row counts
> 07/11/2012 12:06:24 CEST connection [25114] :                   column info will be sent
> 07/11/2012 12:06:24 CEST connection [25114] :                   returning column counts...
> 07/11/2012 12:06:24 CEST connection [25114] :                   done returning column counts
> 07/11/2012 12:06:24 CEST connection [25114] :           sending column type format...
> 07/11/2012 12:06:24 CEST connection [25114] :                   id's
> 07/11/2012 12:06:24 CEST connection [25114] :           done sending column type format
> 07/11/2012 12:06:24 CEST connection [25114] :                   returning column info...
> 07/11/2012 12:06:24 CEST connection [25114] :                   Charset:1:97 (96,0) NOT NULL
> 07/11/2012 12:06:24 CEST connection [25114] :                   Description:1:181 (180,0) NOT NULL
> 07/11/2012 12:06:24 CEST connection [25114] :                   Default collation:1:97 (96,0) NOT NULL
> 07/11/2012 12:06:24 CEST connection [25114] :                   Maxlen:55:8 (3,0) NOT NULL
> 07/11/2012 12:06:24 CEST connection [25114] :                   done returning column info
> 07/11/2012 12:06:24 CEST connection [25114] :           returning output bind values
> 07/11/2012 12:06:24 CEST connection [25114] :                   0
> 07/11/2012 12:06:24 CEST connection [25114] :           done returning output bind values
> 07/11/2012 12:06:24 CEST connection [25114] :           done returning result set header
> 07/11/2012 12:06:24 CEST connection [25114] :   handle query succeeded
> 07/11/2012 12:06:24 CEST connection [25114] :           returning result set data...
> 07/11/2012 12:06:24 CEST connection [25114] :           skipping 0 rows...
> 07/11/2012 12:06:24 CEST connection [25114] :           done skipping rows
> 07/11/2012 12:06:24 CEST connection [25114] :           fetching 0 rows...
> 07/11/2012 12:06:24 CEST connection [25114] :                   "big5","Big5 Traditional Chinese","big5_chinese_ci","2",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "dec8","DEC West European","dec8_swedish_ci","1",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "cp850","DOS West European","cp850_general_ci","1",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "hp8","HP West European","hp8_english_ci","1",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "koi8r","KOI8-R Relcom Russian","koi8r_general_ci","1",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "latin1","cp1252 West European","latin1_swedish_ci","1",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "latin2","ISO 8859-2 Central European","latin2_general_ci","1",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "swe7","7bit Swedish","swe7_swedish_ci","1",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "ascii","US ASCII","ascii_general_ci","1",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "ujis","EUC-JP Japanese","ujis_japanese_ci","3",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "sjis","Shift-JIS Japanese","sjis_japanese_ci","2",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "hebrew","ISO 8859-8 Hebrew","hebrew_general_ci","1",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "tis620","TIS620 Thai","tis620_thai_ci","1",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "euckr","EUC-KR Korean","euckr_korean_ci","2",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "koi8u","KOI8-U Ukrainian","koi8u_general_ci","1",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "gb2312","GB2312 Simplified Chinese","gb2312_chinese_ci","2",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "greek","ISO 8859-7 Greek","greek_general_ci","1",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "cp1250","Windows Central European","cp1250_general_ci","1",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "gbk","GBK Simplified Chinese","gbk_chinese_ci","2",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "latin5","ISO 8859-9 Turkish","latin5_turkish_ci","1",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "armscii8","ARMSCII-8 Armenian","armscii8_general_ci","1",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "utf8","UTF-8 Unicode","utf8_general_ci","3",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "ucs2","UCS-2 Unicode","ucs2_general_ci","2",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "cp866","DOS Russian","cp866_general_ci","1",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "keybcs2","DOS Kamenicky Czech-Slovak","keybcs2_general_ci","1",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "macce","Mac Central European","macce_general_ci","1",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "macroman","Mac West European","macroman_general_ci","1",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "cp852","DOS Central European","cp852_general_ci","1",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "latin7","ISO 8859-13 Baltic","latin7_general_ci","1",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "cp1251","Windows Cyrillic","cp1251_general_ci","1",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "cp1256","Windows Arabic","cp1256_general_ci","1",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "cp1257","Windows Baltic","cp1257_general_ci","1",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "binary","Binary pseudo charset","binary","1",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "geostd8","GEOSTD8 Georgian","geostd8_general_ci","1",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "cp932","SJIS for Windows Japanese","cp932_japanese_ci","2",
> 07/11/2012 12:06:24 CEST connection [25114] :                   "eucjpms","UJIS for Windows Japanese","eucjpms_japanese_ci","3",
> 07/11/2012 12:06:24 CEST connection [25114] :           done returning result set data
> 07/11/2012 12:06:24 CEST connection [25114] :   getting command...
> 07/11/2012 12:06:52 CEST connection [25114] :   getting command failed: client sent bad command or timed out
> 07/11/2012 12:06:52 CEST connection [25114] :   end session
> 07/11/2012 12:06:52 CEST connection [25114] :           ending session...
> 07/11/2012 12:06:52 CEST connection [25114] :           aborting all busy cursors...
> 07/11/2012 12:06:52 CEST connection [25114] :                   0
> 07/11/2012 12:06:52 CEST connection [25114] :           done aborting all busy cursors
> 07/11/2012 12:06:52 CEST connection [25114] :           committing...
> 07/11/2012 12:06:52 CEST connection [25114] :           done committing...
> 07/11/2012 12:06:52 CEST connection [25114] : setting autocommit...
> 07/11/2012 12:06:52 CEST connection [25114] : done setting autocommit
> 07/11/2012 12:06:52 CEST connection [25114] :   done ending session
> 07/11/2012 12:06:52 CEST connection [25114] :   waiting for client to close the connection...
> 07/11/2012 12:06:52 CEST connection [25114] :   done waiting for client to close the connection...
> 07/11/2012 12:06:52 CEST connection [25114] :   closing sockets from a previously suspended session...
> 07/11/2012 12:06:52 CEST connection [25114] :   done closing sockets from a previously suspended session...
> 07/11/2012 12:06:52 CEST connection [25114] : decrementing client session count...
> 07/11/2012 12:06:52 CEST connection [25114] : done decrementing client session count...
> 07/11/2012 12:06:52 CEST connection [25114] : done with client session
> 07/11/2012 12:06:52 CEST connection [25114] : decrementing session count...
> 07/11/2012 12:06:52 CEST connection [25114] :   acquiring session count mutex
> 07/11/2012 12:06:52 CEST connection [25114] :   done acquiring session count mutex
> 07/11/2012 12:06:52 CEST connection [25114] :   0
> 07/11/2012 12:06:52 CEST connection [25114] :   releasing session count mutex
> 07/11/2012 12:06:52 CEST connection [25114] :   done releasing session count mutex
> 07/11/2012 12:06:52 CEST connection [25114] : done decrementing session count
> 07/11/2012 12:06:52 CEST connection [25114] : waiting for available database...
> 07/11/2012 12:06:52 CEST connection [25114] : database is available
> 07/11/2012 12:06:52 CEST connection [25114] : database is available
> 07/11/2012 12:06:52 CEST connection [25114] : initializing session...
> 07/11/2012 12:06:52 CEST connection [25114] : done initializing session...
> 07/11/2012 12:06:52 CEST connection [25114] : announcing availability...
> 07/11/2012 12:06:52 CEST connection [25114] :   acquiring announce mutex
> (gdb) where
>
> #0  0x00007f17bcb22513 in mysql_stmt_affected_rows (stmt=0x7f17c70e46f0) at mysql.cpp:2122
> #1  0x00007f17bcd2fd40 in zif_mysql_affected_rows (ht=<value optimized out>, return_value=0x7f17c7568f20, return_value_ptr=<value optimized out>,
>      this_ptr=<value optimized out>, return_value_used=<value optimized out>) at /usr/src/packages/BUILD/php-5.3.14/ext/mysql/php_mysql.c:1788
> #2  0x00007f17c1bd985d in zend_do_fcall_common_helper_SPEC (execute_data=0x7f17c6868d20) at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_vm_execute.h:320
> #3  0x00007f17c1bb2834 in execute (op_array=0x7f17c75f03a8) at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_vm_execute.h:107
> #4  0x00007f17c1b7f910 in zend_call_function (fci=0x7fff3c906ea0, fci_cache=<value optimized out>)
>      at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_execute_API.c:969
> #5  0x00007f17c1acdec7 in zif_call_user_func_array (ht=<value optimized out>, return_value=0x7f17c7580de8, return_value_ptr=<value optimized out>,
>      this_ptr=<value optimized out>, return_value_used=<value optimized out>) at /usr/src/packages/BUILD/php-5.3.14/ext/standard/basic_functions.c:4814
> #6  0x00007f17c1bd985d in zend_do_fcall_common_helper_SPEC (execute_data=0x7f17c6868808) at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_vm_execute.h:320
> #7  0x00007f17c1bb2834 in execute (op_array=0x7f17c76235f0) at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_vm_execute.h:107
> #8  0x00007f17c1b7f910 in zend_call_function (fci=0x7fff3c9071e0, fci_cache=<value optimized out>)
>      at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_execute_API.c:969
> #9  0x00007f17c1ba2f97 in zend_call_method (object_pp=0x7fff3c907308, obj_ce=<value optimized out>, fn_proxy=0x7f17c75f3dc8,
>      function_name=0x7f17c1c5e168 "__call", function_name_len=<value optimized out>, retval_ptr_ptr=0x7fff3c907318, param_count=2, arg1=0x7f17c7580e48,
>      arg2=0x7f17c7580b88) at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_interfaces.c:97
> #10 0x00007f17c1bad7ce in zend_std_call_user_call (ht=<value optimized out>, return_value=0x7f17c7580b58, return_value_ptr=<value optimized out>,
>      this_ptr=0x7f17a8cb7580, return_value_used=<value optimized out>) at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_object_handlers.c:717
> #11 0x00007f17c1bd985d in zend_do_fcall_common_helper_SPEC (execute_data=0x7f17c6868480) at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_vm_execute.h:320
> #12 0x00007f17c1bb2834 in execute (op_array=0x7f17c72ce450) at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_vm_execute.h:107
> #13 0x00007f17c1b7f910 in zend_call_function (fci=0x7fff3c9075e0, fci_cache=<value optimized out>)
>      at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_execute_API.c:969
> #14 0x00007f17c1acdec7 in zif_call_user_func_array (ht=<value optimized out>, return_value=0x7f17c7580af8, return_value_ptr=<value optimized out>,
>      this_ptr=<value optimized out>, return_value_used=<value optimized out>) at /usr/src/packages/BUILD/php-5.3.14/ext/standard/basic_functions.c:4814
> #15 0x00007f17c1bd985d in zend_do_fcall_common_helper_SPEC (execute_data=0x7f17c6867a60) at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_vm_execute.h:320
> #16 0x00007f17c1bb2834 in execute (op_array=0x7f17c761e850) at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_vm_execute.h:107
> #17 0x00007f17c1b7f910 in zend_call_function (fci=0x7fff3c907920, fci_cache=<value optimized out>)
>      at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_execute_API.c:969
> #18 0x00007f17c1ba2f97 in zend_call_method (object_pp=0x7fff3c907a48, obj_ce=<value optimized out>, fn_proxy=0x7f17c75b14b0,
>      function_name=0x7f17c1c5e168 "__call", function_name_len=<value optimized out>, retval_ptr_ptr=0x7fff3c907a58, param_count=2, arg1=0x7f17c75d0a70,
>      arg2=0x7f17c7576370) at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_interfaces.c:97
> #19 0x00007f17c1bad7ce in zend_std_call_user_call (ht=<value optimized out>, return_value=0x7f17c758a590, return_value_ptr=<value optimized out>,
>      this_ptr=0x7f17c758a2b8, return_value_used=<value optimized out>) at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_object_handlers.c:717
> #20 0x00007f17c1bd985d in zend_do_fcall_common_helper_SPEC (execute_data=0x7f17c6867410) at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_vm_execute.h:320
> #21 0x00007f17c1bb2834 in execute (op_array=0x7f17c75effc8) at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_vm_execute.h:107
> #22 0x00007f17c1b8df16 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/packages/BUILD/php-5.3.14/Zend/zend.c:1236
> #23 0x00007f17c1b36273 in php_execute_script (primary_file=0x7fff3c909fe0) at /usr/src/packages/BUILD/php-5.3.14/main/main.c:2308
> #24 0x00007f17c1c21e4d in php_handler (r=0x7f17c6fa1450) at /usr/src/packages/BUILD/php-5.3.14/sapi/apache2handler/sapi_apache2.c:669
> #25 0x00007f17c69cde08 in ap_run_handler ()
> #26 0x00007f17c69ce26c in ap_invoke_handler ()
> #27 0x00007f17c69dbf00 in ap_process_request ()
> #28 0x00007f17c69d8e98 in ?? ()
> #29 0x00007f17c69d4b28 in ap_run_process_connection ()
> #30 0x00007f17c69e0e5a in ?? ()
> #31 0x00007f17c69e116a in ?? ()
> #32 0x00007f17c69e1227 in ?? ()
> #33 0x00007f17c69e1b75 in ap_mpm_run ()
> #34 0x00007f17c69b89be in main ()
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> 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
>

[Sqlrelay-discussion] sqlrelay 0.45 and mysql 5.1.62 C++ -- bind problem

[Vishal S. (GDC) <gdc...@gm...>]

hello,

I am new to sqlrelay and have the following query on using the bind
variables of mysql using sqlrelay. the version of distributions i am
using is mentioned in the subject

I am using the C++ api of sqlrelay.

I prepare a mysql statement as below (please not that I use `@'
instead of `:' mentioned in the tutorial, as `:' was giving MySQL
errors)

cur->prepareQuery ("select * from testtable2 where id=@id1");
cur->inputBind("id1",1);
cur->executeQuery ();

While the above three statements don't generate any errors, I don't
get the results.

If I did


cur->prepareQuery ("select * from testtable2 where id=:id1");
cur->inputBind("id1",1);
cur->executeQuery ();

MySQL generated errors as in Wrong Syntax.

Anything that I would have missed? sqlrconnection, sqlrcursor are
properly initialized and if I do:

cur->prepareQuery ("select * from testtable2 where id=1");
cur->executeQuery ();

i do get the results.

SQLRelay Experts, please guide.

Regards,

BIC

[Sqlrelay-discussion] maxcursors size

[sagar s. <sag...@gm...>]

hi,

In SQL relay can we dynamically change the "maxcursors" size. is there any
apis
available for that.

thank you

-- 
with regards,
SAGAR

[Sqlrelay-discussion] Problems with Database answer

[Diemisom M. <dca...@gm...>]

Hi all,

I can't receive the answer of the database. It sends one row with 2
cols but the debug in sqlrelay shows some messages like:

commit or rollback check...
commit or rollback needed
done with commit or rollback check
processing query failed
done processing query
handling error...
returning error...
failed to handle query: error
done returning error
done handling error...
getting command...
done getting command

Could you help me?

-- 
Diemisom Melo

[Sqlrelay-discussion] Client killed during transaction

[Ville S. <vil...@gm...>]

Hi,

What does SQL Relay connection do if the client process is killed (either
with SIGTERM or SIGKILL) during a transaction?

I realize that this is probably database specific. I've run couple of tests
using SQL Relay 0.43 (C API) and Oracle 11.2.0. My client program does this:

1. Start a transaction (auto-commit off).
2. Delete a row.
3. Sleep 60 seconds.
4. Commit.

During the 60 seconds I have killed the program either using "kill" and
"kill -9". In both cases the transaction has been committed. I also tried
shutting down SQL Relay. Again, the transaction is committed. I found this
slightly surprising, I thought the transaction would be rolled back.

This may be how Oracle behaves. I'd just like to understand what SQL Relay
connection does when the client process is killed. Does it close the
connection? In Oracle documentation (
http://docs.oracle.com/cd/B28359_01/server.111/b28318/transact.htm), it
says:

---
A transaction ends when any of the following occurs:

- A user issues a COMMIT or ROLLBACK statement without a SAVEPOINT clause.

- A user runs a DDL statement such as CREATE, DROP, RENAME, or ALTER. If
the current transaction contains any DML statements, Oracle Database first
commits the transaction, and then runs and commits the DDL statement as a
new, single statement transaction.

- A user disconnects from Oracle Database. The current transaction is
committed.

- A user process terminates abnormally. The current transaction is rolled
back.
---

So if SQL Relay disconnects from Oracle when the client is killed, the
current transaction is committed. Would there be a way to configure SQL
Relay to do a rollback instead if it notices that auto-commit is off and
commit hasn't been done?

I guess Oracle would actually do a rollback if the SQL Relay connection
process would terminate "abnormally".

Many thanks for any advice,
Ville

[Sqlrelay-discussion] sqlrelay 0.45 and php 5.3.X don't mix

[mailing l. <lis...@ya...>]

Hello,

I'm testing sqlrelay 0.45 (compiled against MySQL 5.1.63) with php 5.3.14 and all that I got is an apache coredump. The sqlrelay installation itself seems work appropriately as mysql client with LD_PRELOAD executes all SQL queries and returns the results.

Below I post some fragments so list members can help to determine the problem, it seems something related with mysql command response.

any hint about this case?



# ldd /usr/lib64/php5/extensions/mysql.so 
ldd: warning: you do not have execution permission for `/usr/lib64/php5/extensions/mysql.so'
        linux-vdso.so.1 =>  (0x00007fff3ab02000)
        libmysql50sqlrelay-0.45.so.1 => /usr/lib64/libmysql50sqlrelay-0.45.so.1 (0x00007fa1494e3000)
        libsqlrclient-0.45.so.1 => /usr/lib64/libsqlrclient-0.45.so.1 (0x00007fa1492c5000)
        librudiments-0.36.1.so.1 => /usr/lib64/librudiments-0.36.1.so.1 (0x00007fa149044000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa148e27000)
        libssl.so.1.0.0 => /lib64/libssl.so.1.0.0 (0x00007fa148bca000)
        libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 (0x00007fa148818000)
        libz.so.1 => /lib64/libz.so.1 (0x00007fa148600000)
        libpcre.so.0 => /lib64/libpcre.so.0 (0x00007fa1483c9000)
        librt.so.1 => /lib64/librt.so.1 (0x00007fa1481c0000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fa147f86000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fa147d81000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fa147a14000)
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fa14770b000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fa1474b3000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fa14729d000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fa149912000)


# cat /etc/sqlrelay.conf
<?xml version="1.0"?>
<!DOCTYPE instances SYSTEM "sqlrelay.dtd">

<instances>

    <instance id="test-sqlrelay" 
                  port="9000" 
                  dbase="mysql" 
                  connections="2" 
                  maxconnections="15" 
                  maxqueuelength="5" 
                  growby="1" 
                  ttl="60" 
                  maxsessioncount="1000" 
                  endofsession="commit" 
                  sessiontimeout="600" 
                  runasuser="sqlrelay" 
                  runasgroup="sqlrelay" 
                  cursors="5" 
                  maxcursors="10" 
                  cursors_growby="1" 
                  authtier="listener" 
                  handoff="reconnect" 
                  deniedips="" 
                  allowedips=".*" 
                  debug="listener_and_connection_and_sqltranslation" 
                  maxquerysize="65536" 
                  maxstringbindvaluelength="4000" 
                  maxlobbindvaluelength="71680" 
                  idleclienttimeout="-1" 
                  maxlisteners="-1" 
                  listenertimeout="10" 
                  reloginatstart="yes" 
                  timequeriessec="0" 
                  timequeriesusec="0" 
                  fakeinputbindvariables="no" 
                  translatebindvariables="no" 
                  isolationlevel="read committed" 
                  ignoreselectdatabase="yes">
         <users>
                  <user user="user1" password="password1"/>
                  <user user="user2" password="password2"/>
                  <user user="user3" password="password3"/>
         </users>
         <connections>
                  <connection connectionid="test" string="host=dbserver;user=test;password=12345678;db=testdb;" metric="1" behindloadbalancer="no"/>
          </connections>
     </instance>
</instances>



# cat sqlr-connection.25113
07/11/2012 12:04:10 CEST connection [25113] : attaching to shared memory and semaphores
07/11/2012 12:04:10 CEST connection [25113] : id filename: 
07/11/2012 12:04:10 CEST connection [25113] : /var/sqlrelay/tmp/ipc/test-sqlrelay
07/11/2012 12:04:10 CEST connection [25113] :   attaching to shared memory...
07/11/2012 12:04:10 CEST connection [25113] :   attaching to semaphores...
07/11/2012 12:04:10 CEST connection [25113] : done attaching to shared memory and semaphores
07/11/2012 12:04:10 CEST connection [25114] : logging in...
07/11/2012 12:04:10 CEST connection [25114] : done logging in
07/11/2012 12:04:10 CEST connection [25114] : setting autocommit...
07/11/2012 12:04:10 CEST connection [25114] : done setting autocommit
07/11/2012 12:04:10 CEST connection [25114] : initializing cursors...
07/11/2012 12:04:10 CEST connection [25114] :   0
07/11/2012 12:04:10 CEST connection [25114] :   1
07/11/2012 12:04:10 CEST connection [25114] :   2
07/11/2012 12:04:10 CEST connection [25114] :   3
07/11/2012 12:04:10 CEST connection [25114] :   4
07/11/2012 12:04:10 CEST connection [25114] : done initializing cursors
07/11/2012 12:04:10 CEST connection [25114] : incrementing connection count...
07/11/2012 12:04:10 CEST connection [25114] :   acquiring connection count mutex
07/11/2012 12:04:10 CEST connection [25114] :   done acquiring connection count mutex
07/11/2012 12:04:10 CEST connection [25114] :   1
07/11/2012 12:04:10 CEST connection [25114] :   releasing connection count mutex
07/11/2012 12:04:10 CEST connection [25114] :   done releasing connection count mutex
07/11/2012 12:04:10 CEST connection [25114] : done incrementing connection count
07/11/2012 12:04:10 CEST connection [25114] :                           creating /var/sqlrelay/tmp/ipc/test-sqlrelay-host4
07/11/2012 12:04:10 CEST connection [25114] : waiting for available database...
07/11/2012 12:04:10 CEST connection [25114] : database is available
07/11/2012 12:04:10 CEST connection [25114] : database is available
07/11/2012 12:04:10 CEST connection [25114] : initializing session...
07/11/2012 12:04:10 CEST connection [25114] : done initializing session...
07/11/2012 12:04:10 CEST connection [25114] : announcing availability...
07/11/2012 12:04:10 CEST connection [25114] : registering for handoff...
07/11/2012 12:04:10 CEST connection [25114] :   handoffsockname: /var/sqlrelay/tmp/sockets/host4-sqlrelay-handoff
07/11/2012 12:04:10 CEST connection [25114] :   trying...
07/11/2012 12:04:10 CEST connection [25114] : done registering for handoff
07/11/2012 12:04:10 CEST connection [25114] :   acquiring announce mutex
07/11/2012 12:04:10 CEST connection [25114] :   done acquiring announce mutex
07/11/2012 12:04:10 CEST connection [25114] :   handoff=pass
07/11/2012 12:04:10 CEST connection [25114] :   signalling listener to read
07/11/2012 12:04:10 CEST connection [25114] :   done signalling listener to read
07/11/2012 12:04:10 CEST connection [25114] :   waiting for listener
07/11/2012 12:06:24 CEST connection [25114] :   done waiting for listener
07/11/2012 12:06:24 CEST connection [25114] :   releasing announce mutex
07/11/2012 12:06:24 CEST connection [25114] :   done releasing announce mutex
07/11/2012 12:06:24 CEST connection [25114] : done announcing availability...
07/11/2012 12:06:24 CEST connection [25114] : waiting for client...
07/11/2012 12:06:24 CEST connection [25114] :   pass succeeded
07/11/2012 12:06:24 CEST connection [25114] : done waiting for client
07/11/2012 12:06:24 CEST connection [25114] : client session...
07/11/2012 12:06:24 CEST connection [25114] : incrementing client session count...
07/11/2012 12:06:24 CEST connection [25114] : done incrementing client session count...
07/11/2012 12:06:24 CEST connection [25114] :   getting command...
07/11/2012 12:06:24 CEST connection [25114] :   done getting command
07/11/2012 12:06:24 CEST connection [25114] :   authenticate
07/11/2012 12:06:24 CEST connection [25114] :   authenticate...
07/11/2012 12:06:24 CEST connection [25114] :   authentication was done on listener
07/11/2012 12:06:24 CEST connection [25114] :   getting command...
07/11/2012 12:06:24 CEST connection [25114] :   done getting command
07/11/2012 12:06:24 CEST connection [25114] :   select database
07/11/2012 12:06:24 CEST connection [25114] :   getting command...
07/11/2012 12:06:24 CEST connection [25114] :   done getting command
07/11/2012 12:06:24 CEST connection [25114] :   getting a cursor...
07/11/2012 12:06:24 CEST connection [25114] :           available cursor:
07/11/2012 12:06:24 CEST connection [25114] :                   0
07/11/2012 12:06:24 CEST connection [25114] :   done getting a cursor
07/11/2012 12:06:24 CEST connection [25114] :   new query
07/11/2012 12:06:24 CEST connection [25114] :   handling query...
07/11/2012 12:06:24 CEST connection [25114] :           getting query...
07/11/2012 12:06:24 CEST connection [25114] :                   querylength:
07/11/2012 12:06:24 CEST connection [25114] :                           18
07/11/2012 12:06:24 CEST connection [25114] :                   query:
07/11/2012 12:06:24 CEST connection [25114] : SHOW CHARACTER SET
07/11/2012 12:06:24 CEST connection [25114] :           getting query succeeded
07/11/2012 12:06:24 CEST connection [25114] :           getting input binds...
07/11/2012 12:06:24 CEST connection [25114] :           done getting input binds
07/11/2012 12:06:24 CEST connection [25114] :           getting output binds...
07/11/2012 12:06:24 CEST connection [25114] :           done getting output binds
07/11/2012 12:06:24 CEST connection [25114] :           getting send column info...
07/11/2012 12:06:24 CEST connection [25114] :                   send column info
07/11/2012 12:06:24 CEST connection [25114] :           done getting send column info...
07/11/2012 12:06:24 CEST connection [25114] :           processing query...
07/11/2012 12:06:24 CEST connection [25114] :                   preparing/executing...
07/11/2012 12:06:24 CEST connection [25114] :           commit or rollback check...
07/11/2012 12:06:24 CEST connection [25114] :                   commit or rollback needed
07/11/2012 12:06:24 CEST connection [25114] :           done with commit or rollback check
07/11/2012 12:06:24 CEST connection [25114] :           processing query succeeded
07/11/2012 12:06:24 CEST connection [25114] :           done processing query
07/11/2012 12:06:24 CEST connection [25114] :           returning result set header...
07/11/2012 12:06:24 CEST connection [25114] :                   returning row counts...
07/11/2012 12:06:24 CEST connection [25114] :           sending row counts...
07/11/2012 12:06:24 CEST connection [25114] :                   actual rows: 36
07/11/2012 12:06:24 CEST connection [25114] :                   affected rows: -1
07/11/2012 12:06:24 CEST connection [25114] :           done sending row counts
07/11/2012 12:06:24 CEST connection [25114] :                   done returning row counts
07/11/2012 12:06:24 CEST connection [25114] :                   column info will be sent
07/11/2012 12:06:24 CEST connection [25114] :                   returning column counts...
07/11/2012 12:06:24 CEST connection [25114] :                   done returning column counts
07/11/2012 12:06:24 CEST connection [25114] :           sending column type format...
07/11/2012 12:06:24 CEST connection [25114] :                   id's
07/11/2012 12:06:24 CEST connection [25114] :           done sending column type format
07/11/2012 12:06:24 CEST connection [25114] :                   returning column info...
07/11/2012 12:06:24 CEST connection [25114] :                   Charset:1:97 (96,0) NOT NULL 
07/11/2012 12:06:24 CEST connection [25114] :                   Description:1:181 (180,0) NOT NULL 
07/11/2012 12:06:24 CEST connection [25114] :                   Default collation:1:97 (96,0) NOT NULL 
07/11/2012 12:06:24 CEST connection [25114] :                   Maxlen:55:8 (3,0) NOT NULL 
07/11/2012 12:06:24 CEST connection [25114] :                   done returning column info
07/11/2012 12:06:24 CEST connection [25114] :           returning output bind values
07/11/2012 12:06:24 CEST connection [25114] :                   0
07/11/2012 12:06:24 CEST connection [25114] :           done returning output bind values
07/11/2012 12:06:24 CEST connection [25114] :           done returning result set header
07/11/2012 12:06:24 CEST connection [25114] :   handle query succeeded
07/11/2012 12:06:24 CEST connection [25114] :           returning result set data...
07/11/2012 12:06:24 CEST connection [25114] :           skipping 0 rows...
07/11/2012 12:06:24 CEST connection [25114] :           done skipping rows
07/11/2012 12:06:24 CEST connection [25114] :           fetching 0 rows...
07/11/2012 12:06:24 CEST connection [25114] :                   "big5","Big5 Traditional Chinese","big5_chinese_ci","2",
07/11/2012 12:06:24 CEST connection [25114] :                   "dec8","DEC West European","dec8_swedish_ci","1",
07/11/2012 12:06:24 CEST connection [25114] :                   "cp850","DOS West European","cp850_general_ci","1",
07/11/2012 12:06:24 CEST connection [25114] :                   "hp8","HP West European","hp8_english_ci","1",
07/11/2012 12:06:24 CEST connection [25114] :                   "koi8r","KOI8-R Relcom Russian","koi8r_general_ci","1",
07/11/2012 12:06:24 CEST connection [25114] :                   "latin1","cp1252 West European","latin1_swedish_ci","1",
07/11/2012 12:06:24 CEST connection [25114] :                   "latin2","ISO 8859-2 Central European","latin2_general_ci","1",
07/11/2012 12:06:24 CEST connection [25114] :                   "swe7","7bit Swedish","swe7_swedish_ci","1",
07/11/2012 12:06:24 CEST connection [25114] :                   "ascii","US ASCII","ascii_general_ci","1",
07/11/2012 12:06:24 CEST connection [25114] :                   "ujis","EUC-JP Japanese","ujis_japanese_ci","3",
07/11/2012 12:06:24 CEST connection [25114] :                   "sjis","Shift-JIS Japanese","sjis_japanese_ci","2",
07/11/2012 12:06:24 CEST connection [25114] :                   "hebrew","ISO 8859-8 Hebrew","hebrew_general_ci","1",
07/11/2012 12:06:24 CEST connection [25114] :                   "tis620","TIS620 Thai","tis620_thai_ci","1",
07/11/2012 12:06:24 CEST connection [25114] :                   "euckr","EUC-KR Korean","euckr_korean_ci","2",
07/11/2012 12:06:24 CEST connection [25114] :                   "koi8u","KOI8-U Ukrainian","koi8u_general_ci","1",
07/11/2012 12:06:24 CEST connection [25114] :                   "gb2312","GB2312 Simplified Chinese","gb2312_chinese_ci","2",
07/11/2012 12:06:24 CEST connection [25114] :                   "greek","ISO 8859-7 Greek","greek_general_ci","1",
07/11/2012 12:06:24 CEST connection [25114] :                   "cp1250","Windows Central European","cp1250_general_ci","1",
07/11/2012 12:06:24 CEST connection [25114] :                   "gbk","GBK Simplified Chinese","gbk_chinese_ci","2",
07/11/2012 12:06:24 CEST connection [25114] :                   "latin5","ISO 8859-9 Turkish","latin5_turkish_ci","1",
07/11/2012 12:06:24 CEST connection [25114] :                   "armscii8","ARMSCII-8 Armenian","armscii8_general_ci","1",
07/11/2012 12:06:24 CEST connection [25114] :                   "utf8","UTF-8 Unicode","utf8_general_ci","3",
07/11/2012 12:06:24 CEST connection [25114] :                   "ucs2","UCS-2 Unicode","ucs2_general_ci","2",
07/11/2012 12:06:24 CEST connection [25114] :                   "cp866","DOS Russian","cp866_general_ci","1",
07/11/2012 12:06:24 CEST connection [25114] :                   "keybcs2","DOS Kamenicky Czech-Slovak","keybcs2_general_ci","1",
07/11/2012 12:06:24 CEST connection [25114] :                   "macce","Mac Central European","macce_general_ci","1",
07/11/2012 12:06:24 CEST connection [25114] :                   "macroman","Mac West European","macroman_general_ci","1",
07/11/2012 12:06:24 CEST connection [25114] :                   "cp852","DOS Central European","cp852_general_ci","1",
07/11/2012 12:06:24 CEST connection [25114] :                   "latin7","ISO 8859-13 Baltic","latin7_general_ci","1",
07/11/2012 12:06:24 CEST connection [25114] :                   "cp1251","Windows Cyrillic","cp1251_general_ci","1",
07/11/2012 12:06:24 CEST connection [25114] :                   "cp1256","Windows Arabic","cp1256_general_ci","1",
07/11/2012 12:06:24 CEST connection [25114] :                   "cp1257","Windows Baltic","cp1257_general_ci","1",
07/11/2012 12:06:24 CEST connection [25114] :                   "binary","Binary pseudo charset","binary","1",
07/11/2012 12:06:24 CEST connection [25114] :                   "geostd8","GEOSTD8 Georgian","geostd8_general_ci","1",
07/11/2012 12:06:24 CEST connection [25114] :                   "cp932","SJIS for Windows Japanese","cp932_japanese_ci","2",
07/11/2012 12:06:24 CEST connection [25114] :                   "eucjpms","UJIS for Windows Japanese","eucjpms_japanese_ci","3",
07/11/2012 12:06:24 CEST connection [25114] :           done returning result set data
07/11/2012 12:06:24 CEST connection [25114] :   getting command...
07/11/2012 12:06:52 CEST connection [25114] :   getting command failed: client sent bad command or timed out
07/11/2012 12:06:52 CEST connection [25114] :   end session
07/11/2012 12:06:52 CEST connection [25114] :           ending session...
07/11/2012 12:06:52 CEST connection [25114] :           aborting all busy cursors...
07/11/2012 12:06:52 CEST connection [25114] :                   0
07/11/2012 12:06:52 CEST connection [25114] :           done aborting all busy cursors
07/11/2012 12:06:52 CEST connection [25114] :           committing...
07/11/2012 12:06:52 CEST connection [25114] :           done committing...
07/11/2012 12:06:52 CEST connection [25114] : setting autocommit...
07/11/2012 12:06:52 CEST connection [25114] : done setting autocommit
07/11/2012 12:06:52 CEST connection [25114] :   done ending session
07/11/2012 12:06:52 CEST connection [25114] :   waiting for client to close the connection...
07/11/2012 12:06:52 CEST connection [25114] :   done waiting for client to close the connection...
07/11/2012 12:06:52 CEST connection [25114] :   closing sockets from a previously suspended session...
07/11/2012 12:06:52 CEST connection [25114] :   done closing sockets from a previously suspended session...
07/11/2012 12:06:52 CEST connection [25114] : decrementing client session count...
07/11/2012 12:06:52 CEST connection [25114] : done decrementing client session count...
07/11/2012 12:06:52 CEST connection [25114] : done with client session
07/11/2012 12:06:52 CEST connection [25114] : decrementing session count...
07/11/2012 12:06:52 CEST connection [25114] :   acquiring session count mutex
07/11/2012 12:06:52 CEST connection [25114] :   done acquiring session count mutex
07/11/2012 12:06:52 CEST connection [25114] :   0
07/11/2012 12:06:52 CEST connection [25114] :   releasing session count mutex
07/11/2012 12:06:52 CEST connection [25114] :   done releasing session count mutex
07/11/2012 12:06:52 CEST connection [25114] : done decrementing session count
07/11/2012 12:06:52 CEST connection [25114] : waiting for available database...
07/11/2012 12:06:52 CEST connection [25114] : database is available
07/11/2012 12:06:52 CEST connection [25114] : database is available
07/11/2012 12:06:52 CEST connection [25114] : initializing session...
07/11/2012 12:06:52 CEST connection [25114] : done initializing session...
07/11/2012 12:06:52 CEST connection [25114] : announcing availability...
07/11/2012 12:06:52 CEST connection [25114] :   acquiring announce mutex
(gdb) where

#0  0x00007f17bcb22513 in mysql_stmt_affected_rows (stmt=0x7f17c70e46f0) at mysql.cpp:2122
#1  0x00007f17bcd2fd40 in zif_mysql_affected_rows (ht=<value optimized out>, return_value=0x7f17c7568f20, return_value_ptr=<value optimized out>, 
    this_ptr=<value optimized out>, return_value_used=<value optimized out>) at /usr/src/packages/BUILD/php-5.3.14/ext/mysql/php_mysql.c:1788
#2  0x00007f17c1bd985d in zend_do_fcall_common_helper_SPEC (execute_data=0x7f17c6868d20) at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_vm_execute.h:320
#3  0x00007f17c1bb2834 in execute (op_array=0x7f17c75f03a8) at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_vm_execute.h:107
#4  0x00007f17c1b7f910 in zend_call_function (fci=0x7fff3c906ea0, fci_cache=<value optimized out>)
    at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_execute_API.c:969
#5  0x00007f17c1acdec7 in zif_call_user_func_array (ht=<value optimized out>, return_value=0x7f17c7580de8, return_value_ptr=<value optimized out>, 
    this_ptr=<value optimized out>, return_value_used=<value optimized out>) at /usr/src/packages/BUILD/php-5.3.14/ext/standard/basic_functions.c:4814
#6  0x00007f17c1bd985d in zend_do_fcall_common_helper_SPEC (execute_data=0x7f17c6868808) at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_vm_execute.h:320
#7  0x00007f17c1bb2834 in execute (op_array=0x7f17c76235f0) at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_vm_execute.h:107
#8  0x00007f17c1b7f910 in zend_call_function (fci=0x7fff3c9071e0, fci_cache=<value optimized out>)
    at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_execute_API.c:969
#9  0x00007f17c1ba2f97 in zend_call_method (object_pp=0x7fff3c907308, obj_ce=<value optimized out>, fn_proxy=0x7f17c75f3dc8, 
    function_name=0x7f17c1c5e168 "__call", function_name_len=<value optimized out>, retval_ptr_ptr=0x7fff3c907318, param_count=2, arg1=0x7f17c7580e48, 
    arg2=0x7f17c7580b88) at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_interfaces.c:97
#10 0x00007f17c1bad7ce in zend_std_call_user_call (ht=<value optimized out>, return_value=0x7f17c7580b58, return_value_ptr=<value optimized out>, 
    this_ptr=0x7f17a8cb7580, return_value_used=<value optimized out>) at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_object_handlers.c:717
#11 0x00007f17c1bd985d in zend_do_fcall_common_helper_SPEC (execute_data=0x7f17c6868480) at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_vm_execute.h:320
#12 0x00007f17c1bb2834 in execute (op_array=0x7f17c72ce450) at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_vm_execute.h:107
#13 0x00007f17c1b7f910 in zend_call_function (fci=0x7fff3c9075e0, fci_cache=<value optimized out>)
    at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_execute_API.c:969
#14 0x00007f17c1acdec7 in zif_call_user_func_array (ht=<value optimized out>, return_value=0x7f17c7580af8, return_value_ptr=<value optimized out>, 
    this_ptr=<value optimized out>, return_value_used=<value optimized out>) at /usr/src/packages/BUILD/php-5.3.14/ext/standard/basic_functions.c:4814
#15 0x00007f17c1bd985d in zend_do_fcall_common_helper_SPEC (execute_data=0x7f17c6867a60) at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_vm_execute.h:320
#16 0x00007f17c1bb2834 in execute (op_array=0x7f17c761e850) at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_vm_execute.h:107
#17 0x00007f17c1b7f910 in zend_call_function (fci=0x7fff3c907920, fci_cache=<value optimized out>)
    at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_execute_API.c:969
#18 0x00007f17c1ba2f97 in zend_call_method (object_pp=0x7fff3c907a48, obj_ce=<value optimized out>, fn_proxy=0x7f17c75b14b0, 
    function_name=0x7f17c1c5e168 "__call", function_name_len=<value optimized out>, retval_ptr_ptr=0x7fff3c907a58, param_count=2, arg1=0x7f17c75d0a70, 
    arg2=0x7f17c7576370) at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_interfaces.c:97
#19 0x00007f17c1bad7ce in zend_std_call_user_call (ht=<value optimized out>, return_value=0x7f17c758a590, return_value_ptr=<value optimized out>, 
    this_ptr=0x7f17c758a2b8, return_value_used=<value optimized out>) at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_object_handlers.c:717
#20 0x00007f17c1bd985d in zend_do_fcall_common_helper_SPEC (execute_data=0x7f17c6867410) at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_vm_execute.h:320
#21 0x00007f17c1bb2834 in execute (op_array=0x7f17c75effc8) at /usr/src/packages/BUILD/php-5.3.14/Zend/zend_vm_execute.h:107
#22 0x00007f17c1b8df16 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/packages/BUILD/php-5.3.14/Zend/zend.c:1236
#23 0x00007f17c1b36273 in php_execute_script (primary_file=0x7fff3c909fe0) at /usr/src/packages/BUILD/php-5.3.14/main/main.c:2308
#24 0x00007f17c1c21e4d in php_handler (r=0x7f17c6fa1450) at /usr/src/packages/BUILD/php-5.3.14/sapi/apache2handler/sapi_apache2.c:669
#25 0x00007f17c69cde08 in ap_run_handler ()
#26 0x00007f17c69ce26c in ap_invoke_handler ()
#27 0x00007f17c69dbf00 in ap_process_request ()
#28 0x00007f17c69d8e98 in ?? ()
#29 0x00007f17c69d4b28 in ap_run_process_connection ()
#30 0x00007f17c69e0e5a in ?? ()
#31 0x00007f17c69e116a in ?? ()
#32 0x00007f17c69e1227 in ?? ()
#33 0x00007f17c69e1b75 in ap_mpm_run ()
#34 0x00007f17c69b89be in main ()