...

If I run merovingian and then try to connect to my

database using JDBC through my Java app, I get this error returned by JDBC:

...

"Maximum number of redirects reached, aborting

connection attempt. Sorry."

Please run: java -jar jdbcclient.jar --database=yourdb -Xdebug here, and send me the resulting monet_XXXXXXXXXXXXXXXXXXXXXX.log file.

OK, but please note that I do NOT have this 'max redirects reached' problem when I use jdbcclient.jar. I only have this issue when I use JDBC through my web app (which internally uses JDBC to talk to the db). Also note that if I use mserver5 instead of Merovingian than everything works fine from my Java app with JDBC! So the problem is specifically with use on Merovingian.

It dawned on me that perhaps my JDBC connection is not correct for use with Merovingian. I am using this: jdbc:monetdb://localhost:50000

and uname/password is passed in separately. Is that correct? Perhaps this string needs to be different when using Merovingian instead of mserver5?

At any rate, here is the log file in case the trace tells you anything interesting. Remember that this connects and works ok:

------------------- RD 1213450401466: read final block: 28 bytes RX 1213450401467: void:merovingian:8:plain:LIT RD 1213450401467: inserting prompt TD 1213450401467: write final block: 48 bytes TX 1213450401467: BIG:merovingian:{plain}merovingianvoid:sql:demo: RD 1213450401468: read final block: 24 bytes RX 1213450401468: ^mapi:merovingian:proxy

RD 1213450401468: inserting prompt RD 1213450401468: read final block: 35 bytes RX 1213450401468: zdvrv48oh:mserver:8:crypt,plain:LIT RD 1213450401468: inserting prompt TD 1213450401469: write final block: 45 bytes TX 1213450401469: BIG:monetdb:{plain}monetdbzdvrv48oh:sql:demo: RD 1213450401469: read final block: 0 bytes RX 1213450401469: RD 1213450401469: inserting prompt TD 1213450401473: write final block: 48 bytes TX 1213450401474: sSET TIME ZONE INTERVAL '-04:00' HOUR TO MINUTE; RD 1213450401474: read final block: 0 bytes RX 1213450401474: RD 1213450401474: inserting prompt TD 1213450401485: write final block: 15 bytes TX 1213450401485: Xreply_size 250 RD 1213450401485: read final block: 0 bytes RX 1213450401485: RD 1213450401486: inserting prompt TD 1213450401486: write final block: 46 bytes TX 1213450401486: sSELECT "name", "value" FROM sys.env() as env; RD 1213450401487: read final block: 1600 bytes RX 1213450401487: &1 0 44 2 44 % .env, .env # table_name % name, value # name % varchar, varchar # type % 17, 61 # length [ "gdk_arch", "32biti686-pc-linux-gnu" ] [ "gdk_version", "1.24.0" ] [ "monet_pid", "1192" ] [ "prefix", "/usr" ] [ "exec_prefix", "/usr" ] [ "gdk_dbname", "demo" ] [ "gdk_dbfarm", "/usr/var/MonetDB5/dbfarm" ] [ "gdk_debug", "0" ] [ "gdk_mem_bigsize", "262144" ] [ "gdk_alloc_map", "no" ] [ "gdk_mem_pagebits", "14" ] [ "gdk_vmtrim", "yes" ] [ "monet_admin", "adm" ] [ "monet_prompt", ">" ] [ "monet_welcome", "yes" ] [ "monet_mod_path", "/usr/lib/MonetDB5:/usr/lib/MonetDB5/lib:/usr/lib/MonetDB5/bin" ] [ "monet_daemon", "yes" ] [ "host", "localhost" ] [ "mapi_port", "0" ] [ "mapi_noheaders", "no" ] [ "mapi_debug", "0" ] [ "mapi_clients", "2" ] [ "sql_debug", "0" ] [ "sql_logdir", "/usr/var/MonetDB5/sql_logs" ] [ "xquery_logdir", "/usr/var/MonetDB/xquery_logs" ] [ "standoff_ns", "http://monetdb.cwi.nl/standoff" ] [ "standoff_start", "start" ] [ "standoff_end", "end" ] [ "config", "/usr/etc/monetdb5.conf" ] [ "mapi_open", "true" ] [ "monet_vault_key", "/usr/var/MonetDB5/dbfarm/demo/.vaultkey" ] [ "gdk_embedded", "no" ] [ "mero_msglog", "/usr/var/log/merovingian.log" ] [ "mero_errlog", "/usr/var/log/merovingian.log" ] [ "mero_timeinterval", "600" ] [ "mero_pidfile", "/usr/var/run/merovingian.pid" ] [ "mero_exittimeout", "7" ] [ "mero_doproxy", "yes" ] [ "mero_discoveryttl", "600" ] [ "mal_init", "/usr/lib/MonetDB5/mal_init.mal" ] [ "mal_listing", "15" ] [ "checkpoint_dir", "/usr/var/MonetDB5/chkpnt" ] [ "sql_init", "/usr/lib/MonetDB5/sql_init.sql" ] [ "monet_version", "5.6.0" ]

