[jira] [Updated] (MATH-473) Frequency: new option: NON-sorted
[ https://issues.apache.org/jira/browse/MATH-473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-473: - Assignee: (was: Phil Steitz) Frequency: new option: NON-sorted - Key: MATH-473 URL: https://issues.apache.org/jira/browse/MATH-473 Project: Commons Math Issue Type: Improvement Affects Versions: 1.0, 1.1, 1.2, 2.0, 2.1 Reporter: Dan Checkoway Fix For: 3.0 Attachments: MATH-473.patch I have a request for enhancement on org.apache.commons.math.stat.Frequency. I would like to be able to specify that the the backing map NOT be sorted. Right now it uses TreeMap. I would like to have the option of specifying that sorting is not important, and would in fact hinder performance, and a plain old HashMap should be used instead. i.e. constructor such as: public Frequency(boolean sorted); If sorted is true, use a TreeMap. If sorted is false, use a HashMap. Is this feasible? I'd be happy to contribute a patch if that would help. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-575) Exceptions in genetics package or not consistent with the rest of [math]
[ https://issues.apache.org/jira/browse/MATH-575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-575: - Assignee: (was: Phil Steitz) Exceptions in genetics package or not consistent with the rest of [math] Key: MATH-575 URL: https://issues.apache.org/jira/browse/MATH-575 Project: Commons Math Issue Type: Bug Affects Versions: 2.0, 2.1, 2.2 Reporter: Phil Steitz Priority: Minor Fix For: 3.0 InvalidRepresentationException is checked and non-localized. This exception should be placed in the [math] hierarchy. The AbstractListChromosome constructor also throws a non-localised IAE, which should be replaced by an appropriate [math] exception. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-474) Frequency: new method: merge(Frequency)
[ https://issues.apache.org/jira/browse/MATH-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-474: - Assignee: (was: Phil Steitz) Frequency: new method: merge(Frequency) --- Key: MATH-474 URL: https://issues.apache.org/jira/browse/MATH-474 Project: Commons Math Issue Type: Improvement Reporter: Dan Checkoway Fix For: 3.0 Attachments: MATH-474.patch I'd like to propose an enhancement to org.apache.commons.math.stat.Frequency. I need to merge multiple Frequency objects, and it would be great if Frequency had inherent support for this, such as: public void merge(Frequency other); public void merge(CollectionFrequency others); I'd be happy to submit a patch if that would help... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-588) Weighted Mean evaluation may not have optimal numerics
[
https://issues.apache.org/jira/browse/MATH-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz updated MATH-588:
-
Assignee: (was: Phil Steitz)
Weighted Mean evaluation may not have optimal numerics
--
Key: MATH-588
URL: https://issues.apache.org/jira/browse/MATH-588
Project: Commons Math
Issue Type: Bug
Affects Versions: 2.1, 2.2
Reporter: Phil Steitz
Fix For: 3.0
I recently got this in a test run
{code}
testWeightedConsistency(org.apache.commons.math.stat.descriptive.moment.MeanTest)
Time elapsed: 0 sec FAILURE!
java.lang.AssertionError: expected:0.002282165958997601 but
was:0.002282165958997157
at org.junit.Assert.fail(Assert.java:91)
at org.junit.Assert.failNotEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:441)
at
org.apache.commons.math.TestUtils.assertRelativelyEquals(TestUtils.java:178)
at
org.apache.commons.math.TestUtils.assertRelativelyEquals(TestUtils.java:153)
at
org.apache.commons.math.stat.descriptive.UnivariateStatisticAbstractTest.testWeightedConsistency(UnivariateStatisticAbstractTest.java:170)
{code}
The correction formula used to compute the unweighted mean may not be
appropriate or optimal in the presence of weights:
{code}
// Compute initial estimate using definitional formula
double sumw = sum.evaluate(weights,begin,length);
double xbarw = sum.evaluate(values, weights, begin, length) / sumw;
// Compute correction factor in second pass
double correction = 0;
for (int i = begin; i begin + length; i++) {
correction += weights[i] * (values[i] - xbarw);
}
return xbarw + (correction/sumw);
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBCP-372) Statement Leak occurs when batch update is used.
[ https://issues.apache.org/jira/browse/DBCP-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated DBCP-372: - Fix Version/s: 1.4.1 Statement Leak occurs when batch update is used. Key: DBCP-372 URL: https://issues.apache.org/jira/browse/DBCP-372 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.3, 1.4 Environment: Oracle 11g Reporter: Naozumi Taromaru Priority: Critical Fix For: 1.4.1 org.apache.commons.dbcp.PoolablePreparedStatement#passivate() execute clearBatch(). (DBCP-264) But this clearBatch() throw SQLException. (DelegatingStatement#checkOpen() throw SQLException, because _closed is true.) The result, the PoolablePreparedStatement doesn't return to pool, and the PoolablePreparedStatement doesn't execute PreparedStatement#close(). When a lot of data is processed, in the case of Oracle * ORA-00604 * ORA-01000 occurs. Proposal: clearBatch(); in passivate() method changes as follows. batchAdded = false; getInnermostDelegate().clearBatch(); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBCP-368) determine which connections to hold in pool by relative value
[ https://issues.apache.org/jira/browse/DBCP-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated DBCP-368: - Fix Version/s: 2.0 determine which connections to hold in pool by relative value - Key: DBCP-368 URL: https://issues.apache.org/jira/browse/DBCP-368 Project: Commons Dbcp Issue Type: New Feature Reporter: Philip Williams Fix For: 2.0 Situation: a Firebird-Classic database (each connection has independent metadata cache), in a metadata-heavy environment; many quick actions will never force the database server to load full metadata, but a few will, in our case resulting in 200MB of metadata cache in memory (takes about 3 seconds to load, visible latency to the user); any connection that has done this is more valuable to us, and we'd prefer to keep those connections in the pool, and remove idle connections which haven't incurred this cost yet and are relatively cheap to recreate later if our load increases. Doing this is preferable to forcing ALL connections to load metadata at start, as this means the pool will always have a startup cost (in time), and the server will likely use more memory than really necessary. Proposal: add new configuration parameter; if set, run the SQL string and get back a single-column, single-row result-set containing an arbitrary value as determined by the connection; prefer to close the lowest(?)-value connections first, to get down to the configured minIdle. Would require querying each open connection, when the pool is over-full, to determine which ones are most valuable. If not set, use current algorithm (based on age?). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBCP-361) BasicManagedDataSource optional transaction enlistment
[ https://issues.apache.org/jira/browse/DBCP-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated DBCP-361: - Fix Version/s: 2.0 BasicManagedDataSource optional transaction enlistment -- Key: DBCP-361 URL: https://issues.apache.org/jira/browse/DBCP-361 Project: Commons Dbcp Issue Type: New Feature Reporter: Aaron Hamid Fix For: 2.0 It would be nice to not automatically enlist connections in a transaction. I have found automatic enlistment can be problematic when using another transaction API such as Spring's declarative transactions (JtaTransactionManager). It appears Spring may create a second, wrapping transaction. With Oracle this leads to: ORA-02089: COMMIT is not allowed in a subordinate session. E.g. see Bitronix setAutomaticEnlistingEnabled http://btm.codehaus.org/api/1.3.3/bitronix/tm/resource/common/ResourceBean.html#setAutomaticEnlistingEnabled(boolean) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBCP-369) Exception when using SharedPoolDataSource concurrently
[
https://issues.apache.org/jira/browse/DBCP-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz updated DBCP-369:
-
Fix Version/s: 1.4.1
Exception when using SharedPoolDataSource concurrently
--
Key: DBCP-369
URL: https://issues.apache.org/jira/browse/DBCP-369
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 1.4
Environment: Java Hotspot Server VM 1.6.0_07, Linux
Reporter: Michael Pradel
Fix For: 1.4.1
Hi,
I get a ConcurrentModificationException when using instances of
SharedPoolDataSource concurrently. The problem occurs when one thread calls
setDataSourceName() while another thread calls close(), either on the same
instance of SharedPoolDataSource or on different instances. I'll attach a
short example program that leads to an exception for almost every run on my
machine.
The cause of the exception seems to be in InstanceKeyObjectFactory.
registerNewInstance() is synchronized, but removeInstance() isn't. This
allows concurrent accesses to the non-thread-safe 'instanceMap'.
Is this a bug? Or are SharedPoolDataSource and InstanceKeyObjectFactory not
supposed to be thread-safe?
Thanks!
import java.util.ArrayList;
import org.apache.commons.dbcp.datasources.SharedPoolDataSource;
public class SharedPoolDataSourceTest {
public static void main(String[] args) {
new SharedPoolDataSourceTest().run();
}
private void run() {
final ArrayListSharedPoolDataSource dataSources = new
ArrayListSharedPoolDataSource();
for (int j = 0; j 1; j++) {
SharedPoolDataSource dataSource = new
SharedPoolDataSource();
dataSources.add(dataSource);
}
Thread t1 = new Thread(new Runnable() {
public void run() {
for (SharedPoolDataSource dataSource :
dataSources) {
dataSource.setDataSourceName(a);
}
}
});
Thread t2 = new Thread(new Runnable() {
public void run() {
for (SharedPoolDataSource dataSource :
dataSources) {
try { dataSource.close(); } catch
(Exception e) {}
}
}
});
t1.start();
t2.start();
try {
t1.join();
t2.join();
} catch (InterruptedException ie) {}
}
}
Exception in thread Thread-0 java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
at java.util.HashMap$KeyIterator.next(HashMap.java:828)
at
org.apache.commons.dbcp.datasources.InstanceKeyObjectFactory.registerNewInstance(InstanceKeyObjectFactory.java:51)
at
org.apache.commons.dbcp.datasources.InstanceKeyDataSource.setDataSourceName(InstanceKeyDataSource.java:246)
at
potentialBugs.SharedPoolDataSourceTest$1.run(SharedPoolDataSourceTest.java:23)
at java.lang.Thread.run(Thread.java:619)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBCP-373) Ability to configure upper bound on total number of connections managed by pooled data sources across all keys (user/password).
[ https://issues.apache.org/jira/browse/DBCP-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated DBCP-373: - Fix Version/s: 2.0 Ability to configure upper bound on total number of connections managed by pooled data sources across all keys (user/password). --- Key: DBCP-373 URL: https://issues.apache.org/jira/browse/DBCP-373 Project: Commons Dbcp Issue Type: Improvement Affects Versions: 1.4 Reporter: Scott Cameron Fix For: 2.0 For a discussion about this request, please refer to: http://www.mail-archive.com/user@commons.apache.org/msg07215.html. In general, it feels like SharedPoolDataSource and PerUserPoolDataSource could be made much more powerful and flexible by exposing as much of the configurability of the underlying ObjectPool as possible. It seems to me that if consumers are going to want to customize behavior it is very likely that it is the ObjectPool that they will want to tweak. Exposing the power of the inner pool would be really useful. But if that doesn't make sense, at least allowing a global cap on the total number of connections across all keys in the pool data source would solve at least the problem I describe in the mailing list post. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBCP-367) minIdle's document is not correct
[ https://issues.apache.org/jira/browse/DBCP-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated DBCP-367: - Fix Version/s: 1.4.1 minIdle's document is not correct - Key: DBCP-367 URL: https://issues.apache.org/jira/browse/DBCP-367 Project: Commons Dbcp Issue Type: Improvement Affects Versions: 2.0 Reporter: Ken Tatsushita Priority: Trivial Fix For: 1.4.1 Attachments: configuration.xml.patch Hi experts! minIdle does not work when not running evictor thread. However, there is no description about it in the document. I think that need to add a note in document. I made a patch. Best regards. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBCP-364) BasicDataSourceFactory#createDataSource return signature should be BasicDataSourceFactory so that caller can invoke methods not declared in DataSource (e.g., close())
[ https://issues.apache.org/jira/browse/DBCP-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated DBCP-364: - Fix Version/s: 2.0 BasicDataSourceFactory#createDataSource return signature should be BasicDataSourceFactory so that caller can invoke methods not declared in DataSource (e.g., close()) -- Key: DBCP-364 URL: https://issues.apache.org/jira/browse/DBCP-364 Project: Commons Dbcp Issue Type: Improvement Reporter: ori Priority: Trivial Fix For: 2.0 BasicDataSourceFactory#createDataSource currently returns a DataSource instance. It should a return type of BasicDataSourceFactory. Otherwise the caller has to cast it to invoke close (and other methods specific to the implementation). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBCP-363) dbcp bundle should use DynamicImport
[ https://issues.apache.org/jira/browse/DBCP-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated DBCP-363: - Fix Version/s: 1.4.1 dbcp bundle should use DynamicImport Key: DBCP-363 URL: https://issues.apache.org/jira/browse/DBCP-363 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.3, 1.4 Reporter: Felix Mayerhuber Fix For: 1.4.1 The bundle provided in the maven central of the commons.dbcp doesn't have a DynamicImport defined. This resolves in following error: If you want to use a BasicDataSource class as dataSource and the class is provided by the osgi environment (equinox, ...) the dataSource is not able to be created due to a ClassNotFoundException. If the bundle would have set DynamicImport it works. (I had to change from your bundle to the commons.dbcp bundle provided by servicemix, because there the DynamicImport is set) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBCP-322) CPDSConnectionFactory.validateObject(Object) ignores Throwable
[
https://issues.apache.org/jira/browse/DBCP-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz updated DBCP-322:
-
Fix Version/s: (was: 1.4.1)
(was: 1.3.1)
2.0
This is a behavior change that could conceivably break some applications, so
pushing to 2.0
CPDSConnectionFactory.validateObject(Object) ignores Throwable
--
Key: DBCP-322
URL: https://issues.apache.org/jira/browse/DBCP-322
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 1.2, 1.2.1, 1.2.2, 1.3, 1.4
Reporter: Sebb
Fix For: 2.0
CPDSConnectionFactory.validateObject(Object) catches and ignores Throwable,
which is a bit excessive. For example:
{code}
if (rset != null) {
try {
rset.close();
} catch (Throwable t) {
// ignore
}
}
{code}
close() can only throw SQLException, and that is all that should be ignored.
In particular, ThreadDeath should never be ignored.
Same applies to KeyedCPDSConnectionFactory.
Basic[Managed]Datasource also catch Throwable, but rethrow it as
SQLNestedException.
This is a bit better, but there's still the problem with ThreadDeath.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBCP-319) Make private fields final where possible
[ https://issues.apache.org/jira/browse/DBCP-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated DBCP-319: - Fix Version/s: (was: 1.4.1) (was: 1.3.1) 2.0 Make private fields final where possible Key: DBCP-319 URL: https://issues.apache.org/jira/browse/DBCP-319 Project: Commons Dbcp Issue Type: Improvement Reporter: Sebb Fix For: 2.0 Attachments: DBCP-319-private-final.patch Several private fields could be made final: AbandonedTrace.config AbandonedTrace.AbandonedObjectException._createdTime cpdsadapter.PooledConnectionImpl: * connection * delegatingConnection * eventListeners * statementEventListeners * pstmtPool is protected, but could probably be made final if it were not for the API change that would imply cpdsadapter.PooledConnectionImpl.PStmtKey (nested class, variables are protected, but might as well be private) * all of its fields could be made final datasources.[Keyed]CPDSConnectionFactory.validatingMap datasources.[Keyed]CPDSConnectionFactory.pcMap managed.PoolableManagedConnection.transactionRegistry managed.PoolableManagedConnectionFactory.transactionRegistry managed.TransactionRegistry.transactionManager|caches|xaResources .AbandonedObjectPool.config|trace -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBCP-317) Findbugs: Class doesn't override equals in superclass
[ https://issues.apache.org/jira/browse/DBCP-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated DBCP-317: - Fix Version/s: (was: 1.4.1) (was: 1.3.1) 2.0 Findbugs: Class doesn't override equals in superclass - Key: DBCP-317 URL: https://issues.apache.org/jira/browse/DBCP-317 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.4 Reporter: Sebb Priority: Minor Fix For: 2.0 Findbugs: Class doesn't override equals in superclass - 8 instances This class extends a class that defines an equals method and adds fields, but doesn't define an equals method itself. Thus, equality on instances of this class will ignore the identity of the subclass and the added fields. Be sure this is what is intended, and that you don't need to override the equals method. Even if you don't need to override the equals method, consider overriding it anyway to document the fact that the equals method for the subclass just return the result of invoking super.equals(o). Classes (superclass) are: cpdsadapter.ConnectionImpl doesn't override DelegatingConnection.equals datasources.LRUMap doesn't override SequencedHashMap.equals managed.ManagedConnection doesn't override DelegatingConnection.equals managed.PoolableManagedConnection doesn't override DelegatingConnection.equals PoolableCallableStatement doesn't override DelegatingCallableStatement.equals PoolableConnection doesn't override DelegatingConnection.equals PoolablePreparedStatement doesn't override DelegatingPreparedStatement.equals PoolingConnection doesn't override DelegatingConnection.equals -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-724) 1
[ https://issues.apache.org/jira/browse/MATH-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-724: - Affects Version/s: (was: Nightly Builds) 1.0 1.1 1.2 2.0 2.1 2.2 Fix Version/s: 3.0 Summary: 1 (was: RandomDataImpl.nextInt does not distribute uniformly for negative lower bound) 1 - Key: MATH-724 URL: https://issues.apache.org/jira/browse/MATH-724 Project: Commons Math Issue Type: Bug Affects Versions: 1.0, 1.1, 1.2, 2.0, 2.1, 2.2 Reporter: Dennis Hendriks Fix For: 3.0 Attachments: NextIntTest3.java, NextIntUniformTest.java, NextUniformTest3.java, math-724-v2.patch, math-724-v3.patch, math-724.patch When using the RandomDataImpl.nextInt function to get a uniform sample in a [lower, upper] interval, when the lower value is less than zero, the output is not uniformly distributed, as the lowest value is practically never returned. See the attached NextIntUniformTest.java file. It uses a [-3, 5] interval. For several values between 0 and 1, testNextIntUniform1 prints the return value of RandomDataImpl.nextInt (as double and as int). We see that -2 through 5 are returned several times. The -3 value however, is only returned for 0.0, and is thus under-respresented in the integer samples. The output of test method testNextIntUniform2 also clearly shows that value -3 is never sampled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-724) RandomDataImpl.nextInt does not distribute uniformly for negative lower bound
[ https://issues.apache.org/jira/browse/MATH-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-724: - Summary: RandomDataImpl.nextInt does not distribute uniformly for negative lower bound (was: 1) RandomDataImpl.nextInt does not distribute uniformly for negative lower bound - Key: MATH-724 URL: https://issues.apache.org/jira/browse/MATH-724 Project: Commons Math Issue Type: Bug Affects Versions: 1.0, 1.1, 1.2, 2.0, 2.1, 2.2 Reporter: Dennis Hendriks Fix For: 3.0 Attachments: NextIntTest3.java, NextIntUniformTest.java, NextUniformTest3.java, math-724-v2.patch, math-724-v3.patch, math-724.patch When using the RandomDataImpl.nextInt function to get a uniform sample in a [lower, upper] interval, when the lower value is less than zero, the output is not uniformly distributed, as the lowest value is practically never returned. See the attached NextIntUniformTest.java file. It uses a [-3, 5] interval. For several values between 0 and 1, testNextIntUniform1 prints the return value of RandomDataImpl.nextInt (as double and as int). We see that -2 through 5 are returned several times. The -3 value however, is only returned for 0.0, and is thus under-respresented in the integer samples. The output of test method testNextIntUniform2 also clearly shows that value -3 is never sampled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-720) RandomDataImpl uses both JDKRandomGenerator and Well19937c, while contract/javadoc only specifies Well19937c.
[
https://issues.apache.org/jira/browse/MATH-720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz updated MATH-720:
-
Affects Version/s: (was: 3.0)
Nightly Builds
Fix Version/s: 3.0
RandomDataImpl uses both JDKRandomGenerator and Well19937c, while
contract/javadoc only specifies Well19937c.
-
Key: MATH-720
URL: https://issues.apache.org/jira/browse/MATH-720
Project: Commons Math
Issue Type: Bug
Affects Versions: Nightly Builds
Reporter: Dennis Hendriks
Labels: random, seed
Fix For: 3.0
Attachments: TestRandom.java
See attached unit test. I create a distribution, sample it (not printed), set
the seed to 0, and then print the next sample. I also create the same
distribution again, set the seed to 0, and then print the next sample. I
expect the same sample, as in both cases the seed was set to 0, just before
sampling. I however get this output:
{code}
5
4
{code}
The problem is in the org.apache.commons.math.random.RandomDataImpl class:
- The RandomDataImpl(RandomGenerator rand) constructor states in javadoc:
@param rand the source of (non-secure) random data (may be null, resulting
in default JDK-supplied generator)
- reSeed(long seed) method does: if (rand == null) rand = new
JDKRandomGenerator();
- reSeed() method does: if (rand == null) rand = new JDKRandomGenerator();
- class javadoc states: If no codeRandomGenerator/code is provided in
the constructor, the default is to use a Well19937c generator.
- getRan() does: if (rand == null) rand = new
Well19937c(System.currentTimeMillis() + System.identityHashCode(this));
- getRan() states in javadoc: Creates and initializes a default generator
if null. Uses a Well19937c generator with System.currentTimeMillis() +
System.identityHashCode(this)) as the default seed.
It seems that only Well19937c should be used, but the constructor javadoc,
and the implementation of the reSeed methods was not updated to match this. I
think the partial changes were done in MATH-701, more specifically, in commit
[1197626] (and related commit [1197716]).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-287) Add support for weighted descriptive statistics
[ https://issues.apache.org/jira/browse/MATH-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-287: - Assignee: (was: Phil Steitz) Add support for weighted descriptive statistics --- Key: MATH-287 URL: https://issues.apache.org/jira/browse/MATH-287 Project: Commons Math Issue Type: New Feature Affects Versions: 2.0 Reporter: Matthew Rowles Priority: Minor Fix For: 3.1 Attachments: weightTests.patch, weighted.patch Add support for weighted descriptive statistics, such as weighted variance. An example method call would be Variance.evaluate(double[] values, double[] weights, int begin, int length) - Suggested by mickey...@taosnet.com on the mailing list. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-449) Storeless covariance
[
https://issues.apache.org/jira/browse/MATH-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz updated MATH-449:
-
Assignee: (was: Phil Steitz)
Storeless covariance
Key: MATH-449
URL: https://issues.apache.org/jira/browse/MATH-449
Project: Commons Math
Issue Type: Improvement
Reporter: Patrick Meyer
Fix For: 3.1
Attachments: MATH-449.patch
Original Estimate: 168h
Remaining Estimate: 168h
Currently there is no storeless version for computing the covariance.
However, Pebay (2008) describes algorithms for on-line covariance
computations, [http://infoserve.sandia.gov/sand_doc/2008/086212.pdf]. I have
provided a simple class for implementing this algorithm. It would be nice to
have this integrated into org.apache.commons.math.stat.correlation.Covariance.
{code}
//This code is granted for inclusion in the Apache Commons under the terms of
the ASL.
public class StorelessCovariance{
private double deltaX = 0.0;
private double deltaY = 0.0;
private double meanX = 0.0;
private double meanY = 0.0;
private double N=0;
private Double covarianceNumerator=0.0;
private boolean unbiased=true;
public Covariance(boolean unbiased){
this.unbiased = unbiased;
}
public void increment(Double x, Double y){
if(x!=null y!=null){
N++;
deltaX = x - meanX;
deltaY = y - meanY;
meanX += deltaX/N;
meanY += deltaY/N;
covarianceNumerator += ((N-1.0)/N)*deltaX*deltaY;
}
}
public Double getResult(){
if(unbiased){
return covarianceNumerator/(N-1.0);
}else{
return covarianceNumerator/N;
}
}
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-665) QRDecomposition does not have a singularity threshold
[ https://issues.apache.org/jira/browse/MATH-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-665: - Fix Version/s: 3.0 QRDecomposition does not have a singularity threshold - Key: MATH-665 URL: https://issues.apache.org/jira/browse/MATH-665 Project: Commons Math Issue Type: Bug Reporter: Phil Steitz Fix For: 3.0 QRDecompositionImpl tests elements of rDiag for exact equality to 0 in checking singularity. A singularity threshold should be defined for this class and used in the singularity test. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-704) One of Variance.evaluate() methods does not work correctly
[ https://issues.apache.org/jira/browse/MATH-704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-704: - Fix Version/s: 3.0 One of Variance.evaluate() methods does not work correctly -- Key: MATH-704 URL: https://issues.apache.org/jira/browse/MATH-704 Project: Commons Math Issue Type: Bug Affects Versions: 2.2 Environment: Java 1.6 Reporter: Leonid Ilyevsky Fix For: 3.0 The method org.apache.commons.math.stat.descriptive.moment.Variance.evaluate(double[] values, double[] weights, double mean, int begin, int length) does not work properly. Looks loke it ignores the length parameter and grabs the whole dataset. Similar method in Mean class seems to work. I did not check other methods taking the part of the array; they may have the same problem. Workaround: I had to shrink my arrays and use the method without the length. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-691) Statistics.setVarianceImpl makes getStandardDeviation produce NaN
[
https://issues.apache.org/jira/browse/MATH-691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz updated MATH-691:
-
Fix Version/s: 3.0
Assignee: Phil Steitz
Statistics.setVarianceImpl makes getStandardDeviation produce NaN
-
Key: MATH-691
URL: https://issues.apache.org/jira/browse/MATH-691
Project: Commons Math
Issue Type: Bug
Affects Versions: 2.2
Environment: Windows 7 64-bit, java version 1.6.0_23
Reporter: Warren Tang
Assignee: Phil Steitz
Priority: Minor
Fix For: 3.0
Original Estimate: 5h
Remaining Estimate: 5h
Invoking SummaryStatistics.setVarianceImpl(new Variance(true/false) makes
getStandardDeviation produce NaN. The code to reproduce it:
{code:java}
int[] scores = {1, 2, 3, 4};
SummaryStatistics stats = new SummaryStatistics();
stats.setVarianceImpl(new Variance(false)); //use population variance
for(int i : scores) {
stats.addValue(i);
}
double sd = stats.getStandardDeviation();
System.out.println(sd);
{code}
A workaround suggested by Mikkel is:
{code:java}
double sd = FastMath.sqrt(stats.getSecondMoment() / stats.getN());
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau
[ https://issues.apache.org/jira/browse/MATH-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-699: - Affects Version/s: (was: 3.0) 2.2 Fix Version/s: 3.0 inverseCumulativeDistribution fails with cumulative distribution having a plateau - Key: MATH-699 URL: https://issues.apache.org/jira/browse/MATH-699 Project: Commons Math Issue Type: Bug Affects Versions: 2.2 Reporter: Sébastien Brisard Assignee: Sébastien Brisard Priority: Minor Fix For: 3.0 Attachments: AbstractContinuousDistributionTest.java, inv-cum-new-impl.zip This bug report follows MATH-692. The attached unit test fails. As required by the definition in MATH-692, the lower-bound of the interval on which the cdf is constant should be returned. This is not so at the moment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-703) Splitting up the distribution hierarchy
[ https://issues.apache.org/jira/browse/MATH-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-703: - Affects Version/s: 2.2 Fix Version/s: 3.0 Splitting up the distribution hierarchy --- Key: MATH-703 URL: https://issues.apache.org/jira/browse/MATH-703 Project: Commons Math Issue Type: Improvement Affects Versions: 2.2 Reporter: Christian Winter Priority: Minor Fix For: 3.0 Attachments: MATH-703_patch.zip As discussed on the mailing list (http://apache-commons.680414.n4.nabble.com/math-Distributions-over-sample-spaces-other-than-R-tp3931349p3931349.html), the distribution interfaces should be restructured. The most important point is to create one root interface for each domain. There should *not* be a common super-interace because different domains require different functionality. Additionally, a super-inferface would require to parametrize the domain which makes things more complicated (e.g., double would have to be replaced by Double). Currently, Commons Math supports distributions with real domain and distributions with integer domain. Thus there will be the interfaces RealDistribution and IntegerDistribution. Another point is to drop the special cases of distributions with real domain in order to simplify the structure. There won't be an interface for absolutely continuous distributions, and there won't be an interface for discrete distributions on the real domain. All the functionality required by the special cases can be defined in RealDistribution. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-650) FastMath has static code which slows the first access to FastMath
[ https://issues.apache.org/jira/browse/MATH-650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-650: - Fix Version/s: 3.0 FastMath has static code which slows the first access to FastMath - Key: MATH-650 URL: https://issues.apache.org/jira/browse/MATH-650 Project: Commons Math Issue Type: Improvement Affects Versions: Nightly Builds Environment: Android 2.3 (Dalvik VM with JIT) Reporter: Alexis Robert Priority: Minor Fix For: 3.0 Attachments: FastMathLoadCheck.java, LucTestPerformance.java Working on an Android application using Orekit, I've discovered that a simple FastMath.floor() takes about 4 to 5 secs on a 1GHz Nexus One phone (only the first time it's called). I've launched the Android profiling tool (traceview) and the problem seems to be linked with the static portion of FastMath code named // Initialize tables The timing resulted in : - FastMath.slowexp (40.8%) - FastMath.expint (39.2%) \- FastMath.quadmult() (95.6% of expint) - FastMath.slowlog (18.2%) Hoping that would help Thanks! Alexis Robert -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (POOL-190) Add API BaseObjectPool.isOpen()
[ https://issues.apache.org/jira/browse/POOL-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated POOL-190: - Issue Type: New Feature (was: Bug) Add API BaseObjectPool.isOpen() --- Key: POOL-190 URL: https://issues.apache.org/jira/browse/POOL-190 Project: Commons Pool Issue Type: New Feature Affects Versions: 1.5.6 Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) Maven home: C:\Java\apache-maven-3.0.3\bin\.. Java version: 1.6.0_24, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_24\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Reporter: Gary D. Gregory Fix For: 2.0 Attachments: isOpen.diff Add API BaseObjectPool.isOpen() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (POOL-190) Add API BaseObjectPool.isOpen()
[ https://issues.apache.org/jira/browse/POOL-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated POOL-190: - Issue Type: Bug (was: New Feature) Add API BaseObjectPool.isOpen() --- Key: POOL-190 URL: https://issues.apache.org/jira/browse/POOL-190 Project: Commons Pool Issue Type: Bug Affects Versions: 1.5.6 Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) Maven home: C:\Java\apache-maven-3.0.3\bin\.. Java version: 1.6.0_24, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_24\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Reporter: Gary D. Gregory Fix For: 2.0 Attachments: isOpen.diff Add API BaseObjectPool.isOpen() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (POOL-192) GenericKeyedObjectPool: clear() clears the keyed pool but does not decrease the item counter
[ https://issues.apache.org/jira/browse/POOL-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated POOL-192: - Fix Version/s: 1.5.7 Thanks for reporting this. GenericKeyedObjectPool: clear() clears the keyed pool but does not decrease the item counter Key: POOL-192 URL: https://issues.apache.org/jira/browse/POOL-192 Project: Commons Pool Issue Type: Bug Affects Versions: 1.5.6 Reporter: Helge Dannenberg Fix For: 1.5.7 If function 'clear(Object key)' in GenericKeyedObjectPool is called onto a keyed pool, the ObjectQueue (= the keyed pool) is removed from the pool list. Its items are deleteded in the function 'destroy()' afterwards. But as the ObjectQueue is already removed, the itemcounter _totalInternalProcessing is never decreased. As a result of this bug the pool exhausts even if the pool is empty. The solution is to decrease the counter _totalInternalProcessing in 'destroy()' also if ObjectQueue in null. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (POOL-189) close() does not release threads blocked on borrowObject()
[ https://issues.apache.org/jira/browse/POOL-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated POOL-189: - Fix Version/s: 1.5.7 Thanks for reporting this. close() does not release threads blocked on borrowObject() -- Key: POOL-189 URL: https://issues.apache.org/jira/browse/POOL-189 Project: Commons Pool Issue Type: Bug Affects Versions: 1.5.6 Environment: java 1.6.0_24 Reporter: Adrian Nistor Fix For: 1.5.7 Attachments: Test.java Hi, When I call close() and borrowObject() concurrently with no objects in the pool, close() will finish but borrowObject() is blocked forever. The documentation of close() mentions that borrowObject() should fail with IllegalStateException, so I would expect the waiting threads to throw IllegalStateException. I will attach a test that exposes this problem. For this test, the expected output is: 0 1 2 ... 4999 DONE But when the bug manifests (almost always for this test), the output is: 0 1 2 The test does not finish, it just gets stuck after printing several values. Is this a bug or am I reading the documentation wrongly? Is there a patch for this? Thanks! Adrian -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (POOL-190) Add API BaseObjectPool.isOpen()
[ https://issues.apache.org/jira/browse/POOL-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated POOL-190: - Fix Version/s: (was: 1.5.7) Removing 1.5.7 as this is an API change. Add API BaseObjectPool.isOpen() --- Key: POOL-190 URL: https://issues.apache.org/jira/browse/POOL-190 Project: Commons Pool Issue Type: New Feature Affects Versions: 1.5.6 Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) Maven home: C:\Java\apache-maven-3.0.3\bin\.. Java version: 1.6.0_24, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_24\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Reporter: Gary D. Gregory Fix For: 2.0 Attachments: isOpen.diff Add API BaseObjectPool.isOpen() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-762) Handle or document ReflectionToStringBuilder and ToStringBuilder for collections that are not thread safe
[
https://issues.apache.org/jira/browse/LANG-762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz updated LANG-762:
-
Attachment: ReflectionToStringBuilderConcurrencyTest.java
Attaching a test that illustrates the problem, which I don't think is solvable
by the [lang] code (so probably this class should not be committed, as it will
never pass).
The problem is that when you circumvent a class' internal synchronization to
protect fields, all bets are off in terms of data integrity or CoMod
exceptions. This should be clearly documented - i.e., users should be warned
that this class should not be used in concurrent applications, or at least
fields protected by synchronization should be excluded.
What is going on in the test case is that there are two different kinds of
threads spawned concurrently - one kind uses the reflection back door opened by
the builder to inspect an instance and the other kind mutates the instance
using its synchronized methods. Note that synchronizing the builder using the
private field's monitor will not solve the problem (i.e., the first patch does
not work) because what really needs to happen is that the access by the builder
needs to be synchronized using the instance's monitor. You could try to fix
that by synchronizing on the instance, which would solve this example; but
there is no guarantee that a class may not use its own internal locks, so there
is no generic solution to this problem.
My recommendation is to just document the danger associated with using
reflection to access private fields in the class javadoc.
Handle or document ReflectionToStringBuilder and ToStringBuilder for
collections that are not thread safe
-
Key: LANG-762
URL: https://issues.apache.org/jira/browse/LANG-762
Project: Commons Lang
Issue Type: Bug
Components: lang.builder.*
Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
Maven home: C:\Java\apache-maven-3.0.3\bin\..
Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_24\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: windows
Reporter: Gary D. Gregory
Attachments: ReflectionToStringBuilderConcurrencyTest.java,
patch-LANG762.txt
Moving discussion here from https://issues.apache.org/jira/browse/POOL-191
ConcurrentModificationException in GenericObjectPool LinkedList.
It is possible to get a {{ConcurrentModificationException}} in a
{{LinkedList}} from a Commons Pool {{GenericObjectPool}}.
This happens when I call {{ReflectionToStringBuilder.toString(this)}} from a
subclass of {{GenericObjectPool}}. My guess is that it would happen with just
{{ReflectionToStringBuilder.toString(gop)}}. IOW, subclassing does not have
anything to do with it I would venture.
For example, in this stack trace {{JmsSessionPool}} is a subclass of
{{GenericObjectPool}}.
{noformat}
java.util.ConcurrentModificationException
at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:761)
at java.util.LinkedList$ListItr.next(LinkedList.java:696)
at java.util.AbstractCollection.toString(AbstractCollection.java:421)
at java.lang.String.valueOf(String.java:2826)
at java.lang.StringBuffer.append(StringBuffer.java:219)
at
org.apache.commons.lang3.builder.ToStringStyle.appendDetail(ToStringStyle.java:598)
at
org.apache.commons.lang3.builder.ToStringStyle.appendInternal(ToStringStyle.java:473)
at
org.apache.commons.lang3.builder.ToStringStyle.append(ToStringStyle.java:436)
at
org.apache.commons.lang3.builder.ToStringBuilder.append(ToStringBuilder.java:848)
at
org.apache.commons.lang3.builder.ReflectionToStringBuilder.appendFieldsIn(ReflectionToStringBuilder.java:528)
at
org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:692)
at
org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:288)
at
org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:119)
at
com.seagullsw.appinterface.comm.jms.JmsSessionPool.toString(JmsSessionPool.java:120)
at java.lang.String.valueOf(String.java:2826)
at java.lang.StringBuffer.append(StringBuffer.java:219)
at
org.apache.commons.lang3.builder.ToStringStyle.appendDetail(ToStringStyle.java:586)
at
org.apache.commons.lang3.builder.ToStringStyle.appendInternal(ToStringStyle.java:550)
at
org.apache.commons.lang3.builder.ToStringStyle.append(ToStringStyle.java:436)
at
org.apache.commons.lang3.builder.ToStringBuilder.append(ToStringBuilder.java:848)
at
