You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Passalacqua Nicolas <np...@prosodie.com> on 2007/04/19 15:05:10 UTC

ofbiz down

Hi there,

 

We get trouble with minerva connexion pool. 

 

We digging through, but I was just wondering if somebody already see
this?

 

We work on a postgres database.

 

Regards,

 

Nick 


Re: ofbiz down

Posted by Ashish Vijaywargiya <as...@adititechlabs.com>.
Hi Nick,

It might be much better if you will provide some more details.

1) Log Error.
2) Which revision of Ofbiz are you using ??
3) Have you kept the postgres connector in framework/entity/lib/jdbc ??


On 4/19/07, Passalacqua Nicolas <np...@prosodie.com> wrote:
>
> Hi there,
>
>
>
> We get trouble with minerva connexion pool.
>
>
>
> We digging through, but I was just wondering if somebody already see
> this?
>
>
>
> We work on a postgres database.
>
>
>
> Regards,
>
>
>
> Nick
>
>


-- 
Thanks & Regards
Ashish Vijaywargiya
Aditisoft Technology Laboratory
http://www.adititechlabs.com
ashish.vijaywargiya@adititechlabs.com
__________________________________
Office          :  509.855.4113
Cellphone    :  +919893479711

Re: TR: ofbiz down

Posted by Walter Vaughan <wv...@steelerubber.com>.
Cléms wrote:

> We got a lot of locking trouble as we analyse postgresql logs.
> Our configuration:
> Postgresql 8.0.4
> opentaps 0.9.2 

As a regular reader of the pgsql-general@postgresql.org mailing list, it is 
quite evidient that very few of the people in that project approve of that 
version as usable in a production environment. There is a lot of discussion 
about the merits of going directly to 8.3.x when available vs. sticking with 
8.2.x for a while, but when anyone jumps in with a 8.0 problem it gets tossed 
back that the problem is fixed with a version from 8.1.X and higher.

There is a slew of performance and reliablity issues as well as automatic 
vacuuming with the 8.2 series that may make your upgrade well worth the effort.

If you need to stay with 8.0.X, I'd say you need to install the 8.0.12 version 
and make sure you have your manual vacuum proceedure properly configured.

FWIW, I seem to remember people quoting 30% or so peformance increase 8.0 -> 
8.3devel, which is a lot, if you are stress testing ofBiz.

--
Walter

Re: TR: ofbiz down

Posted by David E Jones <jo...@hotwaxmedia.com>.
Has anyone found any more details related to this? This popped up on one of our new client instances running on Postgres (a more recent version than this... 8.1.8), and then we were contacted by another previous client who is running on MySQL (not sure which version).

Andrew Zeneski added some log messages to try to help diagnose this, but we haven't yet found the problem. If we don't find it soon based on further tests we will probably add a UI to WebTools to help manually monitor the connection pool, and possibly do maintenance on it as well.

Anyway, I'm guessing a lot of people are seeing this, and mostly in systems that are either in production or in loaded testing over a long period of time (it usually takes at least a few hours to manifest in the stuff we are doing).

-David