RD 1213450401487: inserting prompt ---------------------

I noticed that your system does not have openssl and/or libpcre available. The first might cause this behaviour if something is really messed up in the code. So, please send me the logfile.

Actually I do have openssl installed. I built it from source a while back and it works fine when I manually use the openssl command, but perhaps I didn't get it to install properly into the dirs/lib dirs apps are looking in for its libraries?

*** The two most important points that I cannot stress enough that may be good clues as to what is causing this are as follows:

1) JDBC through jdbcclient.jar works, but JDBC through my Java servlet does not.

Here is a snippet of the config file I use to instruct my servlet how to talk to JDBC:

<init-param> <param-name>driver</param-name> <param-value>nl.cwi.monetdb.jdbc.MonetDriver</param-value> <description>JDBC driver class</description> </init-param> <init-param> <param-name>url</param-name> <param-value>jdbc:monetdb://localhost:50000/demo</param-value> <description>The JDBC connect string to use</description> </init-param> <init-param> <param-name>user</param-name> <param-value>monetdb</param-value> <description>username</description> </init-param> <init-param> <param-name>password</param-name> <param-value>monetdb</param-value> <description>password</description> </init-param>

2) If I run mserver5 INSTEAD of merovingian, than JDBC through my Java serlvet works just fine!

What do you suggest I try next either to resolve it or to collect more troubleshooting information?

Thank you!

Great. Then it is exactly what I thought: a bug I already solved. You can interchange the jdbcclient.jar with your monetdb-jdbc-1.X.jar file. The former contains the latter, and in your case, the latter is outdated.

Thank you - I'm using your jdbcclient.jar instead of the 1.7 driver and indeed it is now working great!!! Thank you.

I was surprised that the nightly stable does not contain a source build of the latest jdbc driver (at least, not that I can find) but yours is working nicely.

The only other hurdles I have left to cover is that we really need and aggregate median() function (which I understand is now on the wish-list) and hopefully there is already a standard deviation function (i.e. std() or stdev() etc. I haven't found one so far but have an open email on the list with the inquiry.

Fabian Groffen wrote:

On 15-06-2008 10:21:50 -0700, Rt Ibmer wrote:

...

...

Great. Then it is exactly what I thought: a bug I already solved. You can interchange the jdbcclient.jar with your monetdb-jdbc-1.X.jar file. The former contains the latter, and in your case, the latter is outdated.

Thank you - I'm using your jdbcclient.jar instead of the 1.7 driver and indeed it is now working great!!! Thank you.

I was surprised that the nightly stable does not contain a source build of the latest jdbc driver (at least, not that I can find) but yours is working nicely.

It's in the "java" repository, and should automagically be built if you use the monetdb-install.sh script provided you have javac and ant available.

...

The only other hurdles I have left to cover is that we really need and aggregate median() function (which I understand is now on the wish-list) and hopefully there is already a standard deviation function (i.e. std() or stdev() etc. I haven't found one so far but have an open email on the list with the inquiry.

stddev(), variance() and median() not (yet) a built-in. The addition of these statistical primitives require an extension to the aggr.mx module, one that is on the list to be re-designed. Don't expect these functions to become available in the upcoming release.

There is a bug on SourceForge on this functionc, IIRC.

---

Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers