Google 網路論壇不再支援新的 Usenet 貼文或訂閱項目,但過往內容仍可供查看。

WebLogic6.1 with Interbase6.0 and CMP2.0

瀏覽次數:0 次
跳到第一則未讀訊息

Steffen Schenk

未讀,
2002年8月29日 清晨6:37:492002/8/29
收件者:

Hello,

we have some problems with our application including the container managed ejbs
under the weblogic6.1 and the interbase6.0.

Is there anyone who has had problems with the driver or the database in connection
with the weblogic server?

When monitoring the connection pools we see that some connections aren't closed
because they're permanently shown on the monitoring site under tab "Conections".
After half a day the maximum of the connection pool is reached and forced the
exception "no resources available".


In the weblogic.log we find the exceptions(before reaching the maximum) like:
java.lang.VerifyError: (class: interbase/interclient/ErrorKey, method: _$372 signature:
(Ljava/lang/String;Ljava/lang/String;I)V) Expecting to find unitialized object
on stack
at interbase.interclient.SQLException.<init>(SQLException.java:83)
at interbase.interclient.UnavailableInterBaseServerException.<init>(UnavailableInterBaseServerException.java:85)
at interbase.interclient.RecvMessage.createSQLException(RecvMessage.java:641)
at interbase.interclient.RecvMessage.makeSQLException(RecvMessage.java:593)
at interbase.interclient.RecvMessage.get_EXCEPTIONS(RecvMessage.java:554)
at interbase.interclient.Connection._$126173(Connection.java:391)
at interbase.interclient.Connection._$45044(Connection.java:331)
at interbase.interclient.Connection.<init>(Connection.java:285)
at interbase.interclient.Driver.connect(Driver.java:204)
at weblogic.jdbc.common.internal.ConnectionEnvFactory.makeConnection(ConnectionEnvFactory.java:191)
at weblogic.jdbc.common.internal.ConnectionEnvFactory.createResource(ConnectionEnvFactory.java:134)
at weblogic.common.internal.ResourceAllocator.makeResources(ResourceAllocator.java:698)
at weblogic.common.internal.ResourceAllocator.reserve(ResourceAllocator.java:511)
at weblogic.common.internal.ResourceAllocator.reserve(ResourceAllocator.java:400)
at weblogic.common.internal.ResourceAllocator.reserveNoWait(ResourceAllocator.java:368)
at weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:166)
at weblogic.jdbc.common.internal.ConnectionPool.reserveNoWait(ConnectionPool.java:127)
at weblogic.jdbc.common.internal.RmiDataSource.getPoolConnection(RmiDataSource.java:194)
at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:219)
at weblogic.ejb20.cmp.rdbms.RDBMSPersistenceManager.getConnection(RDBMSPersistenceManager.java:313)
at de.fiatbank.workflow.beans.workflow_User_ivcygb__WebLogic_CMP_RDBMS.__WL_store(workflow_User_ivcygb__WebLogic_CMP_RDBMS.java:4175)


Has anyone an idea?


Thanks for help
Steffen


Joseph Weinstein

未讀,
2002年8月29日 下午1:25:352002/8/29
收件者:Steffen Schenk
Hi. That stacktrace looks like the JVM is corrupted. If all the beans are
CMP then all the connections they use will be automatically closed and
put back into the pool. One thing you can do to stabilize the situation
may be to make the pool create all the connections it will need at
startup so you never have to make one at runtime.
Joe

Joseph Weinstein

未讀,
2002年9月3日 下午1:57:202002/9/3
收件者:Steffen Schenk
Steffen Schenk wrote:

> Hello,
> thanks for your help Joe.
> We set the initial capacity to a higher value and now the system runs stable.

good to hear!

> But there are some failures in Bea Weblogic JDBC Area.
> Here an answer from another bea consultant:

Ok. I agree that refresh should be turned off by specifying refresh minutes
as 99999999 or something like that. I do recommend init=max
Joe

>
>
> > Hallo Herr Eiermann,
> >
> >
> > wie am Telefon besprochen schicke ich Ihnen ein paar Anregungen,
> > wie Sie bei der Suche nach den verlorenen Connections weiter vorgehen
> > koennen:
> >
> > 1) Bedeutung der einzelnen Felder beim Monitoring der Connections:
> > Connections High: groesste Anzahl der von connections, die jemals
> > erreicht wurde
> > Connections Total: Zaehler, wie of eine Connections angefordert
> > wurde
> > Connections: Aktuelle Anzhal der Connections
> >
> > Zur von Ihnen beobachteten Anomalie der Connections High habe ich
> > einen Change
> > Request (CR) gefunden, der dieses Verhalten korrigiert:
> > CR060062 WLS 6.1sp1 - 'Connections High' in connection pool
> > monitoring
> > screen incorrectly
> > includes the connections refreshed by WLS
> >
> > Wie ist Ihre aktuelle Einstellung des Connection Refresh? Meine
> > Empfehlung:
> > - wenn die Verbindungen gut sind, ein moeglichst langes Intervall
> > nehmen, oder
> > ueberhaupt disablen.
> > - Kein shrinking verwenden, wenn es nicht unbedingt sein muss
> > - Initialeinstellung InitialCapacity=MaxCapacity
> >
> > 2) weiters habe ich folgenden CR gefunden:
> > CR072179 Difference in behavior for jdbc connections taken from pool
> > driver or
> > DataSource when not closed
> >
> > Fuer diesen CR existiert ein Patch auf Basis on WLS6.1SP2. Diesen
> > Patch habe ich
> > ich Ihnen an diese Mail angehaengt. Bei Verwendung dieses Patch wird
> > die Connection,
> > wenn es sich um eine Instanz von weblogic.jdbc.rmi.SerialConnection
> > handelt bei der
> > Garbage Collection geschlossen und damit an den Pool zurückgegeben.
> >
> > Dieser Fix wird auch in der Version WLS7.0SP1 enthalten sein.
> >
> > Mein Vorschlag lautet nun auf WLS6.1SP2 mit dem Patch oben angegebenen
> > Patch zu
> > gehen. Plazieren Sie den gelieferten jar file vor weblogic_sp.jar und
> > weblogic.jar in Ihrem
> > CLASSPATH.
>
> ----------------------------------------------------------------------------------------------------
> Name: CR072179_610sp2.jar.zip
> CR072179_610sp2.jar.zip Type: Zip Compressed Data (application/x-zip-compressed)
> Encoding: base64

0 則新訊息