Re: Connection leak problem with OJB RC3 on Weblogic 7.0 SP2
Hi,
there is no difference in intern handling between
PersistenceBroker broker =
PersistenceBrokerFactory.defaultPersistenceBroker();
and
PersistenceBroker broker =
PersistenceBrokerFactory.createPersistenceBroker(PBKey key)
First method is a convenience method for the second one. If
attribute default-connection=true set in jdbc-connection-descriptor
(with valid user/password) OJB build an intern PBKey used to
fulfil first method call.
Second method is recommended when:
- using more than on database/database user
- you don't want to declare user/passwd in repository file
If you only user one database and don't have a problem to declare
user/passwd in repository file, then there is no reason to use
convenience method.
:) OJB turorial is not a best source for real applications .
Currently Brain McCallister is refactoring the tuturial stuff to
make things clearer.
regards,
Armin
- Original Message -
From: Gustafson, Scott F. [EMAIL PROTECTED]
To: OJB Users List [EMAIL PROTECTED]
Sent: Wednesday, August 13, 2003 2:25 PM
Subject: RE: Connection leak problem with OJB RC3 on Weblogic 7.0 SP2
Beware of:
PersistenceBroker broker =
PersistenceBrokerFactory.defaultPersistenceBroker();
I ran into some threading issues when using it, after I switched to:
PersistenceBroker broker =
PersistenceBrokerFactory.createPersistenceBroker(PBKey key)
These problems went away, see an earlier thread Threadsafety of the
PersistenceBroker default impl
sg
-Original Message-
From: Alexander Prozor [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 13, 2003 8:15 AM
To: OJB Users List
Subject: Re: Connection leak problem with OJB RC3 on Weblogic 7.0
SP2
:) OJB turorial is not a best source for real applications .
it's better to take a look to the unit tests code. as you can
see in all tests broker closed:
PersistenceBroker broker =
PersistenceBrokerFactory.defaultPersistenceBroker();
try
{
}
finally
{
if (broker != null) broker.close();
}
Nope, actually I don't call the broker.close() method. Is it
necessary?
The example code didn't do that either and the JavaDoc says
about the
close()
method:
Close this PersistenceBroker so that no further requests
may be made on it.
A PersistenceBroker instance can be used only until it is
closed. Closing a
PersistenceBroker might release it to the pool of available
PersistenceBrokers, or might be garbage collected, at the
option of the
implementation.
So it might release the broker instance to the pool, not the
connection. Or
does it automatically closes the underlying Connection object?
I'll give a try anyway.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Connection leak problem with OJB RC3 on Weblogic 7.0 SP2
Nope, actually I don't call the broker.close() method. Is it necessary? The example code didn't do that either and the JavaDoc says about the close() method: Close this PersistenceBroker so that no further requests may be made on it. A PersistenceBroker instance can be used only until it is closed. Closing a PersistenceBroker might release it to the pool of available PersistenceBrokers, or might be garbage collected, at the option of the implementation. So it might release the broker instance to the pool, not the connection. Or does it automatically closes the underlying Connection object? I'll give a try anyway. -Original Message- From: Alexander Prozor [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 13, 2003 1:49 PM To: OJB Users List Subject: Re: Connection leak problem with OJB RC3 on Weblogic 7.0 SP2 Do you call broker.clcse() method after storing/retriaving operations? Hi, I have got a problem with using OJB RC3 on Weblogic 7.0 SP2. In the Weblogic there's a connection pool and datasource set up. The OJB is connecting to the database via this JNDI Datasource. No matter which ConnectionFactoryClass I set in the OJB.properties, I always get a connection leak error. Is it possible that the OJB doesn't close the connection when it is not used anymore? I'd appreciate your help. Thanks Peter Bona the exception: Aug 13, 2003 10:37:36 AM CEST Warning JDBC server-a Finalizer kernel identity 001074 A JDBC pool connect ion leak was detected. A Connection leak occurs when a connection obtained from the pool was not closed explicitly by calling close() and then was disposed by t he garbage collector and returned to the connection pool. The following stack tr ace at create shows where the leaked connection was created. Stack trace at con nection create: at weblogic.jdbc.pool.Connection.init(Connection.java:62) at weblogic.jdbc.common.internal.RmiDataSource.getPoolConnectionObj(RmiD ataSource.java:284) at weblogic.jdbc.common.internal.RmiDataSource.getPoolConnection(RmiData Source.java:252) at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSour ce.java:270) at org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.newCo nnectionFromDataSource(Unknown Source) at org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.looku pConnection(Unknown Source) at org.apache.ojb.broker.accesslayer.ConnectionFactoryManagedImpl.lookup Connection(Unknown Source) at org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.getConnection at org.apache.ojb.broker.accesslayer.StatementManager.getPreparedStateme nt(Unknown Source) at org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeQuery(Unknown Source) at org.apache.ojb.broker.accesslayer.RsIterator.init(Unknown Source) at org.apache.ojb.broker.core.RsIteratorFactoryImpl.createRsIterator(Unk nown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getRsIteratorFromQue ry(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getIteratorFromQuery (Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery (Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery (Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery (Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery (Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionB yQuery(Unknown Source) The corresponding OJB.properties (part of it): #-- - - # ConnectionFactory / Default ConnectionPool #-- - - # The ConnectionFactoryClass entry determines which kind of ConnectionFactory # is to be used within org.apache.ojb as connection factory. # A ConnectionFactory is responsible for creating # JDBC Connections. Current version ships four implementations: # # 1. ConnectionFactoryNotPooledImpl #No pooling, no playing around. #Every connection request returns a new connection, #every connection release close the connection. # 2. ConnectionFactoryPooledImpl #This implementation supports connection pooling. # 3. ConnectionFactoryDBCPImpl #Using the jakarta-DBCP api for connection management, support #connection- and prepared statement-pooling, abandoned connection handling. # 4. ConnectionFactoryManagedImpl #Connection factory for use within managed environments - e.g. JBoss. #Every obtained DataSource was wrapped within OJB (and ignore #e.g. con.commit() calls within OJB). #Use this implementation e.g if you use Datasources from an application server. # # Use the OJB performance tests to decide, which implementation
RE: Connection leak problem with OJB RC3 on Weblogic 7.0 SP2
Beware of:
PersistenceBroker broker =
PersistenceBrokerFactory.defaultPersistenceBroker();
I ran into some threading issues when using it, after I switched to:
PersistenceBroker broker =
PersistenceBrokerFactory.createPersistenceBroker(PBKey key)
These problems went away, see an earlier thread Threadsafety of the
PersistenceBroker default impl
sg
-Original Message-
From: Alexander Prozor [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 13, 2003 8:15 AM
To: OJB Users List
Subject: Re: Connection leak problem with OJB RC3 on Weblogic 7.0 SP2
:) OJB turorial is not a best source for real applications .
it's better to take a look to the unit tests code. as you can
see in all tests broker closed:
PersistenceBroker broker =
PersistenceBrokerFactory.defaultPersistenceBroker();
try
{
}
finally
{
if (broker != null) broker.close();
}
Nope, actually I don't call the broker.close() method. Is it
necessary?
The example code didn't do that either and the JavaDoc says
about the
close()
method:
Close this PersistenceBroker so that no further requests
may be made on it.
A PersistenceBroker instance can be used only until it is
closed. Closing a
PersistenceBroker might release it to the pool of available
PersistenceBrokers, or might be garbage collected, at the
option of the
implementation.
So it might release the broker instance to the pool, not the
connection. Or
does it automatically closes the underlying Connection object?
I'll give a try anyway.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Connection leak problem with OJB RC3 on Weblogic 7.0 SP2
Hi, I have got a problem with using OJB RC3 on Weblogic 7.0 SP2. In the Weblogic there's a connection pool and datasource set up. The OJB is connecting to the database via this JNDI Datasource. No matter which ConnectionFactoryClass I set in the OJB.properties, I always get a connection leak error. Is it possible that the OJB doesn't close the connection when it is not used anymore? I'd appreciate your help. Thanks Peter Bona the exception: Aug 13, 2003 10:37:36 AM CEST Warning JDBC server-a Finalizer kernel identity 001074 A JDBC pool connect ion leak was detected. A Connection leak occurs when a connection obtained from the pool was not closed explicitly by calling close() and then was disposed by t he garbage collector and returned to the connection pool. The following stack tr ace at create shows where the leaked connection was created. Stack trace at con nection create: at weblogic.jdbc.pool.Connection.init(Connection.java:62) at weblogic.jdbc.common.internal.RmiDataSource.getPoolConnectionObj(RmiD ataSource.java:284) at weblogic.jdbc.common.internal.RmiDataSource.getPoolConnection(RmiData Source.java:252) at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSour ce.java:270) at org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.newCo nnectionFromDataSource(Unknown Source) at org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.looku pConnection(Unknown Source) at org.apache.ojb.broker.accesslayer.ConnectionFactoryManagedImpl.lookup Connection(Unknown Source) at org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.getConnection at org.apache.ojb.broker.accesslayer.StatementManager.getPreparedStateme nt(Unknown Source) at org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeQuery(Unknown Source) at org.apache.ojb.broker.accesslayer.RsIterator.init(Unknown Source) at org.apache.ojb.broker.core.RsIteratorFactoryImpl.createRsIterator(Unk nown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getRsIteratorFromQue ry(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getIteratorFromQuery (Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery (Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery (Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery (Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery (Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionB yQuery(Unknown Source) The corresponding OJB.properties (part of it): #--- - # ConnectionFactory / Default ConnectionPool #--- - # The ConnectionFactoryClass entry determines which kind of ConnectionFactory # is to be used within org.apache.ojb as connection factory. # A ConnectionFactory is responsible for creating # JDBC Connections. Current version ships four implementations: # # 1. ConnectionFactoryNotPooledImpl #No pooling, no playing around. #Every connection request returns a new connection, #every connection release close the connection. # 2. ConnectionFactoryPooledImpl #This implementation supports connection pooling. # 3. ConnectionFactoryDBCPImpl #Using the jakarta-DBCP api for connection management, support #connection- and prepared statement-pooling, abandoned connection handling. # 4. ConnectionFactoryManagedImpl #Connection factory for use within managed environments - e.g. JBoss. #Every obtained DataSource was wrapped within OJB (and ignore #e.g. con.commit() calls within OJB). #Use this implementation e.g if you use Datasources from an application server. # # Use the OJB performance tests to decide, which implementation is best for you. # The proper way of obtaining a connection is configured in # JDBCConnectionDescriptor entries in the repository.xml file. # If want a more fine grained control of each connection pool used by OJB, # take a look at the repository.dtd, there was a possibility to override # this default connection factory entry in each JDBCConnectionDescriptor. # #ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryP ooledImpl #ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryN otPooledImpl ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryMa nagedImpl #ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryD BCPImpl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Connection leak problem with OJB RC3 on Weblogic 7.0 SP2
ups, typos
- Original Message -
From: Armin Waibel [EMAIL PROTECTED]
To: OJB Users List [EMAIL PROTECTED]
Sent: Wednesday, August 13, 2003 2:51 PM
Subject: Re: Connection leak problem with OJB RC3 on Weblogic 7.0 SP2
Hi,
there is no difference in intern handling between
PersistenceBroker broker =
PersistenceBrokerFactory.defaultPersistenceBroker();
and
PersistenceBroker broker =
PersistenceBrokerFactory.createPersistenceBroker(PBKey key)
First method is a convenience method for the second one. If
attribute default-connection=true set in jdbc-connection-descriptor
(with valid user/password) OJB build an intern PBKey used to
fulfil first method call.
Second method is recommended when:
- using more than on database/database user
- you don't want to declare user/passwd in repository file
###
If you only use one database and don't have a problem to declare
user/passwd in repository file, then there is no reason not to use
convenience method.
### (does this make things clearer? ;-))
:) OJB turorial is not a best source for real applications .
Currently Brain McCallister is refactoring the tuturial stuff to
make things clearer.
regards,
Armin
- Original Message -
From: Gustafson, Scott F. [EMAIL PROTECTED]
To: OJB Users List [EMAIL PROTECTED]
Sent: Wednesday, August 13, 2003 2:25 PM
Subject: RE: Connection leak problem with OJB RC3 on Weblogic 7.0 SP2
Beware of:
PersistenceBroker broker =
PersistenceBrokerFactory.defaultPersistenceBroker();
I ran into some threading issues when using it, after I switched to:
PersistenceBroker broker =
PersistenceBrokerFactory.createPersistenceBroker(PBKey key)
These problems went away, see an earlier thread Threadsafety of the
PersistenceBroker default impl
sg
-Original Message-
From: Alexander Prozor [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 13, 2003 8:15 AM
To: OJB Users List
Subject: Re: Connection leak problem with OJB RC3 on Weblogic 7.0
SP2
:) OJB turorial is not a best source for real applications .
it's better to take a look to the unit tests code. as you can
see in all tests broker closed:
PersistenceBroker broker =
PersistenceBrokerFactory.defaultPersistenceBroker();
try
{
}
finally
{
if (broker != null) broker.close();
}
Nope, actually I don't call the broker.close() method. Is it
necessary?
The example code didn't do that either and the JavaDoc says
about the
close()
method:
Close this PersistenceBroker so that no further requests
may be made on it.
A PersistenceBroker instance can be used only until it is
closed. Closing a
PersistenceBroker might release it to the pool of available
PersistenceBrokers, or might be garbage collected, at the
option of the
implementation.
So it might release the broker instance to the pool, not the
connection. Or
does it automatically closes the underlying Connection object?
I'll give a try anyway.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Connection leak problem with OJB RC3 on Weblogic 7.0 SP2
Do you call broker.clcse() method after storing/retriaving operations? Hi, I have got a problem with using OJB RC3 on Weblogic 7.0 SP2. In the Weblogic there's a connection pool and datasource set up. The OJB is connecting to the database via this JNDI Datasource. No matter which ConnectionFactoryClass I set in the OJB.properties, I always get a connection leak error. Is it possible that the OJB doesn't close the connection when it is not used anymore? I'd appreciate your help. Thanks Peter Bona the exception: Aug 13, 2003 10:37:36 AM CEST Warning JDBC server-a Finalizer kernel identity 001074 A JDBC pool connect ion leak was detected. A Connection leak occurs when a connection obtained from the pool was not closed explicitly by calling close() and then was disposed by t he garbage collector and returned to the connection pool. The following stack tr ace at create shows where the leaked connection was created. Stack trace at con nection create: at weblogic.jdbc.pool.Connection.init(Connection.java:62) at weblogic.jdbc.common.internal.RmiDataSource.getPoolConnectionObj(RmiD ataSource.java:284) at weblogic.jdbc.common.internal.RmiDataSource.getPoolConnection(RmiData Source.java:252) at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSour ce.java:270) at org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.newCo nnectionFromDataSource(Unknown Source) at org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.looku pConnection(Unknown Source) at org.apache.ojb.broker.accesslayer.ConnectionFactoryManagedImpl.lookup Connection(Unknown Source) at org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.getConnection at org.apache.ojb.broker.accesslayer.StatementManager.getPreparedStateme nt(Unknown Source) at org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeQuery(Unknown Source) at org.apache.ojb.broker.accesslayer.RsIterator.init(Unknown Source) at org.apache.ojb.broker.core.RsIteratorFactoryImpl.createRsIterator(Unk nown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getRsIteratorFromQue ry(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getIteratorFromQuery (Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery (Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery (Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery (Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery (Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionB yQuery(Unknown Source) The corresponding OJB.properties (part of it): #--- - # ConnectionFactory / Default ConnectionPool #--- - # The ConnectionFactoryClass entry determines which kind of ConnectionFactory # is to be used within org.apache.ojb as connection factory. # A ConnectionFactory is responsible for creating # JDBC Connections. Current version ships four implementations: # # 1. ConnectionFactoryNotPooledImpl #No pooling, no playing around. #Every connection request returns a new connection, #every connection release close the connection. # 2. ConnectionFactoryPooledImpl #This implementation supports connection pooling. # 3. ConnectionFactoryDBCPImpl #Using the jakarta-DBCP api for connection management, support #connection- and prepared statement-pooling, abandoned connection handling. # 4. ConnectionFactoryManagedImpl #Connection factory for use within managed environments - e.g. JBoss. #Every obtained DataSource was wrapped within OJB (and ignore #e.g. con.commit() calls within OJB). #Use this implementation e.g if you use Datasources from an application server. # # Use the OJB performance tests to decide, which implementation is best for you. # The proper way of obtaining a connection is configured in # JDBCConnectionDescriptor entries in the repository.xml file. # If want a more fine grained control of each connection pool used by OJB, # take a look at the repository.dtd, there was a possibility to override # this default connection factory entry in each JDBCConnectionDescriptor. # #ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryP ooledImpl #ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryN otPooledImpl ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryMa nagedImpl #ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryD BCPImpl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
RE: Connection leak problem with OJB RC3 on Weblogic 7.0 SP2
Thanks Alexander, it seems that was indeed the problem.
-Original Message-
From: Alexander Prozor [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 13, 2003 2:15 PM
To: OJB Users List
Subject: Re: Connection leak problem with OJB RC3 on Weblogic 7.0 SP2
:) OJB turorial is not a best source for real applications .
it's better to take a look to the unit tests code.
as you can see in all tests broker closed:
PersistenceBroker broker =
PersistenceBrokerFactory.defaultPersistenceBroker();
try
{
}
finally
{
if (broker != null) broker.close();
}
Nope, actually I don't call the broker.close() method. Is it necessary? The
example code didn't do that either and the JavaDoc says about the close()
method:
Close this PersistenceBroker so that no further requests may be made on
it.
A PersistenceBroker instance can be used only until it is closed. Closing a
PersistenceBroker might release it to the pool of available
PersistenceBrokers, or might be garbage collected, at the option of the
implementation.
So it might release the broker instance to the pool, not the connection. Or
does it automatically closes the underlying Connection object?
I'll give a try anyway.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Connection leak problem with OJB RC3 on Weblogic 7.0 SP2
:) OJB turorial is not a best source for real applications .
it's better to take a look to the unit tests code.
as you can see in all tests broker closed:
PersistenceBroker broker =
PersistenceBrokerFactory.defaultPersistenceBroker();
try
{
}
finally
{
if (broker != null) broker.close();
}
Nope, actually I don't call the broker.close() method. Is it necessary? The
example code didn't do that either and the JavaDoc says about the close()
method:
Close this PersistenceBroker so that no further requests may be made on it.
A PersistenceBroker instance can be used only until it is closed. Closing a
PersistenceBroker might release it to the pool of available
PersistenceBrokers, or might be garbage collected, at the option of the
implementation.
So it might release the broker instance to the pool, not the connection. Or
does it automatically closes the underlying Connection object?
I'll give a try anyway.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Connection leak problem with OJB RC3 on Weblogic 7.0 SP2
When will we see some *real* documentation? I've got a pretty big application that's being planned out now that will (hopefully) use OJB, and some real-world documentation would be nice :) -Clay Armin Waibel wrote: :) OJB turorial is not a best source for real applications . Currently Brain McCallister is refactoring the tuturial stuff to make things clearer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
