Re: Ingres JDBC driver hangs on getting a connection

Hi Daniel,
with your tips for the configuration of Hibernate and Ingres I finally
succeeded running the complete Hibernate Junit test suite (excluding
the ConnectionTests). On my desktop PC (Intel Duo core, 2GB mem, XP
Prof.) it took about 2 hours. The test suite reported 22 failures and
94 errrors. The Ingres error log stated some errors like this:
"E_OP0280_SCOPE consistency check - scoping rules for variables used
in query were violated." and "E_GC4810_TL_FSM_STATE GCD Server
internal error: Invalid state transition in TL FSM. Input = 5, state =
0".

Ciao, Carlo
On 25 Jun., 08:41, Carlo <carlo...@xxxxxxxxxxxxxx> wrote:
Hello Daniel,

thanks for your interest in my problems and for the tips how to run
Hibernate's test suite. I will retry it with these.

Ciao,
Carlo

On 22 Jun., 11:10, DanielL <daniel.la...@xxxxxxxxxx> wrote:

Hello Carlo,

here are the best settings so far or running the test suite. They are
not quite optimal for normal applications, but the test suite has some
dirty programming like didn't close all sessions, that consumes lot of
performance etc.:

Ingres changes

DBMS Server
connect_limit=256
system_timeout=10
default_page_size=8192

Name Server
session_limit=256

Locking System
per_tx_limit=2500

Hibernate Changes

/etc/hibernate.properties

changes in the query language section:
hibernate.query.substitutions true=1, false=0, yes='Y', no='N'

changes in the jdbc section:
hibernate.connection.isolation 1
hibernate.jdbc.use_scrollable_resultset true

You can also switch the validate_failure_expected flag in the
build.xml, it then disables reporting expected failures in the test
report. They are irritating, because you didn't know whether Hibernate
wants to produce the failure, or something is going wrong.

Ingres doesn't support reverse scrolling cursors and cursor type
TYPE_SCROLLING_INSENSITIVE at the moment.
Because of this the connection suite runs into a lock situation, which
can only be handled by using the ipm and killing the sessions, but the
best would be disabling the connection test.

There will be a new dialect file in the next days, that fixes some
remaining problems.

There are some other restrictions mentioned in the Ingres
Documentation regarding the jdbc driver e.g. no LOB locators, but all
of them will be fixed or implemented in the next releases. These
limitations will cause some of the test fail.

When disabling the connection test, the test suite should be run in
quite less than an hour dependent on your computer performance.

Regards,

Daniel

On Jun 22, 8:53 am, Carlo <carlo...@xxxxxxxxxxxxxx> wrote:

Hi Daniel,

I'm using Hibernate 3.2.3.ga, and in my hibernate.properties, these
lines are used:
-hibernate.dialect org.hibernate.dialect.IngresDialect
-hibernate.connection.driver_class com.ingres.jdbc.IngresDriver
-hibernate.connection.url jdbc:ingres://localhost:II7/
test;CURSOR=READONLY;auto=multi

Meanwhile I have fiddled around with some properties: first I enabled
Hibernates' C3P0 connection pool (min=6, max=12). After that, I had
the impression, that with this connection pooling the tests ran
better. But then it ended in the same behaviour of inactiv processes.
Then I tried with changes in the configuration of Data Access Server:
I enabled connection pooling here also, setting the client_timeout to
30 and (after another unsuccessful test) I set the
connection_pool_expire to 60. Same results anyway, I thought yesterday
afternoon: after restarting the testsuite at 14:46, I noticed at 15:42
(by consulting the SysInternal process viewer) that there seemed to be
no more activity neither at the Java process nor at the Ingres
processes. I left work office (frustrated...).