Cléms wrote:
> Hi all,
> 
> Some news about our problem:
> During our load testing, everything works fine during something like 2 or 3
> days and then we get this exception:
> 
> 2007-05-04 06:50:51,193 (TP-Processor114) [  ConnectionFactory.java:95
> :ERROR] 
> ---- runtime exception report
> --------------------------------------------------
> There was an error getting a Minerva datasource.
> Exception: java.lang.RuntimeException
> Message: No ManagedConnections Available!
> ---- stack trace
> ---------------------------------------------------------------
> java.lang.RuntimeException: No ManagedConnections Available!
> org.ofbiz.minerva.pool.ObjectPool.getObject(ObjectPool.java:656)
> org.ofbiz.minerva.pool.jdbc.xa.XAPoolDataSource.getConnection(XAPoolDataSource.java:355)
> org.ofbiz.entity.transaction.MinervaConnectionFactory.getConnection(MinervaConnectionFactory.java:56)
> org.ofbiz.entity.jdbc.ConnectionFactory.tryGenericConnectionSources(ConnectionFactory.java:92)
> org.ofbiz.entity.transaction.JNDIFactory.getConnection(JNDIFactory.java:158)
> org.ofbiz.entity.transaction.TransactionFactory.getConnection(TransactionFactory.java:104)
> org.ofbiz.entity.jdbc.ConnectionFactory.getConnection(ConnectionFactory.java:82)
> org.ofbiz.entity.jdbc.SQLProcessor.getConnection(SQLProcessor.java:268)
> 
> 
> We got a lot of locking trouble as we analyse postgresql logs.
> Our configuration:
> Postgresql 8.0.4
> opentaps 0.9.2 
> 
> Regards
> 
> 
> Passalacqua Nicolas wrote:
>> Thanks guys for all the thinks.
>>
>> We will have a look on it, and make you a return as soon as we find
>> something.
>>
>> Regards,
>> Nick
>>
>> -----Message d'origine-----
>> De : Jonathon -- Improov [mailto:jonw@improov.com] 
>> Envoyé : samedi 21 avril 2007 07:20
>> À : user@ofbiz.apache.org
>> Objet : Re: TR: ofbiz down
>>
>> Chris,
>>
>> Yes, I think you're right, the autoReconnect has to do with the connector,
>> not the database per se.
>>
>> The "no database connection found for helpName "localmysql"" sounds like
>> Nicolas could have other 
>> things completely depleting the available connections (we're talking
>> outside the DBCP). So, I 
>> think you're right on that count too.
>>
>> The EOFException is certainly a problem with timed out MySQL connections,
>> nothing to do with 
>> something else completely depleting all available connections. Look at the
>> stack trace.
>>
>> Wait, lemme see my notes.
>>
>> Ok, here's how it happens, the whole trace. For simplicity, lets bundle
>> the XA* stuff under the 
>> name "DBCP".
>>
>> The DBCP gets a connection from its pool, unaware that the connection has
>> already timed out or is 
>> otherwise dead. Timing out isn't the only possible problem, and that's why
>> the DBCP should always 
>> check the connection before returning it to the application.
>>
>> Upon getting the connection from its pool, it "initializes" the connection
>> before returning it to 
>> the application. In this "initialization", one of the first things it does
>> is to set the 
>> transaction isolation level. How is that done? I'd say by an standard SQL
>> query.
>>
>> That's when the first SQL query is fired through that connection, and
>> that's when it fails.
>>
>> Failing the first time will get this same connection to autoReconnect.
>> Thereafter, for the next 8 
>> hours even without further activity, this connection will remain open and
>> valid.
>>
>> Nicolas can fix the issue about something depleting all available
>> connections (from RDBMS, not 
>> DBCP). Maybe catch this "other application" by looking at port
>> connections? However, he cannot fix 
>> the DBCP problem without going into the XAPoolDatasource source codes. If
>> no one else gets to this 
>> soon, I'm guessing I can (or HAVE TO) do it by... June?
>>
>> And yes, the MySQL stack trace definitely looks like how a typical RDBMS
>> operates. The J/Connector 
>> is trying to read stuff (IO) from the timed out database connection, like
>> "Server, do you copy?".
>>
>> Jonathon
>>
>> Chris Howe wrote:
>>> My understanding is that the deprecation of the autoReconnect is in the
>>> J/Connector, not the database (please note, i've never gotten under the
>>> hood of a database, or a jdbc, just used them).  I'm a bit puzzled by
>>> Nicolas's problem since it exists while using J/Connector 3.0.17 which
>>> autoReconnect was still supported.  This may be another connection
>>> related problem.  Perhaps he has multiple things hitting his MySql
>>> server (read not OFBiz) and not enough connections allocated.
>>>
>>> In addition, EOFException doesn't sound right for the error Nicolas is
>>> describing.  Jonathon, if you could verify that an EOFException is
>>> thrown when all connections are timed out on what you still have rigged
>>> up with MySql, it may be helpful for Nicolas.
>>>
>>>
>>>
>>>
>>> --- Jonathon -- Improov <jo...@improov.com> wrote:
>>>
>>>> This definitely has to do with the XAPoolDatasource. If you're using
>>>> MySQL, you've got bad news. 
>>>> Either fix XAPoolDatasource, or downgrade to MySQL 4.x.
>>>>
>>>> I'm using mysql-connector-java-5.0.4-bin.jar with no problems.
>>>>
>>>> Your problem is likely to do with timed out MySQL connections in the
>>>> Database Connection Pool 
>>>> (DBCP). The DBCP commonly used in OFBiz is the XAPoolDatasource. I
>>>> have yet to pull out the source 
>>>> codes for this DBCP to fix this problem.
>>>>
>>>> If you're interested in fixing this problem, you can grab the
>>>> XAPoolDatasource source codes from 
>>>> http://svn.ofbiz.org/viewcvs (David Jones said it's there).
>>>>
>>>> There's another post that said MySQL 5.0 is deprecating the
>>>> autoReconnect feature (if I read 
>>>> right). That would make things worse. With MySQL 4.x, OFBiz can try
>>>> to use a timed out connection, 
>>>> fail once, but won't fail the second time onwards because the
>>>> connection is autoReconnected. With 
>>>> MySQL 5.0, it seems you'll have to restart OFBiz!
>>>>
>>>> As for why MySQL 5.0 is deprecating the autoReconnect feature, or why
>>>> it's not doing away with its 
>>>> wait_timeout security(?) feature, you can probably find more
>>>> conclusively enlightening discussions 
>>>> on RDBMS forums.
>>>>
>>>> Here's what I wrote for a colleague, not comprehensive, but you
>>>> should get a rough idea:
>>>>
>>>> A database connection given out by a RDBMS (eg MySQL, MSSQL,
>>>> PostgreSQL) should always time out 
>>>> after a period of inactivity. That's just prudence. So far, all
>>>> decent enterprise-grade RDBMSes 
>>>> have that feature (MySQL, MSSQL).
>>>>
>>>> A Database Connection Pool (DBCP) is a tool that manages a pool of
>>>> pre-created database 
>>>> connections. It takes out a (configurable) number of connections and
>>>> keeps them in a pool, ready 
>>>> to dish them out to the application (eg OFBiz) on-demand. Benefit:
>>>> saves time, since taking out a 
>>>> connection from any RDBMS requires a substantial waiting period.
>>>>
>>>> The proper implementation for DBCP:
>>>>
>>>> 1. Get a connection from pool.
>>>>
>>>> 2. Check connection status.
>>>>
>>>>     (usually by sending it a query like 'SELECT 1', which will throw
>>>> up an error
>>>>     if the connection is bad).
>>>>
>>>> 3. If bad, drop it from the pool, get another one from the pool.
>>>>
>>>> 4. Repeat steps 2 and 3 until we get a good one.
>>>>
>>>> 5. Return good connection to application
>>>>
>>>>     (OFBiz's DBCP XAPoolDatasource currently throws a bad connection
>>>> back to
>>>>     application with a "choke on this" attitude.)
>>>>
>>>> 6. Check pool size, and replenish if necessary.
>>>>
>>>> Jonathon
>>>>
>>>> Passalacqua Nicolas wrote:
>>>>> Hi,
>>>>>
>>>>> I use the default one: mysql-connector-java-3.0.17-ga-bin.jar
>>>>>
>>>>> But everything works fine during something like 1 or 2 week, and
>>>> after a while I get this error.
>>>>> And then I need to restart ofbiz ....
>>>>>
>>>>> Regards.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : Chris Howe [mailto:cjhowe76013@yahoo.com] 
>>>>> Envoyé : jeudi 19 avril 2007 18:58
>>>>> À : user@ofbiz.apache.org
>>>>> Objet : Re: TR: ofbiz down
>>>>>
>>>>> ******* ERROR: No database connection found for helperName 
>>>>> "localmysql"
>>>>>
>>>>> Have you copied the correct mysql jdbc driver to
>>>>> ofbiz.home/framework/entity/lib/jdbc ???
>>>>>
>>>>>
>>>>> --- Passalacqua Nicolas <np...@prosodie.com> wrote:
>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : vijaywargiya.ashish@gmail.com
>>>>>> [mailto:vijaywargiya.ashish@gmail.com] De la part de Ashish
>>>>>> Vijaywargiya
>>>>>> Envoyé : jeudi 19 avril 2007 15:19
>>>>>> À : user@ofbiz.apache.org
>>>>>> Objet : Re: ofbiz down
>>>>>>
>>>>>>
>>>>>> Hi Nick,
>>>>>>
>>>>>> It might be much better if you will provide some more details.
>>>>>>
>>>>>> 1) Log Error. 
>>>>>> 	Please find them below....
>>>>>>
>>>>>> 2) Which revision of Ofbiz are you using ??
>>>>>> 	I currently use opentaps 0.9.2
>>>>>>
>>>>>> 3) Have you kept the postgres connector in
>>>> framework/entity/lib/jdbc
>>>>>> ??
>>>>>> 	I kept it. Actually the application run but after a few day I get
>>>>>> this 	error.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --- runtime exception report
>>>>>> --------------------------------------------------
>>>>>> There was an error getting a Minerva datasource.
>>>>>> Exception: java.lang.RuntimeException
>>>>>> Message: Unable to setTransactionIsolation: Communication link
>>>>>> failure: java.io.EOFException, underlying cause: null
>>>>>>
>>>>>> ** BEGIN NESTED EXCEPTION ** 
>>>>>>
>>>>>> java.io.EOFException
>>>>>>
>>>>>> STACKTRACE:
>>>>>>
>>>>>> java.io.EOFException
>>>>>> 	at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:1395)
>>>>>> 	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:1539)
>>>>>> 	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:1930)
>>>>>> 	at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1168)
>>>>>> 	at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1279)
>>>>>> 	at com.mysql.jdbc.MysqlIO.sqlQuery(MysqlIO.java:1225)
>>>>>> 	at com.mysql.jdbc.Connection.execSQL(Connection.java:2278)
>>>>>> 	at com.mysql.jdbc.Connection.execSQL(Connection.java:2237)
>>>>>> 	at com.mysql.jdbc.Connection.execSQL(Connection.java:2218)
>>>>>> 	at
>>>>>>
>>> com.mysql.jdbc.Connection.setTransactionIsolation(Connection.java:913)
>>>>>> 	at
>>>>>>
>>> org.ofbiz.minerva.pool.jdbc.xa.wrapper.XAConnectionImpl.setTransactionIsolation(XAConnectionImpl.java:117)
>>>>>> 	at
>>>>>>
>>> org.ofbiz.minerva.pool.jdbc.xa.XAConnectionFactory.prepareObject(XAConnectionFactory.java:412)
>>>>>> 	at
>>>> org.ofbiz.minerva.pool.ObjectPool.getObject(ObjectPool.java:645)
>>>>>> 	at
>>>>>>
>>> org.ofbiz.minerva.pool.jdbc.xa.XAPoolDataSource.getConnection(XAPoolDataSource.java:355)
>>>>>> 	at
>>>>>>
>>> org.ofbiz.entity.transaction.MinervaConnectionFactory.getConnection(MinervaConnectionFactory.java:56)
>>>>>> 	at
>>>>>>
>>> org.ofbiz.entity.jdbc.ConnectionFactory.tryGenericConnectionSources(ConnectionFactory.java:92)
>>>>>> 	at
>>>>>>
>>> org.ofbiz.entity.transaction.JNDIFactory.getConnection(JNDIFactory.java:158)
>>>>>> 	at
>>>>>>
>>> org.ofbiz.entity.transaction.TransactionFactory.getConnection(TransactionFactory.java:104)
>>>>>> 	at
>>>>>>
>>> org.ofbiz.entity.jdbc.ConnectionFactory.getConnection(ConnectionFactory.java:82)
>>>>>> 	at
>>>>>>
>>> org.ofbiz.entity.util.SequenceUtil$SequenceBank.fillBank(SequenceUtil.java:177)
>>>>>> 	at
>>>>>>
>>> org.ofbiz.entity.util.SequenceUtil$SequenceBank.<init>(SequenceUtil.java:120)
>>>>>> 	at
>>>>>>
>>>> org.ofbiz.entity.util.SequenceUtil.getNextSeqId(SequenceUtil.java:94)
>>>>>> 	at
>>> === message truncated ===
>>>
>>>
>>
>>
> 

