sqlrelay-discussion Mailing List for SQL Relay (Page 46)
Brought to you by:
mused
Menu
▾
▴
sqlrelay-discussion — Discussion of topics related to SQL Relay
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
(20) |
Mar
(27) |
Apr
(17) |
May
(32) |
Jun
(45) |
Jul
(49) |
Aug
(68) |
Sep
(44) |
Oct
(29) |
Nov
(64) |
Dec
(25) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(61) |
Feb
(22) |
Mar
(25) |
Apr
(31) |
May
(18) |
Jun
(28) |
Jul
(19) |
Aug
(16) |
Sep
(8) |
Oct
(17) |
Nov
(32) |
Dec
(4) |
| 2007 |
Jan
(20) |
Feb
(25) |
Mar
(5) |
Apr
(12) |
May
(11) |
Jun
(18) |
Jul
(16) |
Aug
(22) |
Sep
(37) |
Oct
(20) |
Nov
(11) |
Dec
(2) |
| 2008 |
Jan
(11) |
Feb
(33) |
Mar
(12) |
Apr
(18) |
May
(22) |
Jun
(31) |
Jul
(23) |
Aug
(6) |
Sep
|
Oct
(10) |
Nov
(22) |
Dec
|
| 2009 |
Jan
(12) |
Feb
(8) |
Mar
(11) |
Apr
(20) |
May
(18) |
Jun
(7) |
Jul
(27) |
Aug
(2) |
Sep
(10) |
Oct
(5) |
Nov
(2) |
Dec
(1) |
| 2010 |
Jan
(11) |
Feb
(18) |
Mar
(10) |
Apr
(28) |
May
(28) |
Jun
|
Jul
(27) |
Aug
(9) |
Sep
(21) |
Oct
(2) |
Nov
(2) |
Dec
(11) |
| 2011 |
Jan
|
Feb
(2) |
Mar
(4) |
Apr
(2) |
May
(2) |
Jun
(44) |
Jul
(9) |
Aug
(2) |
Sep
(12) |
Oct
(7) |
Nov
(11) |
Dec
(7) |
| 2012 |
Jan
(5) |
Feb
|
Mar
(9) |
Apr
(9) |
May
(12) |
Jun
|
Jul
(13) |
Aug
(3) |
Sep
(3) |
Oct
(1) |
Nov
(1) |
Dec
(10) |
| 2013 |
Jan
(21) |
Feb
(3) |
Mar
(4) |
Apr
|
May
(3) |
Jun
(2) |
Jul
(3) |
Aug
(3) |
Sep
(3) |
Oct
|
Nov
|
Dec
(4) |
| 2014 |
Jan
(7) |
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
|
Jul
(4) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: David M. <dav...@fi...> - 2006-01-31 15:58:44
|
Yeah, there's just the one line: uses (u)int[16|32]_t instead of short/long, etc. Which covers some changes I made to the C/C++ api's. Those changes percolated up to the other api's too. But, you're right, it's not very explicit. And there isn't a line about changing rowCount to a 64 bit integer from a 32 bit. I'll add some lines like that. In C/C++, on 32-bit machines, a "long" is 32 bits and a "long long" is 64 bits. On 64-bit machines, both are 64 bits. I was running into problems in a 64bit-host/32bit-client (or vice-versa) environment, so I had to switch "long" to int32_t and "long long" to int64_t. While I was at it, I switched "short" to int16_t, got rid of "int" references (which could be either 16 or 32 bits depending on the platform) and made a few values 64 bit, such as the row count. Sorry about the incompatibility, but I don't imagine it will change again before 1.0 Dave On Tue, 2006-01-31 at 12:58 +0100, Maciej Wisniowski wrote: > Hi > > I've now switched to SQLRelay 0.37pre5 and > found some changes that caused my old code was not > working. > These are changes in SQLRConnection constructor (port > is now short not int), and in rowCount (returns long not int). > I think these things should be listed in changelog, or maybe > they are there but in a inplicit way? > |
|
From: David M. <dav...@fi...> - 2006-01-31 15:45:35
|
On Tue, 2006-01-31 at 10:36 -0200, Rodrigo P. Telles wrote: > Hi David, > > David Muse wrote: > > Long queries should actually mean queries that are longer than 32k > > characters. A query with only 397 characters or so shouldn't cause a > > problem. I vaguely remember an issue like this though, and if it's what > > I remember, I think I fixed it in 0.36. Is it possible for you to > > upgrade SQL Relay to more current version? If so, try > > http://www.firstworks.com/sqlrelay-0.37pre5.tar.gz or sqlrelay-0.36.4 > > from the sqlrelay website and see if the problem still persists. If it > > does (or if you can't easily upgrade), then let me know and I'll see if > > I can get you some code with debug in it and we'll patch the version > > you're running now. > > > I'm using 0.36.4 in a test box and the problem happens too. > I upgraded to 0.37pre5 but it's not possible to run my Java code, a lot > of types of constructors changed and it will be necessary to change all > Java code :-( > > best regards, > > Telles Yeah, I'm sorry about that. A while ago, I started using short, long, long long, unsigned short, etc. datatypes, assuming that short would be 16 bits, long would be 32 bits and long long would be 64 bits. At the time, they were, on every platform that I'd encountered. When x86_64 platforms started coming out people pointed out to me that both "long" and "long long" datatypes were 64 bits. This caused problems when the SQL Relay server was running on a 64 bit machine, talking to a 32 bit client or vice-versa. In this release, I bit the bullet and switched all the datatypes to explicit int16_t, int32_t, int64_t, etc. and the change percolated up through all of the different api's. While I was at it, I changed some variables that had previously been 32 bit to 64 bit, such as row count and got rid of the last remaining "int" types which could be either 16 bit or 32 bit depending on the platform. I don't imagine that any of the function signatures will change again before 1.0. Dave > > Dave > > dav...@fi... > > > > On Wed, 2006-01-04 at 10:34 -0200, Rodrigo P. Telles wrote: > > > >> Hi David, > >> > >> At last I think we (our team) found a cause of the exception! > >> > >> I think there was a misunderstood from my part in that answer (about > >> "long queries"). > >> I understood "long queries" as "long result sets" - and not the lenght > >> of the queries - when in fact the queries has about 397-580 characters. > >> I don't know if it's big enough to be considered "long" but it's the > >> cause of the problem. If we changes that long queries to small ones > >> (selecting or updating only 3 fields instead of 34) the problem go away > >> and everything works fine. > >> > >> Problematic query: > >> > >> SELECT phplib_id, username, domain, password, first_name, last_name, > >> phone, email_address, datetime_created, datetime_modified, confirmation, > >> flag, sendnotification, greeting, ha1, ha1b, perms, allow_find, > >> timezone, rpid, empresa, codInscricao, numInscricao, endereco, bairro, > >> cep, cidade, estado, pais, listaPublica, sigame, temSigame, status, > >> macAddress FROM subscriber WHERE username='2740' > >> > >> Solution query: > >> > >> SELECT phplib_id, username, first_name FROM subscriber WHERE username='2740' > >> > >> So as you said perhaps it's easy to patch. > >> We'll test with how many fields the query starts to generate an exception. > >> > >> best regards, > >> Telles > >> > >> Rodrigo P. Telles wrote: > >> > >> > >>> Hi David, > >>> > >>> Firstworks/4access wrote: > >>> > >>> > >>>> Is it possible to reliably reproduce the problem with a particular > >>>> query, or is it kind of random? > >>>> > >>> No it doesn't, it happens in a random fashion. Could happens twice in > >>> a week or > >>> once in a month. > >>> > >>> > >>>> Offhand, it looks like java is trying to run (or return from) a native > >>>> C++ function and has the wrong address for the function (or wrong return > >>>> address) and it ends up jumping off into the weeds, possibly into a > >>>> non-executable page of memory. This typically happens when a buffer > >>>> overrun occurs and overwrites a jump address. > >>>> > >>>> Does this happen with really long queries? With > >>>> > >>> No it doesn't. > >>> It happens in a simple query using INSERT or SELECT! > >>> > >>> > >>>> Java/Perl/PHP/Ruby/TCL/Python, SQL Relay makes a copy of the query. > >>>> It's possible that there's some kind of bug where the SQL Relay client > >>>> is copying too much data and overrunning it's buffer. If it's only long > >>>> queries, that would make sense and should be easy to patch. > >>>> > >>>> Let me know... > >>>> > >>> Let me know if I can do any thing to "collect" more informations about > >>> that problem. > >>> Thanks for your answer. > >>> > >>> Telles > >>> > >>> > >>>> David Muse > >>>> dav...@fi... > >>>> > >>>> On Fri, 2005-11-11 at 17:48 -0200, Rodrigo P. Telles wrote: > >>>> > >>>> Hi Guys, > >>>> > >>>> I've been experiencing some errors using JAVA with sqlrelay-0.35 API > >>>> > >>> and MySQL > >>> > >>>> 4.1.7 as a DB backend. > >>>> > >>>> Some thimes when I'm doing a query the application failed with that > >>>> > >>> output > >>> > >>>> exception: > >>>> ---------------------------------------------------------------------------------- > >>>> An unexpected exception has been detected in native code outside the VM. > >>>> Unexpected Signal : 11 occurred at PC=0x400C6C48 > >>>> Function=(null)+0x400C6C48 > >>>> Library=/lib/libc.so.6 > >>>> > >>>> NOTE: We are unable to locate the function name symbol for the error > >>>> just occurred. Please refer to release documentation for possible > >>>> reason and solutions. > >>>> > >>> > >>>> Current Java thread: > >>>> at com.firstworks.sqlrelay.SQLRCursor.prepareQuery(Native Method) > >>>> at it.devel.Dao.getBean(Dao.java:185) > >>>> at > >>>> > >>> it.devel.wiser.TerminadorDAO.calculaMinutagem(TerminadorDAO.java:131) > >>> > >>>> at it.devel.Bilhetagem.getTempoCorrigido(Bilhetagem.java:342) > >>>> at it.devel.Bilhetagem.bilhetaTerminador(Bilhetagem.java:320) > >>>> at it.devel.Bilhetagem.bilhetar(Bilhetagem.java:141) > >>>> at it.devel.Bilhetagem.main(Bilhetagem.java:693) > >>>> > >>>> Dynamic libraries: > >>>> 08048000-08056000 r-xp 00000000 08:06 246208 > >>>> > >>> /usr/local/j2sdk1.4.2_06/bin/java > >>> > >>>> 08056000-08059000 rwxp 0000d000 08:06 246208 > >>>> > >>> /usr/local/j2sdk1.4.2_06/bin/java > >>> > >>>> 40000000-40011000 r-xp 00000000 08:05 212994 /lib/ld-2.3.3.so > >>>> 40011000-40012000 rwxp 00011000 08:05 212994 /lib/ld-2.3.3.so > >>>> 40018000-40026000 r-xp 00000000 08:05 213024 /lib/libpthread-0.10.so > >>>> 40026000-40028000 rwxp 0000d000 08:05 213024 /lib/libpthread-0.10.so > >>>> 4006a000-4006c000 r-xp 00000000 08:05 213005 /lib/libdl-2.3.3.so > >>>> 4006c000-4006d000 rwxp 00001000 08:05 213005 /lib/libdl-2.3.3.so > >>>> 4006d000-40167000 r-xp 00000000 08:05 213001 /lib/libc-2.3.3.so > >>>> 40167000-40170000 rwxp 000fa000 08:05 213001 /lib/libc-2.3.3.so > >>>> 40173000-4056f000 r-xp 00000000 08:06 134540 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so > >>>> 4056f000-4058b000 rwxp 003fb000 08:06 134540 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so > >>>> 405a2000-405b1000 r-xp 00000000 08:05 213009 /lib/libnsl-2.3.3.so > >>>> 405b1000-405b2000 rwxp 0000f000 08:05 213009 /lib/libnsl-2.3.3.so > >>>> 405b4000-405d4000 r-xp 00000000 08:05 213007 /lib/libm-2.3.3.so > >>>> 405d4000-405d5000 rwxp 0001f000 08:05 213007 /lib/libm-2.3.3.so > >>>> 405d5000-405dd000 r-xp 00000000 08:06 101710 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so > >>>> 405dd000-405de000 rwxp 00007000 08:06 101710 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so > >>>> 405de000-405e2000 rwxs 00000000 08:09 14628 > >>>> > >>> /tmp/hsperfdata_callstart/19866 > >>> > >>>> 405e3000-405ec000 r-xp 00000000 08:05 213015 > >>>> > >>> /lib/libnss_files-2.3.3.so > >>> > >>>> 405ec000-405ed000 rwxp 00009000 08:05 213015 > >>>> > >>> /lib/libnss_files-2.3.3.so > >>> > >>>> 405ed000-405fd000 r-xp 00000000 08:06 101717 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so > >>>> 405fd000-405ff000 rwxp 0000f000 08:06 101717 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so > >>>> 405ff000-4061f000 r-xp 00000000 08:06 101718 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so > >>>> 4061f000-40621000 rwxp 0001f000 08:06 101718 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so > >>>> 40621000-40635000 r-xp 00000000 08:06 101720 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so > >>>> 40635000-40638000 rwxp 00013000 08:06 101720 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so > >>>> 40638000-41fdf000 r-xs 00000000 08:06 101803 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/rt.jar > >>>> 42029000-4203f000 r-xs 00000000 08:06 101742 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/sunrsasign.jar > >>>> 4203f000-4211c000 r-xs 00000000 08:06 101787 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/jsse.jar > >>>> 4211c000-4212d000 r-xs 00000000 08:06 101743 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/jce.jar > >>>> 4212d000-42686000 r-xs 00000000 08:06 101788 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/charsets.jar > >>>> 4472e000-4472f000 r-xs 00000000 08:06 117021 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/Itau.jar > >>>> 4c7b0000-4c7cc000 r-xs 00000000 08:06 117679 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/sunjce_provider.jar > >>>> 4c7cc000-4c7cf000 r-xs 00000000 08:06 117680 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/dnsns.jar > >>>> 4c7cf000-4c7dc000 r-xs 00000000 08:06 117682 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/ldapsec.jar > >>>> 4c7dc000-4c898000 r-xs 00000000 08:06 117684 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/localedata.jar > >>>> 4c898000-4c8a6000 r-xs 00000000 08:06 117022 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/activation.jar > >>>> 4c8a6000-4c8d3000 r-xs 00000000 08:06 117023 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/mailapi.jar > >>>> 4c8d3000-4c92a000 r-xs 00000000 08:06 117024 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/mail.jar > >>>> 4c92a000-4c930000 r-xs 00000000 08:06 117025 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/pop3.jar > >>>> 4c930000-4c936000 r-xs 00000000 08:06 117026 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/smtp.jar > >>>> 4c936000-4c939000 r-xp 00000000 08:06 377923 > >>>> /usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConnection.so > >>>> 4c939000-4c93a000 rwxp 00002000 08:06 377923 > >>>> /usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConnection.so > >>>> 4c93a000-4c950000 r-xp 00000000 08:06 265533 > >>>> /usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35.so.1.0.0 > >>>> 4c950000-4c953000 rwxp 00015000 08:06 265533 > >>>> /usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35.so.1.0.0 > >>>> 4c953000-4c998000 r-xp 00000000 08:06 377564 > >>>> /usr/local/firstworks/lib/librudiments-0.27.so.1.0.0 > >>>> 4c998000-4c9a2000 rwxp 00044000 08:06 377564 > >>>> /usr/local/firstworks/lib/librudiments-0.27.so.1.0.0 > >>>> 4c9a7000-4c9d2000 r-xp 00000000 08:06 115308 /usr/lib/libssl.so.0.9.7 > >>>> 4c9d2000-4c9d5000 rwxp 0002a000 08:06 115308 /usr/lib/libssl.so.0.9.7 > >>>> 4c9d5000-4caab000 r-xp 00000000 08:06 115306 > >>>> > >>> /usr/lib/libcrypto.so.0.9.7 > >>> > >>>> 4caab000-4cabc000 rwxp 000d6000 08:06 115306 > >>>> > >>> /usr/lib/libcrypto.so.0.9.7 > >>> > >>>> 4cac0000-4cac4000 r-xp 00000000 08:05 213003 /lib/libcrypt-2.3.3.so > >>>> 4cac4000-4cac5000 rwxp 00003000 08:05 213003 /lib/libcrypt-2.3.3.so > >>>> 4caec000-4cb8a000 r-xp 00000000 08:06 114711 > >>>> > >>> /usr/lib/libstdc++.so.5.0.5 > >>> > >>>> 4cb8a000-4cba0000 rwxp 0009d000 08:06 114711 > >>>> > >>> /usr/lib/libstdc++.so.5.0.5 > >>> > >>>> 4cba5000-4cbac000 r-xp 00000000 08:06 114701 /usr/lib/libgcc_s.so.1 > >>>> 4cbac000-4cbad000 rwxp 00006000 08:06 114701 /usr/lib/libgcc_s.so.1 > >>>> 4cbad000-4cbb7000 r-xp 00000000 08:06 377924 > >>>> /usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCursor.so > >>>> 4cbb7000-4cbb9000 rwxp 0000a000 08:06 377924 > >>>> /usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCursor.so > >>>> > >>>> Heap at VM Abort: > >>>> Heap > >>>> def new generation total 576K, used 236K [0x44730000, 0x447d0000, > >>>> > >>> 0x44c10000) > >>> > >>>> eden space 512K, 43% used [0x44730000, 0x44767248, 0x447b0000) > >>>> from space 64K, 24% used [0x447b0000, 0x447b3fa8, 0x447c0000) > >>>> to space 64K, 0% used [0x447c0000, 0x447c0000, 0x447d0000) > >>>> tenured generation total 1408K, used 339K [0x44c10000, 0x44d70000, > >>>> > >>> 0x48730000) > >>> > >>>> the space 1408K, 24% used [0x44c10000, 0x44c64f58, 0x44c65000, > >>>> > >>> 0x44d70000) > >>> > >>>> compacting perm gen total 4096K, used 1696K [0x48730000, > >>>> > >>> 0x48b30000, 0x4c730000) > >>> > >>>> the space 4096K, 41% used [0x48730000, 0x488d8380, 0x488d8400, > >>>> > >>> 0x48b30000) > >>> > >>> > >>>> Local Time = Fri Nov 11 15:34:29 2005 > >>>> Elapsed Time = 771 > >>>> # > >>>> # The exception above was detected in native code outside the VM > >>>> # > >>>> # Java VM: Java HotSpot(TM) Client VM (1.4.2_06-b03 mixed mode) > >>>> - > >>>> -------------------------------------------------------------------------------------------------------- > >>>> > >>>> At the moment is not so easy for me to update to 0.36.x. > >>>> Does some one can help with that problem? > >>>> > >>>> Thanks in advance. > >>>> -- > >>>> ============================================ > >>>> Rodrigo P. Telles <te...@de...> > >>>> IT Manager > >>>> Devel-IT - http://www.devel.it > >>>> IVOZ # 1029 > >>>> +55 14 3324-1200 > >>>> Bestcom Group > >>>> ============================================ > >>>> > >>> ------------------------------------------------------- > >>> SF.Net email is sponsored by: > >>> Tame your development challenges with Apache's Geronimo App Server. > >>> Download > >>> it for free - -and be entered to win a 42" plasma tv or your very own > >>> Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > >>> _______________________________________________ > >>> Sqlrelay-discussion mailing list > >>> Sql...@li... > >>> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > >>> > >>> > >>> > >>> > >>> > >>> > >>>> ------------------------------------------------------- > >>>> This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > >>>> Register for a JBoss Training Course. Free Certification Exam > >>>> for All Training Attendees Through End of 2005. For more info visit: > >>>> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > >>>> _______________________________________________ > >>>> Sqlrelay-discussion mailing list > >>>> Sql...@li... > >>>> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > >>>> > >>> > >>> > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > > for problems? Stop! Download the new AJAX search engine that makes > > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > > _______________________________________________ > > Sqlrelay-discussion mailing list > > Sql...@li... > > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > > > > > |
|
From: Rodrigo P. T. <te...@de...> - 2006-01-31 12:36:35
|
Hi David, David Muse wrote: > Long queries should actually mean queries that are longer than 32k > characters. A query with only 397 characters or so shouldn't cause a > problem. I vaguely remember an issue like this though, and if it's wha= t > I remember, I think I fixed it in 0.36. Is it possible for you to > upgrade SQL Relay to more current version? If so, try > http://www.firstworks.com/sqlrelay-0.37pre5.tar.gz or sqlrelay-0.36.4 > from the sqlrelay website and see if the problem still persists. If it= > does (or if you can't easily upgrade), then let me know and I'll see if= > I can get you some code with debug in it and we'll patch the version > you're running now. > =20 I'm using 0.36.4 in a test box and the problem happens too. I upgraded to 0.37pre5 but it's not possible to run my Java code, a lot of types of constructors changed and it will be necessary to change all Java code :-( best regards, Telles > Dave > dav...@fi... > > On Wed, 2006-01-04 at 10:34 -0200, Rodrigo P. Telles wrote: > =20 >> Hi David, >> >> At last I think we (our team) found a cause of the exception! >> >> I think there was a misunderstood from my part in that answer (about >> "long queries"). >> I understood "long queries" as "long result sets" - and not the lenght= >> of the queries - when in fact the queries has about 397-580 characters= =2E >> I don't know if it's big enough to be considered "long" but it's the >> cause of the problem. If we changes that long queries to small ones >> (selecting or updating only 3 fields instead of 34) the problem go awa= y >> and everything works fine. >> >> Problematic query: >> >> SELECT phplib_id, username, domain, password, first_name, last_name, >> phone, email_address, datetime_created, datetime_modified, confirmatio= n, >> flag, sendnotification, greeting, ha1, ha1b, perms, allow_find, >> timezone, rpid, empresa, codInscricao, numInscricao, endereco, bairro,= >> cep, cidade, estado, pais, listaPublica, sigame, temSigame, status, >> macAddress FROM subscriber WHERE username=3D'2740' >> >> Solution query: >> >> SELECT phplib_id, username, first_name FROM subscriber WHERE username=3D= '2740' >> >> So as you said perhaps it's easy to patch. >> We'll test with how many fields the query starts to generate an except= ion. >> >> best regards, >> Telles >> >> Rodrigo P. Telles wrote: >> >> =20 >>> Hi David, >>> >>> Firstworks/4access wrote: >>> >>> =20 >>>> Is it possible to reliably reproduce the problem with a particular >>>> query, or is it kind of random? >>>> =20 >>> No it doesn't, it happens in a random fashion. Could happens twice in= >>> a week or >>> once in a month. >>> >>> =20 >>>> Offhand, it looks like java is trying to run (or return from) a nati= ve >>>> C++ function and has the wrong address for the function (or wrong re= turn >>>> address) and it ends up jumping off into the weeds, possibly into a >>>> non-executable page of memory. This typically happens when a buffer= >>>> overrun occurs and overwrites a jump address. >>>> =20 >>>> Does this happen with really long queries? With >>>> =20 >>> No it doesn't. >>> It happens in a simple query using INSERT or SELECT! >>> >>> =20 >>>> Java/Perl/PHP/Ruby/TCL/Python, SQL Relay makes a copy of the query. >>>> It's possible that there's some kind of bug where the SQL Relay clie= nt >>>> is copying too much data and overrunning it's buffer. If it's only = long >>>> queries, that would make sense and should be easy to patch. >>>> =20 >>>> Let me know... >>>> =20 >>> Let me know if I can do any thing to "collect" more informations abou= t >>> that problem. >>> Thanks for your answer. >>> >>> Telles >>> >>> =20 >>>> David Muse >>>> dav...@fi... >>>> =20 >>>> On Fri, 2005-11-11 at 17:48 -0200, Rodrigo P. Telles wrote: >>>> =20 >>>> Hi Guys, >>>> =20 >>>> I've been experiencing some errors using JAVA with sqlrelay-0.35 API= >>>> =20 >>> and MySQL >>> =20 >>>> 4.1.7 as a DB backend. >>>> =20 >>>> Some thimes when I'm doing a query the application failed with that >>>> =20 >>> output >>> =20 >>>> exception: >>>> --------------------------------------------------------------------= -------------- >>>> An unexpected exception has been detected in native code outside the= VM. >>>> Unexpected Signal : 11 occurred at PC=3D0x400C6C48 >>>> Function=3D(null)+0x400C6C48 >>>> Library=3D/lib/libc.so.6 >>>> =20 >>>> NOTE: We are unable to locate the function name symbol for the error= >>>> just occurred. Please refer to release documentation for possib= le >>>> reason and solutions. >>>> =20 >>> =20 >>>> Current Java thread: >>>> at com.firstworks.sqlrelay.SQLRCursor.prepareQuery(Native Method) >>>> at it.devel.Dao.getBean(Dao.java:185) >>>> at >>>> =20 >>> it.devel.wiser.TerminadorDAO.calculaMinutagem(TerminadorDAO.java:131)= >>> =20 >>>> at it.devel.Bilhetagem.getTempoCorrigido(Bilhetagem.java:342) >>>> at it.devel.Bilhetagem.bilhetaTerminador(Bilhetagem.java:320) >>>> at it.devel.Bilhetagem.bilhetar(Bilhetagem.java:141) >>>> at it.devel.Bilhetagem.main(Bilhetagem.java:693) >>>> =20 >>>> Dynamic libraries: >>>> 08048000-08056000 r-xp 00000000 08:06 246208 =20 >>>> =20 >>> /usr/local/j2sdk1.4.2_06/bin/java >>> =20 >>>> 08056000-08059000 rwxp 0000d000 08:06 246208 =20 >>>> =20 >>> /usr/local/j2sdk1.4.2_06/bin/java >>> =20 >>>> 40000000-40011000 r-xp 00000000 08:05 212994 /lib/ld-2.3.3.so >>>> 40011000-40012000 rwxp 00011000 08:05 212994 /lib/ld-2.3.3.so >>>> 40018000-40026000 r-xp 00000000 08:05 213024 /lib/libpthread-0.1= 0.so >>>> 40026000-40028000 rwxp 0000d000 08:05 213024 /lib/libpthread-0.1= 0.so >>>> 4006a000-4006c000 r-xp 00000000 08:05 213005 /lib/libdl-2.3.3.so= >>>> 4006c000-4006d000 rwxp 00001000 08:05 213005 /lib/libdl-2.3.3.so= >>>> 4006d000-40167000 r-xp 00000000 08:05 213001 /lib/libc-2.3.3.so >>>> 40167000-40170000 rwxp 000fa000 08:05 213001 /lib/libc-2.3.3.so >>>> 40173000-4056f000 r-xp 00000000 08:06 134540 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so >>>> 4056f000-4058b000 rwxp 003fb000 08:06 134540 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so >>>> 405a2000-405b1000 r-xp 00000000 08:05 213009 /lib/libnsl-2.3.3.s= o >>>> 405b1000-405b2000 rwxp 0000f000 08:05 213009 /lib/libnsl-2.3.3.s= o >>>> 405b4000-405d4000 r-xp 00000000 08:05 213007 /lib/libm-2.3.3.so >>>> 405d4000-405d5000 rwxp 0001f000 08:05 213007 /lib/libm-2.3.3.so >>>> 405d5000-405dd000 r-xp 00000000 08:06 101710 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so >>>> 405dd000-405de000 rwxp 00007000 08:06 101710 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so >>>> 405de000-405e2000 rwxs 00000000 08:09 14628 =20 >>>> =20 >>> /tmp/hsperfdata_callstart/19866 >>> =20 >>>> 405e3000-405ec000 r-xp 00000000 08:05 213015 =20 >>>> =20 >>> /lib/libnss_files-2.3.3.so >>> =20 >>>> 405ec000-405ed000 rwxp 00009000 08:05 213015 =20 >>>> =20 >>> /lib/libnss_files-2.3.3.so >>> =20 >>>> 405ed000-405fd000 r-xp 00000000 08:06 101717 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so >>>> 405fd000-405ff000 rwxp 0000f000 08:06 101717 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so >>>> 405ff000-4061f000 r-xp 00000000 08:06 101718 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so >>>> 4061f000-40621000 rwxp 0001f000 08:06 101718 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so >>>> 40621000-40635000 r-xp 00000000 08:06 101720 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so >>>> 40635000-40638000 rwxp 00013000 08:06 101720 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so >>>> 40638000-41fdf000 r-xs 00000000 08:06 101803 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/rt.jar >>>> 42029000-4203f000 r-xs 00000000 08:06 101742 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/sunrsasign.jar >>>> 4203f000-4211c000 r-xs 00000000 08:06 101787 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/jsse.jar >>>> 4211c000-4212d000 r-xs 00000000 08:06 101743 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/jce.jar >>>> 4212d000-42686000 r-xs 00000000 08:06 101788 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/charsets.jar >>>> 4472e000-4472f000 r-xs 00000000 08:06 117021 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/Itau.jar >>>> 4c7b0000-4c7cc000 r-xs 00000000 08:06 117679 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/sunjce_provider.jar >>>> 4c7cc000-4c7cf000 r-xs 00000000 08:06 117680 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/dnsns.jar >>>> 4c7cf000-4c7dc000 r-xs 00000000 08:06 117682 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/ldapsec.jar >>>> 4c7dc000-4c898000 r-xs 00000000 08:06 117684 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/localedata.jar >>>> 4c898000-4c8a6000 r-xs 00000000 08:06 117022 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/activation.jar >>>> 4c8a6000-4c8d3000 r-xs 00000000 08:06 117023 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/mailapi.jar >>>> 4c8d3000-4c92a000 r-xs 00000000 08:06 117024 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/mail.jar >>>> 4c92a000-4c930000 r-xs 00000000 08:06 117025 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/pop3.jar >>>> 4c930000-4c936000 r-xs 00000000 08:06 117026 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/smtp.jar >>>> 4c936000-4c939000 r-xp 00000000 08:06 377923 >>>> /usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConnection= =2Eso >>>> 4c939000-4c93a000 rwxp 00002000 08:06 377923 >>>> /usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConnection= =2Eso >>>> 4c93a000-4c950000 r-xp 00000000 08:06 265533 >>>> /usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35.so.1= =2E0.0 >>>> 4c950000-4c953000 rwxp 00015000 08:06 265533 >>>> /usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35.so.1= =2E0.0 >>>> 4c953000-4c998000 r-xp 00000000 08:06 377564 >>>> /usr/local/firstworks/lib/librudiments-0.27.so.1.0.0 >>>> 4c998000-4c9a2000 rwxp 00044000 08:06 377564 >>>> /usr/local/firstworks/lib/librudiments-0.27.so.1.0.0 >>>> 4c9a7000-4c9d2000 r-xp 00000000 08:06 115308 /usr/lib/libssl.so.= 0.9.7 >>>> 4c9d2000-4c9d5000 rwxp 0002a000 08:06 115308 /usr/lib/libssl.so.= 0.9.7 >>>> 4c9d5000-4caab000 r-xp 00000000 08:06 115306 =20 >>>> =20 >>> /usr/lib/libcrypto.so.0.9.7 >>> =20 >>>> 4caab000-4cabc000 rwxp 000d6000 08:06 115306 =20 >>>> =20 >>> /usr/lib/libcrypto.so.0.9.7 >>> =20 >>>> 4cac0000-4cac4000 r-xp 00000000 08:05 213003 /lib/libcrypt-2.3.3= =2Eso >>>> 4cac4000-4cac5000 rwxp 00003000 08:05 213003 /lib/libcrypt-2.3.3= =2Eso >>>> 4caec000-4cb8a000 r-xp 00000000 08:06 114711 =20 >>>> =20 >>> /usr/lib/libstdc++.so.5.0.5 >>> =20 >>>> 4cb8a000-4cba0000 rwxp 0009d000 08:06 114711 =20 >>>> =20 >>> /usr/lib/libstdc++.so.5.0.5 >>> =20 >>>> 4cba5000-4cbac000 r-xp 00000000 08:06 114701 /usr/lib/libgcc_s.s= o.1 >>>> 4cbac000-4cbad000 rwxp 00006000 08:06 114701 /usr/lib/libgcc_s.s= o.1 >>>> 4cbad000-4cbb7000 r-xp 00000000 08:06 377924 >>>> /usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCursor.so >>>> 4cbb7000-4cbb9000 rwxp 0000a000 08:06 377924 >>>> /usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCursor.so >>>> =20 >>>> Heap at VM Abort: >>>> Heap >>>> def new generation total 576K, used 236K [0x44730000, 0x447d0000, >>>> =20 >>> 0x44c10000) >>> =20 >>>> eden space 512K, 43% used [0x44730000, 0x44767248, 0x447b0000) >>>> from space 64K, 24% used [0x447b0000, 0x447b3fa8, 0x447c0000) >>>> to space 64K, 0% used [0x447c0000, 0x447c0000, 0x447d0000) >>>> tenured generation total 1408K, used 339K [0x44c10000, 0x44d70000,= >>>> =20 >>> 0x48730000) >>> =20 >>>> the space 1408K, 24% used [0x44c10000, 0x44c64f58, 0x44c65000, >>>> =20 >>> 0x44d70000) >>> =20 >>>> compacting perm gen total 4096K, used 1696K [0x48730000, >>>> =20 >>> 0x48b30000, 0x4c730000) >>> =20 >>>> the space 4096K, 41% used [0x48730000, 0x488d8380, 0x488d8400, >>>> =20 >>> 0x48b30000) >>> >>> =20 >>>> Local Time =3D Fri Nov 11 15:34:29 2005 >>>> Elapsed Time =3D 771 >>>> # >>>> # The exception above was detected in native code outside the VM >>>> # >>>> # Java VM: Java HotSpot(TM) Client VM (1.4.2_06-b03 mixed mode) >>>> - >>>> --------------------------------------------------------------------= ------------------------------------ >>>> =20 >>>> At the moment is not so easy for me to update to 0.36.x. >>>> Does some one can help with that problem? >>>> =20 >>>> Thanks in advance. >>>> -- >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> Rodrigo P. Telles <te...@de...> >>>> IT Manager >>>> Devel-IT - http://www.devel.it >>>> IVOZ # 1029 >>>> +55 14 3324-1200 >>>> Bestcom Group >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> =20 >>> ------------------------------------------------------- >>> SF.Net email is sponsored by: >>> Tame your development challenges with Apache's Geronimo App Server. >>> Download >>> it for free - -and be entered to win a 42" plasma tv or your very own= >>> Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php= >>> _______________________________________________ >>> Sqlrelay-discussion mailing list >>> Sql...@li... >>> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion >>> >>> >>> >>> >>> >>> =20 >>>> ------------------------------------------------------- >>>> This SF.Net email is sponsored by the JBoss Inc. Get Certified Toda= y >>>> Register for a JBoss Training Course. Free Certification Exam >>>> for All Training Attendees Through End of 2005. For more info visit:= >>>> http://ads.osdn.com/?ad_id=3D7628&alloc_id=3D16845&op=3Dclick >>>> _______________________________________________ >>>> Sqlrelay-discussion mailing list >>>> Sql...@li... >>>> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion >>>> =20 >>> >>> =20 > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log = files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!= > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat= =3D121642 > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > =20 |
|
From: Maciej W. <mac...@co...> - 2006-01-31 11:59:24
|
Hi I've now switched to SQLRelay 0.37pre5 and found some changes that caused my old code was not working. These are changes in SQLRConnection constructor (port is now short not int), and in rowCount (returns long not int). I think these things should be listed in changelog, or maybe they are there but in a inplicit way? -- Maciej Wisniowski |
|
From: dforums <df...@vi...> - 2006-01-28 15:11:39
|
Hi David Yes it seems to be a good reference. I'll give you some more : http://pecl.php.net/support.php#resources http://pecl.php.net/package/PDO http://oss.backendmedia.com/index.php?area=PDO&page=HomePage and the site of php.net Regards David reply David David Muse a écrit : >I'll put it on the TODO list, but I can't guarantee when I'll be able to >get it done. > >Is this the site for it http://wiki.cc/php/PDO ? > >Dave >dav...@fi... > >On Tue, 2006-01-24 at 10:08 +0100, david bigand forum wrote: > > >>HELLO >> >>Has the technology advance we have to follow. >> >>I would request to our great designer of SQLrelay. If he could write an PDO >>extension for sqlrelay. >> >>As PDO is an universal wrapper, and that PDO is very much faster than >>PEAR::DB, that could improve enormously the performance of database >>connection for php. >> >>Regards >> >>David >> >> >> >>------------------------------------------------------- >>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >>for problems? Stop! Download the new AJAX search engine that makes >>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 >>_______________________________________________ >>Sqlrelay-discussion mailing list >>Sql...@li... >>https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion >> >> >> > > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 >_______________________________________________ >Sqlrelay-discussion mailing list >Sql...@li... >https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > > |
|
From: David M. <dav...@fi...> - 2006-01-27 19:01:37
|
Aaah, thanks for finding that one. Dave On Wed, 2006-01-25 at 09:00 +0100, Maciej Wisniowski wrote: > I've checked version 0.37pre5 and when compiling it with postgres I get > the error as below. > Without postgres it installs correctly. > > make[3]: Entering folder > `/home/zope/install/sqlrelay_3.7_pre5/sqlrelay-0.37/src/connections/postgresql' > /bin/sh ../../../libtool --mode=compile g++ -Wall -pipe -pthread -I./ > -I../../../ -I../../../src/common -I../../../src/util > -I../../../src/connection -I/usr/local/firstworks/include -pthread > -I/usr/kerberos/include -I../../../src/api/c++/include -c > postgresqlconnection.C -o postgresqlconnection.lo > mkdir .libs > g++ -Wall -pipe -pthread -I./ -I../../../ -I../../../src/common > -I../../../src/util -I../../../src/connection > -I/usr/local/firstworks/include -pthread -I/usr/kerberos/include > -I../../../src/api/c++/include -c postgresqlconnection.C -fPIC -DPIC -o > .libs/postgresqlconnection.o > postgresqlconnection.C:175: definition of implicitly-declared `virtual > postgresqlcursor::~postgresqlcursor()' > make[3]: *** [postgresqlconnection.lo] Error 1 > make[3]: Leaving folder > `/home/zope/install/sqlrelay_3.7_pre5/sqlrelay-0.37/src/connections/postgresql' > make[2]: *** [all] Error 2 > make[2]: Leaving folder > `/home/zope/install/sqlrelay_3.7_pre5/sqlrelay-0.37/src/connections' > make[1]: *** [all] Error 2 > make[1]: Leaving folder > `/home/zope/install/sqlrelay_3.7_pre5/sqlrelay-0.37/src' > make: *** [all] Error 2 > > |
|
From: David M. <dav...@fi...> - 2006-01-27 18:57:36
|
I'll put it on the TODO list, but I can't guarantee when I'll be able to get it done. Is this the site for it http://wiki.cc/php/PDO ? Dave dav...@fi... On Tue, 2006-01-24 at 10:08 +0100, david bigand forum wrote: > HELLO > > Has the technology advance we have to follow. > > I would request to our great designer of SQLrelay. If he could write an PDO > extension for sqlrelay. > > As PDO is an universal wrapper, and that PDO is very much faster than > PEAR::DB, that could improve enormously the performance of database > connection for php. > > Regards > > David > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > |
|
From: David M. <dav...@fi...> - 2006-01-27 18:51:02
|
Yes, I intend to write an ODBC driver for SQL Relay which uses the SQL Relay API. Ie. apps which have been coded to use unixODBC could connect through SQL Relay to a database. It's on the TODO list, but I haven't done any work on it yet. If you'd like to work on it though, please do! :) Dave dav...@fi... On Tue, 2006-01-24 at 22:23 -0500, Batoussa Mougamadou wrote: > Sorry, I didn=E2=80=99t notice the TODO list. >=20 > So, did it plan to have an sqlrelay ODBC API that could interface > unixODBC? >=20 > =20 >=20 > Thank you >=20 > =20 >=20 > =20 > ______________________________________________________________________ > From: Batoussa Mougamadou=20 > Sent: Tuesday, January 24, 2006 4:07 PM > To: 'sql...@li...' > Subject: Calling SQLRelay with UnixODBC >=20 >=20 > =20 >=20 > Hi, >=20 > =20 >=20 > Sqlrelay permits to connect to a database using ODBC connection > (compiled against unixODBC in my case), and it works fine. >=20 > Is it possible to connect via unixODBC (using sqlrelay client =E2=80=A6= ) to a > sqlrelay listener? Or must I implement a specific ODBC Driver which > will use sqlrelay client API? >=20 > =20 >=20 > I mean the following architecture: >=20 > =20 >=20 > Client > Server >=20 > [isql -> unixODBC -> sqlrelay client ] =C3=9F network =C3=A0 [sqlrelay > (daemon/listener) -> unixODBC -> oracle10g] >=20 > =20 >=20 > Thank you >=20 >=20 |
|
From: <kum...@si...> - 2006-01-27 09:18:58
|
David, Ping does return false even after the DB comes up, after failure. similar condition has been reported in http://sourceforge.net/mailarchive/message.php?msg_id=14211078 As already quoted, when the DB goes down, the TCP connection between sqlr-connection and MYSQL server goes to CLOSE_WAIT state from ESTABLISHED state. When the DB comes up, the earlier connection is no longer valid. sqlr-connection must try out a new TCP connection with DB, which is not the case with ping(). AFAIK, only sendQuery() attempts to reconnect. Kumara Sundaram Quoting dav...@fi...: > Are you sure ping() returns false even when the database has come back up? I just tested it and it works for me: [mused@localhost ~]$ sqlr-start -id mysqltest Starting listener: sqlr-listener -id mysqltest -config /usr/local/firstworks/etc/sqlrelay.conf Warning: could not change group to nobody Warning: could not change user to nobody Starting 1 connections to db : sqlr-connection-mysql -id mysqltest -connectionid db -config /usr/local/firstworks/etc/sqlrelay.conf Warning: could not change group to nobody Warning: could not change user to nobody Starting cache manager: sqlr-cachemanager Warning: using default id. Thanks to MP3.com for sponsoring: Clustered/Replicated database support. Perl API. [mused@localhost ~]$ sqlrsh -id mysqltest SQLRShell - Version 0.22 Connected to: localhost:8006 as mysqltest type help; for a help. 0> select * from testtable; col1 ==== 1 Rows Returned : 1 Fields Returned : 1 System time : 20000 (here I shut the db down in another window) 0> ping; The database is down. (here I brought it back up) 0> ping; The database is up. 0> select * from testtable; col1 ==== 1 Rows Returned : 1 Fields Returned : 1 System time : 20000 0> quit 1> ; I tried a couple of other combinations, but ping() appears to work properly to me, at least with MySQL. Dave dav...@fi... On Fri, 2006-01-20 at 16:10 +0600, Kumara S wrote: > Hi, > > We are develpoping a web application that connects to MySQL thru > sqlrelay... > > We thought of using PHP pear DB classes to abstract the > database. My requirement is to connect to the database server and check > if it can handle further queries successfully. When the MySQL server > goes down, sqlrelay sendQuery() keeps retrying infinitely and returns > only after the DB comes up. Since i can't allow my page to wait till > everything becomes normal, i thought of using ping() to check the status > of MySQL before querying. but, even when the DB recovers later, ping() > returns false. Following ealier discussions with Maciej Wisniowski, > ping() just gives the status of the connection that went to CLOSE_WAIT > state and does not attempt to reconnect to DB. It is only the first > sendQuery that reconnects. > > So, using ping() before sendQuery() does > not allow my application to recover even when MySQL is up. > Calling > sendQuery() directly sends my application to infinite loop in case of DB > failure. > > The problem is simple. Connect to DB when it is available in > a single try, return false in case of a DB failure. API calls like > mysql_connect gives me just that. but, sqlrelay either gives me infinite > retries(when DB goes down) or no try at all (when it > recovers). > > Please give me a workaround. > > Thanks! > > Kumara > Sundaram > ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Sqlrelay-discussion mailing list Sql...@li... https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion |
|
From: David M. <dav...@fi...> - 2006-01-25 15:38:27
|
Yes, there's an updated version of rudiments in the tarball. Dave On Wed, 2006-01-25 at 11:18 -0200, Rodrigo P. Telles wrote: > Hi David, > > Thanks for your answer! > Should I have to upgrade rudiments too? > > Best regards, > > Telles > > David Muse wrote: > > Long queries should actually mean queries that are longer than 32k > > characters. A query with only 397 characters or so shouldn't cause a > > problem. I vaguely remember an issue like this though, and if it's what > > I remember, I think I fixed it in 0.36. Is it possible for you to > > upgrade SQL Relay to more current version? If so, try > > http://www.firstworks.com/sqlrelay-0.37pre5.tar.gz or sqlrelay-0.36.4 > > from the sqlrelay website and see if the problem still persists. If it > > does (or if you can't easily upgrade), then let me know and I'll see if > > I can get you some code with debug in it and we'll patch the version > > you're running now. > > > > Dave > > dav...@fi... > > > > On Wed, 2006-01-04 at 10:34 -0200, Rodrigo P. Telles wrote: > > > >> Hi David, > >> > >> At last I think we (our team) found a cause of the exception! > >> > >> I think there was a misunderstood from my part in that answer (about > >> "long queries"). > >> I understood "long queries" as "long result sets" - and not the lenght > >> of the queries - when in fact the queries has about 397-580 characters. > >> I don't know if it's big enough to be considered "long" but it's the > >> cause of the problem. If we changes that long queries to small ones > >> (selecting or updating only 3 fields instead of 34) the problem go away > >> and everything works fine. > >> > >> Problematic query: > >> > >> SELECT phplib_id, username, domain, password, first_name, last_name, > >> phone, email_address, datetime_created, datetime_modified, confirmation, > >> flag, sendnotification, greeting, ha1, ha1b, perms, allow_find, > >> timezone, rpid, empresa, codInscricao, numInscricao, endereco, bairro, > >> cep, cidade, estado, pais, listaPublica, sigame, temSigame, status, > >> macAddress FROM subscriber WHERE username='2740' > >> > >> Solution query: > >> > >> SELECT phplib_id, username, first_name FROM subscriber WHERE username='2740' > >> > >> So as you said perhaps it's easy to patch. > >> We'll test with how many fields the query starts to generate an exception. > >> > >> best regards, > >> Telles > >> > >> Rodrigo P. Telles wrote: > >> > >> > >>> Hi David, > >>> > >>> Firstworks/4access wrote: > >>> > >>> > >>>> Is it possible to reliably reproduce the problem with a particular > >>>> query, or is it kind of random? > >>>> > >>> No it doesn't, it happens in a random fashion. Could happens twice in > >>> a week or > >>> once in a month. > >>> > >>> > >>>> Offhand, it looks like java is trying to run (or return from) a native > >>>> C++ function and has the wrong address for the function (or wrong return > >>>> address) and it ends up jumping off into the weeds, possibly into a > >>>> non-executable page of memory. This typically happens when a buffer > >>>> overrun occurs and overwrites a jump address. > >>>> > >>>> Does this happen with really long queries? With > >>>> > >>> No it doesn't. > >>> It happens in a simple query using INSERT or SELECT! > >>> > >>> > >>>> Java/Perl/PHP/Ruby/TCL/Python, SQL Relay makes a copy of the query. > >>>> It's possible that there's some kind of bug where the SQL Relay client > >>>> is copying too much data and overrunning it's buffer. If it's only long > >>>> queries, that would make sense and should be easy to patch. > >>>> > >>>> Let me know... > >>>> > >>> Let me know if I can do any thing to "collect" more informations about > >>> that problem. > >>> Thanks for your answer. > >>> > >>> Telles > >>> > >>> > >>>> David Muse > >>>> dav...@fi... > >>>> > >>>> On Fri, 2005-11-11 at 17:48 -0200, Rodrigo P. Telles wrote: > >>>> > >>>> Hi Guys, > >>>> > >>>> I've been experiencing some errors using JAVA with sqlrelay-0.35 API > >>>> > >>> and MySQL > >>> > >>>> 4.1.7 as a DB backend. > >>>> > >>>> Some thimes when I'm doing a query the application failed with that > >>>> > >>> output > >>> > >>>> exception: > >>>> ---------------------------------------------------------------------------------- > >>>> An unexpected exception has been detected in native code outside the VM. > >>>> Unexpected Signal : 11 occurred at PC=0x400C6C48 > >>>> Function=(null)+0x400C6C48 > >>>> Library=/lib/libc.so.6 > >>>> > >>>> NOTE: We are unable to locate the function name symbol for the error > >>>> just occurred. Please refer to release documentation for possible > >>>> reason and solutions. > >>>> > >>> > >>>> Current Java thread: > >>>> at com.firstworks.sqlrelay.SQLRCursor.prepareQuery(Native Method) > >>>> at it.devel.Dao.getBean(Dao.java:185) > >>>> at > >>>> > >>> it.devel.wiser.TerminadorDAO.calculaMinutagem(TerminadorDAO.java:131) > >>> > >>>> at it.devel.Bilhetagem.getTempoCorrigido(Bilhetagem.java:342) > >>>> at it.devel.Bilhetagem.bilhetaTerminador(Bilhetagem.java:320) > >>>> at it.devel.Bilhetagem.bilhetar(Bilhetagem.java:141) > >>>> at it.devel.Bilhetagem.main(Bilhetagem.java:693) > >>>> > >>>> Dynamic libraries: > >>>> 08048000-08056000 r-xp 00000000 08:06 246208 > >>>> > >>> /usr/local/j2sdk1.4.2_06/bin/java > >>> > >>>> 08056000-08059000 rwxp 0000d000 08:06 246208 > >>>> > >>> /usr/local/j2sdk1.4.2_06/bin/java > >>> > >>>> 40000000-40011000 r-xp 00000000 08:05 212994 /lib/ld-2.3.3.so > >>>> 40011000-40012000 rwxp 00011000 08:05 212994 /lib/ld-2.3.3.so > >>>> 40018000-40026000 r-xp 00000000 08:05 213024 /lib/libpthread-0.10.so > >>>> 40026000-40028000 rwxp 0000d000 08:05 213024 /lib/libpthread-0.10.so > >>>> 4006a000-4006c000 r-xp 00000000 08:05 213005 /lib/libdl-2.3.3.so > >>>> 4006c000-4006d000 rwxp 00001000 08:05 213005 /lib/libdl-2.3.3.so > >>>> 4006d000-40167000 r-xp 00000000 08:05 213001 /lib/libc-2.3.3.so > >>>> 40167000-40170000 rwxp 000fa000 08:05 213001 /lib/libc-2.3.3.so > >>>> 40173000-4056f000 r-xp 00000000 08:06 134540 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so > >>>> 4056f000-4058b000 rwxp 003fb000 08:06 134540 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so > >>>> 405a2000-405b1000 r-xp 00000000 08:05 213009 /lib/libnsl-2.3.3.so > >>>> 405b1000-405b2000 rwxp 0000f000 08:05 213009 /lib/libnsl-2.3.3.so > >>>> 405b4000-405d4000 r-xp 00000000 08:05 213007 /lib/libm-2.3.3.so > >>>> 405d4000-405d5000 rwxp 0001f000 08:05 213007 /lib/libm-2.3.3.so > >>>> 405d5000-405dd000 r-xp 00000000 08:06 101710 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so > >>>> 405dd000-405de000 rwxp 00007000 08:06 101710 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so > >>>> 405de000-405e2000 rwxs 00000000 08:09 14628 > >>>> > >>> /tmp/hsperfdata_callstart/19866 > >>> > >>>> 405e3000-405ec000 r-xp 00000000 08:05 213015 > >>>> > >>> /lib/libnss_files-2.3.3.so > >>> > >>>> 405ec000-405ed000 rwxp 00009000 08:05 213015 > >>>> > >>> /lib/libnss_files-2.3.3.so > >>> > >>>> 405ed000-405fd000 r-xp 00000000 08:06 101717 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so > >>>> 405fd000-405ff000 rwxp 0000f000 08:06 101717 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so > >>>> 405ff000-4061f000 r-xp 00000000 08:06 101718 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so > >>>> 4061f000-40621000 rwxp 0001f000 08:06 101718 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so > >>>> 40621000-40635000 r-xp 00000000 08:06 101720 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so > >>>> 40635000-40638000 rwxp 00013000 08:06 101720 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so > >>>> 40638000-41fdf000 r-xs 00000000 08:06 101803 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/rt.jar > >>>> 42029000-4203f000 r-xs 00000000 08:06 101742 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/sunrsasign.jar > >>>> 4203f000-4211c000 r-xs 00000000 08:06 101787 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/jsse.jar > >>>> 4211c000-4212d000 r-xs 00000000 08:06 101743 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/jce.jar > >>>> 4212d000-42686000 r-xs 00000000 08:06 101788 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/charsets.jar > >>>> 4472e000-4472f000 r-xs 00000000 08:06 117021 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/Itau.jar > >>>> 4c7b0000-4c7cc000 r-xs 00000000 08:06 117679 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/sunjce_provider.jar > >>>> 4c7cc000-4c7cf000 r-xs 00000000 08:06 117680 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/dnsns.jar > >>>> 4c7cf000-4c7dc000 r-xs 00000000 08:06 117682 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/ldapsec.jar > >>>> 4c7dc000-4c898000 r-xs 00000000 08:06 117684 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/localedata.jar > >>>> 4c898000-4c8a6000 r-xs 00000000 08:06 117022 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/activation.jar > >>>> 4c8a6000-4c8d3000 r-xs 00000000 08:06 117023 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/mailapi.jar > >>>> 4c8d3000-4c92a000 r-xs 00000000 08:06 117024 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/mail.jar > >>>> 4c92a000-4c930000 r-xs 00000000 08:06 117025 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/pop3.jar > >>>> 4c930000-4c936000 r-xs 00000000 08:06 117026 > >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/smtp.jar > >>>> 4c936000-4c939000 r-xp 00000000 08:06 377923 > >>>> /usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConnection.so > >>>> 4c939000-4c93a000 rwxp 00002000 08:06 377923 > >>>> /usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConnection.so > >>>> 4c93a000-4c950000 r-xp 00000000 08:06 265533 > >>>> /usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35.so.1.0.0 > >>>> 4c950000-4c953000 rwxp 00015000 08:06 265533 > >>>> /usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35.so.1.0.0 > >>>> 4c953000-4c998000 r-xp 00000000 08:06 377564 > >>>> /usr/local/firstworks/lib/librudiments-0.27.so.1.0.0 > >>>> 4c998000-4c9a2000 rwxp 00044000 08:06 377564 > >>>> /usr/local/firstworks/lib/librudiments-0.27.so.1.0.0 > >>>> 4c9a7000-4c9d2000 r-xp 00000000 08:06 115308 /usr/lib/libssl.so.0.9.7 > >>>> 4c9d2000-4c9d5000 rwxp 0002a000 08:06 115308 /usr/lib/libssl.so.0.9.7 > >>>> 4c9d5000-4caab000 r-xp 00000000 08:06 115306 > >>>> > >>> /usr/lib/libcrypto.so.0.9.7 > >>> > >>>> 4caab000-4cabc000 rwxp 000d6000 08:06 115306 > >>>> > >>> /usr/lib/libcrypto.so.0.9.7 > >>> > >>>> 4cac0000-4cac4000 r-xp 00000000 08:05 213003 /lib/libcrypt-2.3.3.so > >>>> 4cac4000-4cac5000 rwxp 00003000 08:05 213003 /lib/libcrypt-2.3.3.so > >>>> 4caec000-4cb8a000 r-xp 00000000 08:06 114711 > >>>> > >>> /usr/lib/libstdc++.so.5.0.5 > >>> > >>>> 4cb8a000-4cba0000 rwxp 0009d000 08:06 114711 > >>>> > >>> /usr/lib/libstdc++.so.5.0.5 > >>> > >>>> 4cba5000-4cbac000 r-xp 00000000 08:06 114701 /usr/lib/libgcc_s.so.1 > >>>> 4cbac000-4cbad000 rwxp 00006000 08:06 114701 /usr/lib/libgcc_s.so.1 > >>>> 4cbad000-4cbb7000 r-xp 00000000 08:06 377924 > >>>> /usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCursor.so > >>>> 4cbb7000-4cbb9000 rwxp 0000a000 08:06 377924 > >>>> /usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCursor.so > >>>> > >>>> Heap at VM Abort: > >>>> Heap > >>>> def new generation total 576K, used 236K [0x44730000, 0x447d0000, > >>>> > >>> 0x44c10000) > >>> > >>>> eden space 512K, 43% used [0x44730000, 0x44767248, 0x447b0000) > >>>> from space 64K, 24% used [0x447b0000, 0x447b3fa8, 0x447c0000) > >>>> to space 64K, 0% used [0x447c0000, 0x447c0000, 0x447d0000) > >>>> tenured generation total 1408K, used 339K [0x44c10000, 0x44d70000, > >>>> > >>> 0x48730000) > >>> > >>>> the space 1408K, 24% used [0x44c10000, 0x44c64f58, 0x44c65000, > >>>> > >>> 0x44d70000) > >>> > >>>> compacting perm gen total 4096K, used 1696K [0x48730000, > >>>> > >>> 0x48b30000, 0x4c730000) > >>> > >>>> the space 4096K, 41% used [0x48730000, 0x488d8380, 0x488d8400, > >>>> > >>> 0x48b30000) > >>> > >>> > >>>> Local Time = Fri Nov 11 15:34:29 2005 > >>>> Elapsed Time = 771 > >>>> # > >>>> # The exception above was detected in native code outside the VM > >>>> # > >>>> # Java VM: Java HotSpot(TM) Client VM (1.4.2_06-b03 mixed mode) > >>>> - > >>>> -------------------------------------------------------------------------------------------------------- > >>>> > >>>> At the moment is not so easy for me to update to 0.36.x. > >>>> Does some one can help with that problem? > >>>> > >>>> Thanks in advance. > >>>> -- > >>>> ============================================ > >>>> Rodrigo P. Telles <te...@de...> > >>>> IT Manager > >>>> Devel-IT - http://www.devel.it > >>>> IVOZ # 1029 > >>>> +55 14 3324-1200 > >>>> Bestcom Group > >>>> ============================================ > >>>> > >>> ------------------------------------------------------- > >>> SF.Net email is sponsored by: > >>> Tame your development challenges with Apache's Geronimo App Server. > >>> Download > >>> it for free - -and be entered to win a 42" plasma tv or your very own > >>> Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > >>> _______________________________________________ > >>> Sqlrelay-discussion mailing list > >>> Sql...@li... > >>> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > >>> > >>> > >>> > >>> > >>> > >>> > >>>> ------------------------------------------------------- > >>>> This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > >>>> Register for a JBoss Training Course. Free Certification Exam > >>>> for All Training Attendees Through End of 2005. For more info visit: > >>>> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > >>>> _______________________________________________ > >>>> Sqlrelay-discussion mailing list > >>>> Sql...@li... > >>>> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > >>>> > >>> > >>> > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > > for problems? Stop! Download the new AJAX search engine that makes > > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > > _______________________________________________ > > Sqlrelay-discussion mailing list > > Sql...@li... > > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > > > > > |
|
From: Rodrigo P. T. <te...@de...> - 2006-01-25 13:25:25
|
Hi David, Thanks for your answer! Should I have to upgrade rudiments too? Best regards, Telles David Muse wrote: > Long queries should actually mean queries that are longer than 32k > characters. A query with only 397 characters or so shouldn't cause a > problem. I vaguely remember an issue like this though, and if it's wha= t > I remember, I think I fixed it in 0.36. Is it possible for you to > upgrade SQL Relay to more current version? If so, try > http://www.firstworks.com/sqlrelay-0.37pre5.tar.gz or sqlrelay-0.36.4 > from the sqlrelay website and see if the problem still persists. If it= > does (or if you can't easily upgrade), then let me know and I'll see if= > I can get you some code with debug in it and we'll patch the version > you're running now. > > Dave > dav...@fi... > > On Wed, 2006-01-04 at 10:34 -0200, Rodrigo P. Telles wrote: > =20 >> Hi David, >> >> At last I think we (our team) found a cause of the exception! >> >> I think there was a misunderstood from my part in that answer (about >> "long queries"). >> I understood "long queries" as "long result sets" - and not the lenght= >> of the queries - when in fact the queries has about 397-580 characters= =2E >> I don't know if it's big enough to be considered "long" but it's the >> cause of the problem. If we changes that long queries to small ones >> (selecting or updating only 3 fields instead of 34) the problem go awa= y >> and everything works fine. >> >> Problematic query: >> >> SELECT phplib_id, username, domain, password, first_name, last_name, >> phone, email_address, datetime_created, datetime_modified, confirmatio= n, >> flag, sendnotification, greeting, ha1, ha1b, perms, allow_find, >> timezone, rpid, empresa, codInscricao, numInscricao, endereco, bairro,= >> cep, cidade, estado, pais, listaPublica, sigame, temSigame, status, >> macAddress FROM subscriber WHERE username=3D'2740' >> >> Solution query: >> >> SELECT phplib_id, username, first_name FROM subscriber WHERE username=3D= '2740' >> >> So as you said perhaps it's easy to patch. >> We'll test with how many fields the query starts to generate an except= ion. >> >> best regards, >> Telles >> >> Rodrigo P. Telles wrote: >> >> =20 >>> Hi David, >>> >>> Firstworks/4access wrote: >>> >>> =20 >>>> Is it possible to reliably reproduce the problem with a particular >>>> query, or is it kind of random? >>>> =20 >>> No it doesn't, it happens in a random fashion. Could happens twice in= >>> a week or >>> once in a month. >>> >>> =20 >>>> Offhand, it looks like java is trying to run (or return from) a nati= ve >>>> C++ function and has the wrong address for the function (or wrong re= turn >>>> address) and it ends up jumping off into the weeds, possibly into a >>>> non-executable page of memory. This typically happens when a buffer= >>>> overrun occurs and overwrites a jump address. >>>> =20 >>>> Does this happen with really long queries? With >>>> =20 >>> No it doesn't. >>> It happens in a simple query using INSERT or SELECT! >>> >>> =20 >>>> Java/Perl/PHP/Ruby/TCL/Python, SQL Relay makes a copy of the query. >>>> It's possible that there's some kind of bug where the SQL Relay clie= nt >>>> is copying too much data and overrunning it's buffer. If it's only = long >>>> queries, that would make sense and should be easy to patch. >>>> =20 >>>> Let me know... >>>> =20 >>> Let me know if I can do any thing to "collect" more informations abou= t >>> that problem. >>> Thanks for your answer. >>> >>> Telles >>> >>> =20 >>>> David Muse >>>> dav...@fi... >>>> =20 >>>> On Fri, 2005-11-11 at 17:48 -0200, Rodrigo P. Telles wrote: >>>> =20 >>>> Hi Guys, >>>> =20 >>>> I've been experiencing some errors using JAVA with sqlrelay-0.35 API= >>>> =20 >>> and MySQL >>> =20 >>>> 4.1.7 as a DB backend. >>>> =20 >>>> Some thimes when I'm doing a query the application failed with that >>>> =20 >>> output >>> =20 >>>> exception: >>>> --------------------------------------------------------------------= -------------- >>>> An unexpected exception has been detected in native code outside the= VM. >>>> Unexpected Signal : 11 occurred at PC=3D0x400C6C48 >>>> Function=3D(null)+0x400C6C48 >>>> Library=3D/lib/libc.so.6 >>>> =20 >>>> NOTE: We are unable to locate the function name symbol for the error= >>>> just occurred. Please refer to release documentation for possib= le >>>> reason and solutions. >>>> =20 >>> =20 >>>> Current Java thread: >>>> at com.firstworks.sqlrelay.SQLRCursor.prepareQuery(Native Method) >>>> at it.devel.Dao.getBean(Dao.java:185) >>>> at >>>> =20 >>> it.devel.wiser.TerminadorDAO.calculaMinutagem(TerminadorDAO.java:131)= >>> =20 >>>> at it.devel.Bilhetagem.getTempoCorrigido(Bilhetagem.java:342) >>>> at it.devel.Bilhetagem.bilhetaTerminador(Bilhetagem.java:320) >>>> at it.devel.Bilhetagem.bilhetar(Bilhetagem.java:141) >>>> at it.devel.Bilhetagem.main(Bilhetagem.java:693) >>>> =20 >>>> Dynamic libraries: >>>> 08048000-08056000 r-xp 00000000 08:06 246208 =20 >>>> =20 >>> /usr/local/j2sdk1.4.2_06/bin/java >>> =20 >>>> 08056000-08059000 rwxp 0000d000 08:06 246208 =20 >>>> =20 >>> /usr/local/j2sdk1.4.2_06/bin/java >>> =20 >>>> 40000000-40011000 r-xp 00000000 08:05 212994 /lib/ld-2.3.3.so >>>> 40011000-40012000 rwxp 00011000 08:05 212994 /lib/ld-2.3.3.so >>>> 40018000-40026000 r-xp 00000000 08:05 213024 /lib/libpthread-0.1= 0.so >>>> 40026000-40028000 rwxp 0000d000 08:05 213024 /lib/libpthread-0.1= 0.so >>>> 4006a000-4006c000 r-xp 00000000 08:05 213005 /lib/libdl-2.3.3.so= >>>> 4006c000-4006d000 rwxp 00001000 08:05 213005 /lib/libdl-2.3.3.so= >>>> 4006d000-40167000 r-xp 00000000 08:05 213001 /lib/libc-2.3.3.so >>>> 40167000-40170000 rwxp 000fa000 08:05 213001 /lib/libc-2.3.3.so >>>> 40173000-4056f000 r-xp 00000000 08:06 134540 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so >>>> 4056f000-4058b000 rwxp 003fb000 08:06 134540 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/client/libjvm.so >>>> 405a2000-405b1000 r-xp 00000000 08:05 213009 /lib/libnsl-2.3.3.s= o >>>> 405b1000-405b2000 rwxp 0000f000 08:05 213009 /lib/libnsl-2.3.3.s= o >>>> 405b4000-405d4000 r-xp 00000000 08:05 213007 /lib/libm-2.3.3.so >>>> 405d4000-405d5000 rwxp 0001f000 08:05 213007 /lib/libm-2.3.3.so >>>> 405d5000-405dd000 r-xp 00000000 08:06 101710 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so >>>> 405dd000-405de000 rwxp 00007000 08:06 101710 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/native_threads/libhpi.so >>>> 405de000-405e2000 rwxs 00000000 08:09 14628 =20 >>>> =20 >>> /tmp/hsperfdata_callstart/19866 >>> =20 >>>> 405e3000-405ec000 r-xp 00000000 08:05 213015 =20 >>>> =20 >>> /lib/libnss_files-2.3.3.so >>> =20 >>>> 405ec000-405ed000 rwxp 00009000 08:05 213015 =20 >>>> =20 >>> /lib/libnss_files-2.3.3.so >>> =20 >>>> 405ed000-405fd000 r-xp 00000000 08:06 101717 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so >>>> 405fd000-405ff000 rwxp 0000f000 08:06 101717 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/libverify.so >>>> 405ff000-4061f000 r-xp 00000000 08:06 101718 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so >>>> 4061f000-40621000 rwxp 0001f000 08:06 101718 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/libjava.so >>>> 40621000-40635000 r-xp 00000000 08:06 101720 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so >>>> 40635000-40638000 rwxp 00013000 08:06 101720 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/i386/libzip.so >>>> 40638000-41fdf000 r-xs 00000000 08:06 101803 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/rt.jar >>>> 42029000-4203f000 r-xs 00000000 08:06 101742 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/sunrsasign.jar >>>> 4203f000-4211c000 r-xs 00000000 08:06 101787 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/jsse.jar >>>> 4211c000-4212d000 r-xs 00000000 08:06 101743 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/jce.jar >>>> 4212d000-42686000 r-xs 00000000 08:06 101788 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/charsets.jar >>>> 4472e000-4472f000 r-xs 00000000 08:06 117021 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/Itau.jar >>>> 4c7b0000-4c7cc000 r-xs 00000000 08:06 117679 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/sunjce_provider.jar >>>> 4c7cc000-4c7cf000 r-xs 00000000 08:06 117680 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/dnsns.jar >>>> 4c7cf000-4c7dc000 r-xs 00000000 08:06 117682 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/ldapsec.jar >>>> 4c7dc000-4c898000 r-xs 00000000 08:06 117684 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/localedata.jar >>>> 4c898000-4c8a6000 r-xs 00000000 08:06 117022 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/activation.jar >>>> 4c8a6000-4c8d3000 r-xs 00000000 08:06 117023 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/mailapi.jar >>>> 4c8d3000-4c92a000 r-xs 00000000 08:06 117024 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/mail.jar >>>> 4c92a000-4c930000 r-xs 00000000 08:06 117025 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/pop3.jar >>>> 4c930000-4c936000 r-xs 00000000 08:06 117026 >>>> /usr/local/j2sdk1.4.2_06/jre/lib/ext/smtp.jar >>>> 4c936000-4c939000 r-xp 00000000 08:06 377923 >>>> /usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConnection= =2Eso >>>> 4c939000-4c93a000 rwxp 00002000 08:06 377923 >>>> /usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRConnection= =2Eso >>>> 4c93a000-4c950000 r-xp 00000000 08:06 265533 >>>> /usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35.so.1= =2E0.0 >>>> 4c950000-4c953000 rwxp 00015000 08:06 265533 >>>> /usr/src/sqlrelay-0.35/src/api/c++/src/.libs/libsqlrclient-0.35.so.1= =2E0.0 >>>> 4c953000-4c998000 r-xp 00000000 08:06 377564 >>>> /usr/local/firstworks/lib/librudiments-0.27.so.1.0.0 >>>> 4c998000-4c9a2000 rwxp 00044000 08:06 377564 >>>> /usr/local/firstworks/lib/librudiments-0.27.so.1.0.0 >>>> 4c9a7000-4c9d2000 r-xp 00000000 08:06 115308 /usr/lib/libssl.so.= 0.9.7 >>>> 4c9d2000-4c9d5000 rwxp 0002a000 08:06 115308 /usr/lib/libssl.so.= 0.9.7 >>>> 4c9d5000-4caab000 r-xp 00000000 08:06 115306 =20 >>>> =20 >>> /usr/lib/libcrypto.so.0.9.7 >>> =20 >>>> 4caab000-4cabc000 rwxp 000d6000 08:06 115306 =20 >>>> =20 >>> /usr/lib/libcrypto.so.0.9.7 >>> =20 >>>> 4cac0000-4cac4000 r-xp 00000000 08:05 213003 /lib/libcrypt-2.3.3= =2Eso >>>> 4cac4000-4cac5000 rwxp 00003000 08:05 213003 /lib/libcrypt-2.3.3= =2Eso >>>> 4caec000-4cb8a000 r-xp 00000000 08:06 114711 =20 >>>> =20 >>> /usr/lib/libstdc++.so.5.0.5 >>> =20 >>>> 4cb8a000-4cba0000 rwxp 0009d000 08:06 114711 =20 >>>> =20 >>> /usr/lib/libstdc++.so.5.0.5 >>> =20 >>>> 4cba5000-4cbac000 r-xp 00000000 08:06 114701 /usr/lib/libgcc_s.s= o.1 >>>> 4cbac000-4cbad000 rwxp 00006000 08:06 114701 /usr/lib/libgcc_s.s= o.1 >>>> 4cbad000-4cbb7000 r-xp 00000000 08:06 377924 >>>> /usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCursor.so >>>> 4cbb7000-4cbb9000 rwxp 0000a000 08:06 377924 >>>> /usr/local/firstworks/java/com/firstworks/sqlrelay/libSQLRCursor.so >>>> =20 >>>> Heap at VM Abort: >>>> Heap >>>> def new generation total 576K, used 236K [0x44730000, 0x447d0000, >>>> =20 >>> 0x44c10000) >>> =20 >>>> eden space 512K, 43% used [0x44730000, 0x44767248, 0x447b0000) >>>> from space 64K, 24% used [0x447b0000, 0x447b3fa8, 0x447c0000) >>>> to space 64K, 0% used [0x447c0000, 0x447c0000, 0x447d0000) >>>> tenured generation total 1408K, used 339K [0x44c10000, 0x44d70000,= >>>> =20 >>> 0x48730000) >>> =20 >>>> the space 1408K, 24% used [0x44c10000, 0x44c64f58, 0x44c65000, >>>> =20 >>> 0x44d70000) >>> =20 >>>> compacting perm gen total 4096K, used 1696K [0x48730000, >>>> =20 >>> 0x48b30000, 0x4c730000) >>> =20 >>>> the space 4096K, 41% used [0x48730000, 0x488d8380, 0x488d8400, >>>> =20 >>> 0x48b30000) >>> >>> =20 >>>> Local Time =3D Fri Nov 11 15:34:29 2005 >>>> Elapsed Time =3D 771 >>>> # >>>> # The exception above was detected in native code outside the VM >>>> # >>>> # Java VM: Java HotSpot(TM) Client VM (1.4.2_06-b03 mixed mode) >>>> - >>>> --------------------------------------------------------------------= ------------------------------------ >>>> =20 >>>> At the moment is not so easy for me to update to 0.36.x. >>>> Does some one can help with that problem? >>>> =20 >>>> Thanks in advance. >>>> -- >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> Rodrigo P. Telles <te...@de...> >>>> IT Manager >>>> Devel-IT - http://www.devel.it >>>> IVOZ # 1029 >>>> +55 14 3324-1200 >>>> Bestcom Group >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> =20 >>> ------------------------------------------------------- >>> SF.Net email is sponsored by: >>> Tame your development challenges with Apache's Geronimo App Server. >>> Download >>> it for free - -and be entered to win a 42" plasma tv or your very own= >>> Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php= >>> _______________________________________________ >>> Sqlrelay-discussion mailing list >>> Sql...@li... >>> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion >>> >>> >>> >>> >>> >>> =20 >>>> ------------------------------------------------------- >>>> This SF.Net email is sponsored by the JBoss Inc. Get Certified Toda= y >>>> Register for a JBoss Training Course. Free Certification Exam >>>> for All Training Attendees Through End of 2005. For more info visit:= >>>> http://ads.osdn.com/?ad_id=3D7628&alloc_id=3D16845&op=3Dclick >>>> _______________________________________________ >>>> Sqlrelay-discussion mailing list >>>> Sql...@li... >>>> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion >>>> =20 >>> >>> =20 > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log = files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!= > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat= =3D121642 > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > =20 |
|
From: Maciej W. <mac...@co...> - 2006-01-25 08:00:42
|
I've checked version 0.37pre5 and when compiling it with postgres I get the error as below. Without postgres it installs correctly. make[3]: Entering folder `/home/zope/install/sqlrelay_3.7_pre5/sqlrelay-0.37/src/connections/postgresql' /bin/sh ../../../libtool --mode=compile g++ -Wall -pipe -pthread -I./ -I../../../ -I../../../src/common -I../../../src/util -I../../../src/connection -I/usr/local/firstworks/include -pthread -I/usr/kerberos/include -I../../../src/api/c++/include -c postgresqlconnection.C -o postgresqlconnection.lo mkdir .libs g++ -Wall -pipe -pthread -I./ -I../../../ -I../../../src/common -I../../../src/util -I../../../src/connection -I/usr/local/firstworks/include -pthread -I/usr/kerberos/include -I../../../src/api/c++/include -c postgresqlconnection.C -fPIC -DPIC -o .libs/postgresqlconnection.o postgresqlconnection.C:175: definition of implicitly-declared `virtual postgresqlcursor::~postgresqlcursor()' make[3]: *** [postgresqlconnection.lo] Error 1 make[3]: Leaving folder `/home/zope/install/sqlrelay_3.7_pre5/sqlrelay-0.37/src/connections/postgresql' make[2]: *** [all] Error 2 make[2]: Leaving folder `/home/zope/install/sqlrelay_3.7_pre5/sqlrelay-0.37/src/connections' make[1]: *** [all] Error 2 make[1]: Leaving folder `/home/zope/install/sqlrelay_3.7_pre5/sqlrelay-0.37/src' make: *** [all] Error 2 -- Maciej Wisniowski |
|
From: Batoussa M. <bmo...@sa...> - 2006-01-25 03:26:08
|
Sorry, I didn't notice the TODO list.
So, did it plan to have an sqlrelay ODBC API that could interface
unixODBC?
=20
Thank you
=20
_____ =20
From: Batoussa Mougamadou=20
Sent: Tuesday, January 24, 2006 4:07 PM
To: 'sql...@li...'
Subject: Calling SQLRelay with UnixODBC
=20
Hi,
=20
Sqlrelay permits to connect to a database using ODBC connection
(compiled against unixODBC in my case), and it works fine.
Is it possible to connect via unixODBC (using sqlrelay client ...) to a
sqlrelay listener? Or must I implement a specific ODBC Driver which will
use sqlrelay client API?
=20
I mean the following architecture:
=20
Client
Server
[isql -> unixODBC -> sqlrelay client ] <-- network --> [sqlrelay
(daemon/listener) -> unixODBC -> oracle10g]
=20
Thank you
|
|
From: Batoussa M. <bmo...@sa...> - 2006-01-24 21:07:29
|
Hi,
=20
Sqlrelay permits to connect to a database using ODBC connection
(compiled against unixODBC in my case), and it works fine.
Is it possible to connect via unixODBC (using sqlrelay client ...) to a
sqlrelay listener? Or must I implement a specific ODBC Driver which will
use sqlrelay client API?
=20
I mean the following architecture:
=20
Client
Server
[isql -> unixODBC -> sqlrelay client ] <-- network --> [sqlrelay
(daemon/listener) -> unixODBC -> oracle10g]
=20
Thank you
|
|
From: Dominik M. <ne...@gm...> - 2006-01-24 15:05:33
|
Thanks for your reply. In the meantime, I've found out that it works if I start sqlrelay as the oracle user. So I guess it has something to do with the environment. I'll ask my DBA. Thanks again, Dominik On Tue, 2006-01-24 at 21:47 +0700, Rachman Chavik wrote: > Dominik Meister wrote: > > Hello > > > > First, I'm completely new to sqlrelay. I've installed it to use it with > > an Oracle 10g database. > > > > The relevant part of my sqlrelay.conf file looks like this: > > > > <connection connectionid="exampleconnection" > > string="user=my_user;password=my_password;oracle_sid=DVECILS;" > > metric="1"/> > > > > The tnsnames.ora file looks like this: > > DVECILS = > > (DESCRIPTION = > > (ADDRESS = (PROTOCOL = TCP)(HOST = labdev)(PORT = 1521)) > > (CONNECT_DATA = > > (SERVER = DEDICATED) > > (SID = dvecils) > > ) > > ) > > > > Whenever I start sqlrelay I get: > > > > Starting 3 connections to labdev : > > sqlr-connection-oracle8 -id labdev -connectionid labdev > > -config ../etc/sqlrelay.conf > > OCIServerAttach() failed. > > > > > > ORA-12154: TNS:could not resolve the connect identifier specified > > > > Couldn't log into database. > > > > sqlr-connection-oracle8 failed to start. > > > > > > If I'm trying to connect directly with sqlplus or from a remote machine > > with the Oracle Client everything works fine. > > > > What am I doing wrong? > > > > Thanks, Dominik > > > > Make sure that SQLrelay gets the appropriate Oracle environment. > Normally, source /usr/local/bin/oraenv before starting sqlrelay. > > Furthermore, to test whether your Oracle Net is configured properly, > do: > $ tnsping DVECILS > > $ sqlplus username/password@DVECILS > > if you simply use user/pass without the @DEVCILS, sqlplus does not use > Oracle Net. Someone please correct me if I'm wrong. > > Rgds -- Dominik Meister <ne...@gm...> My public GnuPG key is available at http://meischter.homelinux.org/gpg.txt |
|
From: Rachman C. <rc...@at...> - 2006-01-24 14:46:29
|
Dominik Meister wrote: > Hello > > First, I'm completely new to sqlrelay. I've installed it to use it with > an Oracle 10g database. > > The relevant part of my sqlrelay.conf file looks like this: > > <connection connectionid="exampleconnection" > string="user=my_user;password=my_password;oracle_sid=DVECILS;" > metric="1"/> > > The tnsnames.ora file looks like this: > DVECILS = > (DESCRIPTION = > (ADDRESS = (PROTOCOL = TCP)(HOST = labdev)(PORT = 1521)) > (CONNECT_DATA = > (SERVER = DEDICATED) > (SID = dvecils) > ) > ) > > Whenever I start sqlrelay I get: > > Starting 3 connections to labdev : > sqlr-connection-oracle8 -id labdev -connectionid labdev > -config ../etc/sqlrelay.conf > OCIServerAttach() failed. > > > ORA-12154: TNS:could not resolve the connect identifier specified > > Couldn't log into database. > > sqlr-connection-oracle8 failed to start. > > > If I'm trying to connect directly with sqlplus or from a remote machine > with the Oracle Client everything works fine. > > What am I doing wrong? > > Thanks, Dominik > Make sure that SQLrelay gets the appropriate Oracle environment. Normally, source /usr/local/bin/oraenv before starting sqlrelay. Furthermore, to test whether your Oracle Net is configured properly, do: $ tnsping DVECILS $ sqlplus username/password@DVECILS if you simply use user/pass without the @DEVCILS, sqlplus does not use Oracle Net. Someone please correct me if I'm wrong. Rgds -- Rachman Chavik email: rc...@at... email: ra...@ch... email: rc...@et... www: http://www.chavik.com |
|
From: Maciej W. <mac...@co...> - 2006-01-24 13:27:12
|
> Ehm... I'm not sure now but possibly 1.4. My java version is 1.4.2_04. > I'll check this and the fix tomorrow. I'm not able to check this installation today. I'll let you know whether it works tomorrow. -- Maciej Wisniowski |
|
From: Dominik M. <ne...@gm...> - 2006-01-24 11:34:37
|
Hello
First, I'm completely new to sqlrelay. I've installed it to use it with
an Oracle 10g database.
The relevant part of my sqlrelay.conf file looks like this:
<connection connectionid="exampleconnection"
string="user=my_user;password=my_password;oracle_sid=DVECILS;"
metric="1"/>
The tnsnames.ora file looks like this:
DVECILS =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = labdev)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SID = dvecils)
)
)
Whenever I start sqlrelay I get:
Starting 3 connections to labdev :
sqlr-connection-oracle8 -id labdev -connectionid labdev
-config ../etc/sqlrelay.conf
OCIServerAttach() failed.
ORA-12154: TNS:could not resolve the connect identifier specified
Couldn't log into database.
sqlr-connection-oracle8 failed to start.
If I'm trying to connect directly with sqlplus or from a remote machine
with the Oracle Client everything works fine.
What am I doing wrong?
Thanks, Dominik
--
Dominik Meister <ne...@gm...>
My public GnuPG key is available at http://meischter.homelinux.org/gpg.txt
|
|
From: david b. f. <df...@vi...> - 2006-01-24 09:09:17
|
HELLO Has the technology advance we have to follow. I would request to our great designer of SQLrelay. If he could write an PDO extension for sqlrelay. As PDO is an universal wrapper, and that PDO is very much faster than PEAR::DB, that could improve enormously the performance of database connection for php. Regards David |
|
From: Batoussa M. <bmo...@sa...> - 2006-01-23 22:21:04
|
Sorry, I found how it works. I am trying it right now. =20 Thank you =20 _____ =20 From: Batoussa Mougamadou=20 Sent: Monday, January 23, 2006 4:39 PM To: 'sql...@li...' Subject: SQLRelay ODBC Mode with UnixODBC =20 Hi, =20 I need clarification about how sqlrelay works with unixODBC. I'm trying to connect oracle10g. I have a unixODBC installed, and the associated ODBC driver compiled. How should I use sqlrelay in order to use the ODBC driver compiled for unixODBC to connect the database? During the installation, it seems that the ODBC connection is dynamic; does it mean that I need to create my proper program to connect via sqlrelay? =20 Thanks you for your help. |
|
From: Batoussa M. <bmo...@sa...> - 2006-01-23 22:09:27
|
Sorry, I found how it works. I am trying it right now. =20 Thank you =20 _____ =20 From: Batoussa Mougamadou=20 Sent: Monday, January 23, 2006 4:39 PM To: 'sql...@li...' Subject: SQLRelay ODBC Mode with UnixODBC =20 Hi, =20 I need clarification about how sqlrelay works with unixODBC. I'm trying to connect oracle10g. I have a unixODBC installed, and the associated ODBC driver compiled. How should I use sqlrelay in order to use the ODBC driver compiled for unixODBC to connect the database? During the installation, it seems that the ODBC connection is dynamic; does it mean that I need to create my proper program to connect via sqlrelay? =20 Thanks you for your help. |
|
From: Batoussa M. <bmo...@sa...> - 2006-01-23 21:40:08
|
Hi, =20 I need clarification about how sqlrelay works with unixODBC. I'm trying to connect oracle10g. I have a unixODBC installed, and the associated ODBC driver compiled. How should I use sqlrelay in order to use the ODBC driver compiled for unixODBC to connect the database? During the installation, it seems that the ODBC connection is dynamic; does it mean that I need to create my proper program to connect via sqlrelay? =20 Thanks you for your help. |
|
From: Maciej W. <mac...@co...> - 2006-01-23 19:46:40
|
> If we trigger stand-alone processes that create a number of connections Do you mean that one process creates multiple connections? What language do you use. I'm not sure if I understand you but maybe you are not using delete with cursors? I had a problem in java application that after calling three queries with three cursor objects (3 connections in conf) the next cursor.sendQuery statement hanged. It was because I was not using cursor.delete() function to remove the already used cursor (in Python there is no need to use delete() so I forgot about this thing in Java). Maybe it is something similiar in your case. -- Maciej Wisniowski |
|
From: Ulises R. <ul...@gm...> - 2006-01-23 18:44:55
|
Hi, We are doing some tests to see the performance of SQL-Relay. We have tried changing the parameters of the sqlrelay.conf file to see what gives us better results and we found a problem: If we trigger stand-alone processes that create a number of connections greater that the value of 'connections + maxqueuelength' the whole SQLRelay freezes (and crashes) and we will have to restart it (sqlr-stop and sqlr-start). This is independent of the number specified in maxconnections, say if we have: ... connections=3D"30" maxconnections=3D"150" maxqueuelenght=3D"80" .. in our conf file and we have < 30+80 DB connections, but if we open a new connection then all the other connections seem to stop working. Please let me know if this is a bug or what I am doing wrong. Thanks. Ulises |
|
From: Maciej W. <mac...@co...> - 2006-01-23 18:15:58
|
> I just fixed that and uploaded 0.37pre5 to > http://www.firstworks.com/sqlrelay-0.37pre5.tar.gz Thanks for the fast answer and fix :) > What version of java are you using? Ehm... I'm not sure now but possibly 1.4. I'll check this and the fix tomorrow. -- Maciej Wisniowski |
16 messages has been excluded from this view by a project administrator.