Now, this morning, the first thing I noticed was the windows error
dialog stating that Data Access Server did crash! Wow, and then I
looked into the Ingres error.log and found some interesting things:
after reporting idle client connections which it was aborting, the
system reported errors:
eit-bld-::[II\DASVR\ab4 , 00000000]: Thu Jun 21 16:15:39 2007
E_GC480D_IDLE_LIMIT Client has been idle longer than the configured
limit: connection aborted.
eit-bld-::[II\DASVR\ab4 , 00000000]: Thu Jun 21 16:15:42 2007
E_GC4810_TL_FSM_STATE GCD Server internal error:
Invalid state transition in TL FSM.
Input = 5, state = 0

And, interestingly, after I OK-ayed the Microsoft crash report, and
Data Access Server died, the Hibernate test suite continued to run!
(of course, it couldn't get any more db connections).

Well, and what I could see after the several runs of the test suite is
that the JPALockTest (org.hibernate.test.jpa.lock.JPALockTest) always
lead to the problem of no further activities (but it wasn't always
this test, as apparently the testsuite runs in some kind of random
order; on my first tests it was the ConnectionsSuite which led to the
inactivity; and i tried with commenting it out).

Besides this main problem, I of course noticed a lot of errors and
failures reported by the Hibernate test suite...

On 21 Jun., 17:25, DanielL <daniel.la...@xxxxxxxxxx> wrote:

Hello Carlo,

could you give me some details about which Hibernate 3.2 version you
are using, the first 3 lines of the "## Ingres 2006 or later" section
in hibernate.properties and which test cases are causing this error?

Thanks and Regards,

Daniel

Carlo wrote:
Hi,

I'm evaluating the Ingres DB (ingres2006-9.1.0) for a project where we
are planning to use it with Hibernate 3.2. I installed the server
software locally on my Windows XP system and I'm using the Jdbc Driver
V-9.1.0. Now I'm just trying to see how good this system works with
Hibernate, so running the Hibernate Junit testsuite is a good
candidate for this purpose.

Unfortunately - besides some errors the testsuite soon reports (mostly
because of limitations of the jdbc driver) - the testsuite soon stops
running. It seems the Java process is trying to open a jdbc connection
on the database, and the call doesn't come back - the process is just
hanging around (I think in some native call, as Sysinternals
processExplorer tells so). If I open the Ingres error log, I see the
following last log entries:
"E_GC4807_CONN_ABORT Aborting client connection, reason follows.
eit-bld-::[II\DASVR\604 , 00000000]: Wed Jun 20 14:41:27 2007
E_CL2784_GC_RECEIVE_FAIL An attempted network receive failed".

My first attempt was to exclude some connection tests which do hard
connection testings. But this didn't help. At some other test the same
problem reoccurs.

Does any of you Ingres guys have an idea what's going on and what I
can do to solve the problem?

Carlo


.

Relevant Pages

  • Re: Ingres JDBC driver hangs on getting a connection
    ... here are the best settings so far or running the test suite. ... because you didn't know whether Hibernate ... Ingres doesn't support reverse scrolling cursors and cursor type ... best would be disabling the connection test. ...
    (comp.databases.ingres)
  • Re: Ingres JDBC driver hangs on getting a connection
    ... here are the best settings so far or running the test suite. ... because you didn't know whether Hibernate ... Ingres doesn't support reverse scrolling cursors and cursor type ... best would be disabling the connection test. ...
    (comp.databases.ingres)
  • Re: Ingres JDBC driver hangs on getting a connection
    ... that with this connection pooling the tests ran ... no more activity neither at the Java process nor at the Ingres ... after reporting idle client connections which it was aborting, ... the Hibernate test suite continued to run! ...
    (comp.databases.ingres)
  • Ingres JDBC driver hangs on getting a connection
    ... I'm evaluating the Ingres DB for a project where we ... Hibernate, so running the Hibernate Junit testsuite is a good ... Unfortunately - besides some errors the testsuite soon reports (mostly ... My first attempt was to exclude some connection tests which do hard ...
    (comp.databases.ingres)
  • Hibernate, JBoss 4, MySQL5 Problem
    ... und Hibernate zu realisieren. ... WARN [LocalManagedConnectionFactory] Destroying connection that is not ... object is not an instance of declaring class ...
    (de.comp.lang.java)