RE: TR: ofbiz down

Posted by Cléms <cb...@prosodie.com>.
Hi all,

Some news about our problem:
During our load testing, everything works fine during something like 2 or 3
days and then we get this exception:

2007-05-04 06:50:51,193 (TP-Processor114) [  ConnectionFactory.java:95
:ERROR] 
---- runtime exception report
--------------------------------------------------
There was an error getting a Minerva datasource.
Exception: java.lang.RuntimeException
Message: No ManagedConnections Available!
---- stack trace
---------------------------------------------------------------
java.lang.RuntimeException: No ManagedConnections Available!
org.ofbiz.minerva.pool.ObjectPool.getObject(ObjectPool.java:656)
org.ofbiz.minerva.pool.jdbc.xa.XAPoolDataSource.getConnection(XAPoolDataSource.java:355)
org.ofbiz.entity.transaction.MinervaConnectionFactory.getConnection(MinervaConnectionFactory.java:56)
org.ofbiz.entity.jdbc.ConnectionFactory.tryGenericConnectionSources(ConnectionFactory.java:92)
org.ofbiz.entity.transaction.JNDIFactory.getConnection(JNDIFactory.java:158)
org.ofbiz.entity.transaction.TransactionFactory.getConnection(TransactionFactory.java:104)
org.ofbiz.entity.jdbc.ConnectionFactory.getConnection(ConnectionFactory.java:82)
org.ofbiz.entity.jdbc.SQLProcessor.getConnection(SQLProcessor.java:268)


We got a lot of locking trouble as we analyse postgresql logs.
Our configuration:
Postgresql 8.0.4
opentaps 0.9.2 

Regards


Passalacqua Nicolas wrote:
> 
> Thanks guys for all the thinks.
> 
> We will have a look on it, and make you a return as soon as we find
> something.
> 
> Regards,
> Nick
> 
> -----Message d'origine-----
> De : Jonathon -- Improov [mailto:jonw@improov.com] 
> Envoyé : samedi 21 avril 2007 07:20
> À : user@ofbiz.apache.org
> Objet : Re: TR: ofbiz down
> 
> Chris,
> 
> Yes, I think you're right, the autoReconnect has to do with the connector,
> not the database per se.
> 
> The "no database connection found for helpName "localmysql"" sounds like
> Nicolas could have other 
> things completely depleting the available connections (we're talking
> outside the DBCP). So, I 
> think you're right on that count too.
> 
> The EOFException is certainly a problem with timed out MySQL connections,
> nothing to do with 
> something else completely depleting all available connections. Look at the
> stack trace.
> 
> Wait, lemme see my notes.
> 
> Ok, here's how it happens, the whole trace. For simplicity, lets bundle
> the XA* stuff under the 
> name "DBCP".
> 
> The DBCP gets a connection from its pool, unaware that the connection has
> already timed out or is 
> otherwise dead. Timing out isn't the only possible problem, and that's why
> the DBCP should always 
> check the connection before returning it to the application.
> 
> Upon getting the connection from its pool, it "initializes" the connection
> before returning it to 
> the application. In this "initialization", one of the first things it does
> is to set the 
> transaction isolation level. How is that done? I'd say by an standard SQL
> query.
> 
> That's when the first SQL query is fired through that connection, and
> that's when it fails.
> 
> Failing the first time will get this same connection to autoReconnect.
> Thereafter, for the next 8 
> hours even without further activity, this connection will remain open and
> valid.
> 
> Nicolas can fix the issue about something depleting all available
> connections (from RDBMS, not 
> DBCP). Maybe catch this "other application" by looking at port
> connections? However, he cannot fix 
> the DBCP problem without going into the XAPoolDatasource source codes. If
> no one else gets to this 
> soon, I'm guessing I can (or HAVE TO) do it by... June?
> 
> And yes, the MySQL stack trace definitely looks like how a typical RDBMS
> operates. The J/Connector 
> is trying to read stuff (IO) from the timed out database connection, like
> "Server, do you copy?".
> 
> Jonathon
> 
> Chris Howe wrote:
>> My understanding is that the deprecation of the autoReconnect is in the
>> J/Connector, not the database (please note, i've never gotten under the
>> hood of a database, or a jdbc, just used them).  I'm a bit puzzled by
>> Nicolas's problem since it exists while using J/Connector 3.0.17 which
>> autoReconnect was still supported.  This may be another connection
>> related problem.  Perhaps he has multiple things hitting his MySql
>> server (read not OFBiz) and not enough connections allocated.
>> 
>> In addition, EOFException doesn't sound right for the error Nicolas is
>> describing.  Jonathon, if you could verify that an EOFException is
>> thrown when all connections are timed out on what you still have rigged
>> up with MySql, it may be helpful for Nicolas.
>> 
>> 
>> 
>> 
>> --- Jonathon -- Improov <jo...@improov.com> wrote:
>> 
>>> This definitely has to do with the XAPoolDatasource. If you're using
>>> MySQL, you've got bad news. 
>>> Either fix XAPoolDatasource, or downgrade to MySQL 4.x.
>>>
>>> I'm using mysql-connector-java-5.0.4-bin.jar with no problems.
>>>
>>> Your problem is likely to do with timed out MySQL connections in the
>>> Database Connection Pool 
>>> (DBCP). The DBCP commonly used in OFBiz is the XAPoolDatasource. I
>>> have yet to pull out the source 
>>> codes for this DBCP to fix this problem.
>>>
>>> If you're interested in fixing this problem, you can grab the
>>> XAPoolDatasource source codes from 
>>> http://svn.ofbiz.org/viewcvs (David Jones said it's there).
>>>
>>> There's another post that said MySQL 5.0 is deprecating the
>>> autoReconnect feature (if I read 
>>> right). That would make things worse. With MySQL 4.x, OFBiz can try
>>> to use a timed out connection, 
>>> fail once, but won't fail the second time onwards because the
>>> connection is autoReconnected. With 
>>> MySQL 5.0, it seems you'll have to restart OFBiz!
>>>
>>> As for why MySQL 5.0 is deprecating the autoReconnect feature, or why
>>> it's not doing away with its 
>>> wait_timeout security(?) feature, you can probably find more
>>> conclusively enlightening discussions 
>>> on RDBMS forums.
>>>
>>> Here's what I wrote for a colleague, not comprehensive, but you
>>> should get a rough idea:
>>>
>>> A database connection given out by a RDBMS (eg MySQL, MSSQL,
>>> PostgreSQL) should always time out 
>>> after a period of inactivity. That's just prudence. So far, all
>>> decent enterprise-grade RDBMSes 
>>> have that feature (MySQL, MSSQL).
>>>
>>> A Database Connection Pool (DBCP) is a tool that manages a pool of
>>> pre-created database 
>>> connections. It takes out a (configurable) number of connections and
>>> keeps them in a pool, ready 
>>> to dish them out to the application (eg OFBiz) on-demand. Benefit:
>>> saves time, since taking out a 
>>> connection from any RDBMS requires a substantial waiting period.
>>>
>>> The proper implementation for DBCP:
>>>
>>> 1. Get a connection from pool.
>>>
>>> 2. Check connection status.
>>>
>>>     (usually by sending it a query like 'SELECT 1', which will throw
>>> up an error
>>>     if the connection is bad).
>>>
>>> 3. If bad, drop it from the pool, get another one from the pool.
>>>
>>> 4. Repeat steps 2 and 3 until we get a good one.
>>>
>>> 5. Return good connection to application
>>>
>>>     (OFBiz's DBCP XAPoolDatasource currently throws a bad connection
>>> back to
>>>     application with a "choke on this" attitude.)
>>>
>>> 6. Check pool size, and replenish if necessary.
>>>
>>> Jonathon
>>>
>>> Passalacqua Nicolas wrote:
>>>> Hi,
>>>>
>>>> I use the default one: mysql-connector-java-3.0.17-ga-bin.jar
>>>>
>>>> But everything works fine during something like 1 or 2 week, and
>>> after a while I get this error.
>>>> And then I need to restart ofbiz ....
>>>>
>>>> Regards.
>>>>
>>>>
>>>>
>>>>
>>>> -----Message d'origine-----
>>>> De : Chris Howe [mailto:cjhowe76013@yahoo.com] 
>>>> Envoyé : jeudi 19 avril 2007 18:58
>>>> À : user@ofbiz.apache.org
>>>> Objet : Re: TR: ofbiz down
>>>>
>>>> ******* ERROR: No database connection found for helperName 
>>>> "localmysql"
>>>>
>>>> Have you copied the correct mysql jdbc driver to
>>>> ofbiz.home/framework/entity/lib/jdbc ???
>>>>
>>>>
>>>> --- Passalacqua Nicolas <np...@prosodie.com> wrote:
>>>>
>>>>> -----Message d'origine-----
>>>>> De : vijaywargiya.ashish@gmail.com
>>>>> [mailto:vijaywargiya.ashish@gmail.com] De la part de Ashish
>>>>> Vijaywargiya
>>>>> Envoyé : jeudi 19 avril 2007 15:19
>>>>> À : user@ofbiz.apache.org
>>>>> Objet : Re: ofbiz down
>>>>>
>>>>>
>>>>> Hi Nick,
>>>>>
>>>>> It might be much better if you will provide some more details.
>>>>>
>>>>> 1) Log Error. 
>>>>> 	Please find them below....
>>>>>
>>>>> 2) Which revision of Ofbiz are you using ??
>>>>> 	I currently use opentaps 0.9.2
>>>>>
>>>>> 3) Have you kept the postgres connector in
>>> framework/entity/lib/jdbc
>>>>> ??
>>>>> 	I kept it. Actually the application run but after a few day I get
>>>>> this 	error.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --- runtime exception report
>>>>> --------------------------------------------------
>>>>> There was an error getting a Minerva datasource.
>>>>> Exception: java.lang.RuntimeException
>>>>> Message: Unable to setTransactionIsolation: Communication link
>>>>> failure: java.io.EOFException, underlying cause: null
>>>>>
>>>>> ** BEGIN NESTED EXCEPTION ** 
>>>>>
>>>>> java.io.EOFException
>>>>>
>>>>> STACKTRACE:
>>>>>
>>>>> java.io.EOFException
>>>>> 	at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:1395)
>>>>> 	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:1539)
>>>>> 	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:1930)
>>>>> 	at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1168)
>>>>> 	at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1279)
>>>>> 	at com.mysql.jdbc.MysqlIO.sqlQuery(MysqlIO.java:1225)
>>>>> 	at com.mysql.jdbc.Connection.execSQL(Connection.java:2278)
>>>>> 	at com.mysql.jdbc.Connection.execSQL(Connection.java:2237)
>>>>> 	at com.mysql.jdbc.Connection.execSQL(Connection.java:2218)
>>>>> 	at
>>>>>
>> com.mysql.jdbc.Connection.setTransactionIsolation(Connection.java:913)
>>>>> 	at
>>>>>
>> org.ofbiz.minerva.pool.jdbc.xa.wrapper.XAConnectionImpl.setTransactionIsolation(XAConnectionImpl.java:117)
>>>>> 	at
>>>>>
>> org.ofbiz.minerva.pool.jdbc.xa.XAConnectionFactory.prepareObject(XAConnectionFactory.java:412)
>>>>> 	at
>>> org.ofbiz.minerva.pool.ObjectPool.getObject(ObjectPool.java:645)
>>>>> 	at
>>>>>
>> org.ofbiz.minerva.pool.jdbc.xa.XAPoolDataSource.getConnection(XAPoolDataSource.java:355)
>>>>> 	at
>>>>>
>> org.ofbiz.entity.transaction.MinervaConnectionFactory.getConnection(MinervaConnectionFactory.java:56)
>>>>> 	at
>>>>>
>> org.ofbiz.entity.jdbc.ConnectionFactory.tryGenericConnectionSources(ConnectionFactory.java:92)
>>>>> 	at
>>>>>
>> org.ofbiz.entity.transaction.JNDIFactory.getConnection(JNDIFactory.java:158)
>>>>> 	at
>>>>>
>> org.ofbiz.entity.transaction.TransactionFactory.getConnection(TransactionFactory.java:104)
>>>>> 	at
>>>>>
>> org.ofbiz.entity.jdbc.ConnectionFactory.getConnection(ConnectionFactory.java:82)
>>>>> 	at
>>>>>
>> org.ofbiz.entity.util.SequenceUtil$SequenceBank.fillBank(SequenceUtil.java:177)
>>>>> 	at
>>>>>
>> org.ofbiz.entity.util.SequenceUtil$SequenceBank.<init>(SequenceUtil.java:120)
>>>>> 	at
>>>>>
>>> org.ofbiz.entity.util.SequenceUtil.getNextSeqId(SequenceUtil.java:94)
>>>>> 	at
>> === message truncated ===
>> 
>> 
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/ofbiz-down-tf3607176.html#a10323758
Sent from the OFBiz - User mailing list archive at Nabble.com.