[jira] [Commented] (DBCP-327) XAConnection is not closed
[ https://issues.apache.org/jira/browse/DBCP-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034426#comment-13034426 ] Clement Pang commented on DBCP-327: --- Not sure what's the workaround stated in the description is (other than to not use DBCP). Basically, one cannot use XA mySQL connections with DBCP if this bug is not fixed (since connections will never be closed properly). > XAConnection is not closed > -- > > Key: DBCP-327 > URL: https://issues.apache.org/jira/browse/DBCP-327 > Project: Commons Dbcp > Issue Type: Bug >Affects Versions: 1.4 > Environment: MySQL Connector/J 5.1.12; JOTM 2.1.9; propesed solution > is tested with Derby 10.5.3.0_1 as well >Reporter: Sergey Vladimirov >Priority: Minor > Labels: connection, leak, mysql, transactions, xa > Fix For: 1.3.1 > > Attachments: MySQL and DBCP.zip > > Original Estimate: 8h > Remaining Estimate: 8h > > After creation of connection in > DataSourceXAConnectionFactory::createConnection() the instance of > XAConnection is ready to be garbage collected. But in MySQL Connector/J this > instance holds the real physiscal connection to MySQL server. Thus, simple > test case (in attach) opens 2 connections to server and the first one can be > considered as "leak". > The possible solution is to close "parent" XA connection as soon as "child" > Connection is closed as well. Due to compatibility issues it may be an option > for BasicManagerDataSource. However, Derby seems okay with both variants > (according to my test cases with JOTM/Hibernate/Derby/DBCP(+-patch)) > In the attachment - "manual" test case, since i don't know how to count real > MySQL connection number in runtime. When BasicManagedDataSource is used > (change it at ~43) we can create breakpoint at line "connection.close();" > (~115). According to MySQL Administrator there are 2 connections, but > according to pool - only one. If BasicManagedDataSourceXAClose is used - > first connection correclty closed. > This issue created serious problems in out production system, but, due to > existing workaround (replace BasicManagedDataSource and > DataSourceXAConnectionFactory) priority is minor. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBCP-361) BasicManagedDataSource optional transaction enlistment
[ https://issues.apache.org/jira/browse/DBCP-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034367#comment-13034367 ] Aaron Hamid commented on DBCP-361: -- I don't know why Spring does not detect the existing transaction (both the platform tx manager and bmds are injected with the same (JOTM) tx manager), but it appears that this means BMDS won't work with Spring declarative transactions and PROPAGATION_REQUIRED (which is the default). > 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 > > 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. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DBCP-361) BasicManagedDataSource optional transaction enlistment
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 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. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (DBCP-360) BasicManagedDataSource fails with OracleXADataSource
[
https://issues.apache.org/jira/browse/DBCP-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Hamid closed DBCP-360.
> BasicManagedDataSource fails with OracleXADataSource
>
>
> Key: DBCP-360
> URL: https://issues.apache.org/jira/browse/DBCP-360
> Project: Commons Dbcp
> Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Aaron Hamid
>
> Using the same JDBC url and settings as in non-XA (driverClassName) mode, the
> BasicManagedDataSource will fail when it attempts to obtain an Oracle
> connection when using the Oracle oracle.jdbc.xa.client.OracleXADataSource
> datasource class.
> It appears that BasicManagedDataSource.createConnectionFactory is never
> actually setting the URL (I can't tell where if at all it is set, the
> exception must occur before then).
> class="org.apache.commons.dbcp.managed.BasicManagedDataSource"
> destroy-method="close">
>
>
>
>
>
>
> value="${datasource.pool.validationQuery}"/>
>
>
> value="${datasource.accessToUnderlyingConnectionAllowed}"/>
> name="connectionProperties">driverType=thin;portNumber=1521
>
>
> org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC
> Connection; nested exception is java.sql.SQLException: Cannot create
> PoolableConnectionFactory (Invalid Oracle URL specified:
> OracleDataSource.makeURL)
> Caused by: java.sql.SQLException: Cannot create PoolableConnectionFactory
> (Invalid Oracle URL specified: OracleDataSource.makeURL)
> at
> org.apache.commons.dbcp.managed.BasicManagedDataSource.createPoolableConnectionFactory(BasicManagedDataSource.java:200)
> at
> org.apache.commons.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:1388)
> at
> org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044)
> at
> org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:113)
> at
> org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:79)
> at
> org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:276)
> at ConnectionTest$1.doInTransaction(ConnectionTest.java:79)
> at
> org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:127)
> at ConnectionTest.testConnectionRecovery(ConnectionTest.java:76)
> at ConnectionTest.testOracleBMDSXARecovery(ConnectionTest.java:58)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
> at
> org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
> at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
> at
> org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
> at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
> at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
> at
> org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
> at
> org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
> at
> org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
> at
> org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
> at
> org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
> at
> org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> Caused by: java.sql.SQLException: Invalid Oracle URL specified:
> OracleDataSource.makeURL
> at
> oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
> at
> oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:146)
> at oracle.jdbc.pool.OracleDataSource.makeURL(OracleDataSource.java:1353)
> a
[jira] [Resolved] (DBCP-360) BasicManagedDataSource fails with OracleXADataSource
[
https://issues.apache.org/jira/browse/DBCP-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Hamid resolved DBCP-360.
--
Resolution: Invalid
invalid, the supported pattern is to inject a preconfigured XADataSource
instance. it might be worth making this a bit clearer in the docs: "NOTE: your
XADataSource implementation may require implementation-specific properties to
be set. If so, you must inject a preconstructed XADataSource object via
setXaDataSource.
> BasicManagedDataSource fails with OracleXADataSource
>
>
> Key: DBCP-360
> URL: https://issues.apache.org/jira/browse/DBCP-360
> Project: Commons Dbcp
> Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Aaron Hamid
>
> Using the same JDBC url and settings as in non-XA (driverClassName) mode, the
> BasicManagedDataSource will fail when it attempts to obtain an Oracle
> connection when using the Oracle oracle.jdbc.xa.client.OracleXADataSource
> datasource class.
> It appears that BasicManagedDataSource.createConnectionFactory is never
> actually setting the URL (I can't tell where if at all it is set, the
> exception must occur before then).
> class="org.apache.commons.dbcp.managed.BasicManagedDataSource"
> destroy-method="close">
>
>
>
>
>
>
> value="${datasource.pool.validationQuery}"/>
>
>
> value="${datasource.accessToUnderlyingConnectionAllowed}"/>
> name="connectionProperties">driverType=thin;portNumber=1521
>
>
> org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC
> Connection; nested exception is java.sql.SQLException: Cannot create
> PoolableConnectionFactory (Invalid Oracle URL specified:
> OracleDataSource.makeURL)
> Caused by: java.sql.SQLException: Cannot create PoolableConnectionFactory
> (Invalid Oracle URL specified: OracleDataSource.makeURL)
> at
> org.apache.commons.dbcp.managed.BasicManagedDataSource.createPoolableConnectionFactory(BasicManagedDataSource.java:200)
> at
> org.apache.commons.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:1388)
> at
> org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044)
> at
> org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:113)
> at
> org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:79)
> at
> org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:276)
> at ConnectionTest$1.doInTransaction(ConnectionTest.java:79)
> at
> org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:127)
> at ConnectionTest.testConnectionRecovery(ConnectionTest.java:76)
> at ConnectionTest.testOracleBMDSXARecovery(ConnectionTest.java:58)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
> at
> org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
> at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
> at
> org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
> at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
> at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
> at
> org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
> at
> org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
> at
> org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
> at
> org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
> at
> org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
> at
> org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> Caused
[jira] [Created] (DBCP-360) BasicManagedDataSource fails with OracleXADataSource
BasicManagedDataSource fails with OracleXADataSource Key: DBCP-360 URL: https://issues.apache.org/jira/browse/DBCP-360 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.4 Reporter: Aaron Hamid Using the same JDBC url and settings as in non-XA (driverClassName) mode, the BasicManagedDataSource will fail when it attempts to obtain an Oracle connection when using the Oracle oracle.jdbc.xa.client.OracleXADataSource datasource class. It appears that BasicManagedDataSource.createConnectionFactory is never actually setting the URL (I can't tell where if at all it is set, the exception must occur before then). driverType=thin;portNumber=1521 org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is java.sql.SQLException: Cannot create PoolableConnectionFactory (Invalid Oracle URL specified: OracleDataSource.makeURL) Caused by: java.sql.SQLException: Cannot create PoolableConnectionFactory (Invalid Oracle URL specified: OracleDataSource.makeURL) at org.apache.commons.dbcp.managed.BasicManagedDataSource.createPoolableConnectionFactory(BasicManagedDataSource.java:200) at org.apache.commons.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:1388) at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044) at org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:113) at org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:79) at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:276) at ConnectionTest$1.doInTransaction(ConnectionTest.java:79) at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:127) at ConnectionTest.testConnectionRecovery(ConnectionTest.java:76) at ConnectionTest.testOracleBMDSXARecovery(ConnectionTest.java:58) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44) at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) Caused by: java.sql.SQLException: Invalid Oracle URL specified: OracleDataSource.makeURL at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112) at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:146) at oracle.jdbc.pool.OracleDataSource.makeURL(OracleDataSource.java:1353) at oracle.jdbc.pool.OracleDataSource.getURL(OracleDataSource.java:1064) at oracle.jdbc.xa.client.OracleXADataSource.getPooledConnection(OracleXADataSource.java:204) at oracle.jdbc.xa.client.OracleXADataSource.getXAConnection(OracleXADataSource.java:159) at oracle.jdbc.xa.client.OracleXADataSource.getXAConnection(OracleXADataSource.java:133) at org.apache.commons.dbcp.managed.DataSourceXAConnectionFactory.createConnection(DataSourceXAConnectionFactory.java:103) at org.apache.com
[jira] [Commented] (OGNL-9) Upgrade JUnit to version4
[ https://issues.apache.org/jira/browse/OGNL-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034163#comment-13034163 ] Simone Tripodi commented on OGNL-9: --- WOW amazing, thanks!!! Please don't forget to explain me which kind of mistake I did :D > Upgrade JUnit to version4 > - > > Key: OGNL-9 > URL: https://issues.apache.org/jira/browse/OGNL-9 > Project: OGNL (Incubating) > Issue Type: Task >Reporter: Simone Tripodi >Assignee: Simone Tripodi > Attachments: ognl-9.patch > > > Actually OGNL is tested using JUnit3; in Commons we've been migrating tests > to JUnit4, as a first step just upgrading the dependency and refactoring the > Test classes just by dropping the TestCase inheritance and using the > annotation would be enough (methods refactoring dropping the 'test' prefix > can be postponed). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-578) Decrease DescriptiveStatistics performance from 2.0 to 2.2
[
https://issues.apache.org/jira/browse/MATH-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034152#comment-13034152
]
Mikkel Meyer Andersen commented on MATH-578:
As far as I can see, Percentile contributes a lot to the longer execution time,
so reopening MATH-417 for datasets of this type might be the right thing to do.
> Decrease DescriptiveStatistics performance from 2.0 to 2.2
> --
>
> Key: MATH-578
> URL: https://issues.apache.org/jira/browse/MATH-578
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Linux
>Reporter: Paolo Repele
>Assignee: Mikkel Meyer Andersen
>Priority: Minor
> Attachments: percentile.png
>
>
> Switching between commons-math 2.0 to 2.2 we note how the
> DescriptiveStatistics.addValue(double) has decrease the performance.
> I tested with 2 million values.
> DescriptiveStatistics ds = new DescriptiveStatistics();
> for(int i = 0; i<1000*1000*2; i++) { //2 million values
> ds.addValue(v);
> }
> ds.getPercentile(50);
> Seems that depending by the values inserted in the DescriptiveStatistics it
> takes different time:
> * with a single value (0)
> ** 2.0 -> take ~500 ms
> ** 2.2 -> take more than 10 minutes
> * with 50% fixed value (0) and 50% Math.random()
> ** 2.0 -> take ~500 ms
> ** 2.2 -> take ~25 ms -> ~250 second
> * with 100% Math.random()
> ** 2.0 -> take ~500 ms
> ** 2.2 -> take ~70 ms
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EMAIL-105) Clarify names for SSL and TLS
Clarify names for SSL and TLS
-
Key: EMAIL-105
URL: https://issues.apache.org/jira/browse/EMAIL-105
Project: Commons Email
Issue Type: Improvement
Reporter: Bruno Harbulot
The API offers two categories of settings for the configuration of SSL/TLS:
{{setSSL}} and {{setTLS}} (and respective associated methods).
The names are quite misleading, as this doesn't really oppose SSL and TLS. A
number of e-mail applications make this mistake, but "TLS" is used here to mean
"using STARTTLS" and "SSL" is used here to mean "SSL or TLS, upon connection".
The difference is that:
- With "SSL" (as incorrectly named here), the SMTP client connects to the SMTP
server on a dedicated port and starts the SSL/TLS handshake upon connection.
This is then followed by "normal" SMTP traffic on this SSL/TLS layer.
- With "TLS" (as incorrectly named here), the SMTP client connects to the SMTP
server on the same port as it would do for plain-text SMTP, exchanges a few
SMTP commands, including [STARTTLS (RFC
3207)|http://tools.ietf.org/html/rfc3207 ], and then starts an SSL/TLS
handshake to upgrade to a secure channel.
This is not so much a difference between SSL and TLS, but rather a difference
regarding when the connection is turned into a secure one.
The difference between SSLv3 and TLS 1.0 is mostly a version difference, where
SSLv3 is the predecessor of TLS 1.0.
You can have an TLS 1.0+ upon connection, using the "SSL" setting, without
using {{STARTTLS}} (it's a version configuration up to the {{SSLEngine}} or
{{SSLSocketFactory}}).
Similarly, although it's not written in the specification, some servers seem to
accept an SSLv3 handshake (instead of its successor version: TLS 1.0) after
{{STARTTLS}}.
I'd suggest deprecating {{setSSL}} and {{setTLS}} and replacing them with
{{setOnConnectSSL}} and {{setStartTLS}} (or similar), respectively.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VALIDATOR-292) [PATCH] @localhost and @localhost.localdomain email addresses aren't correctly detected as valid
[ https://issues.apache.org/jira/browse/VALIDATOR-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034096#comment-13034096 ] Nick Burch commented on VALIDATOR-292: -- Following discussions with commons committers at the Apache Retreat, I've re-worked the patch to follow the same design as validators such as the ISBN validator. By default, the domain and email validators will continue to declare localhost as invalid (as they always have done). For most people, this will be correct. For anyone running in a development environment (where localhost is wanted to be valid), a boolean can be passed when fetching the validator instance to toggle this. New patch for this pattern attached, along with unit tests. > [PATCH] @localhost and @localhost.localdomain email addresses aren't > correctly detected as valid > > > Key: VALIDATOR-292 > URL: https://issues.apache.org/jira/browse/VALIDATOR-292 > Project: Commons Validator > Issue Type: Bug > Components: Routines >Affects Versions: 1.4 >Reporter: Nick Burch > Attachments: CommonsValidatorLocalhost.patch > > > Email addresses of the form @localhost and > @localhost.localdomain are valid, but the Email Validator doesn't > detect this. > The attached patch fixes the underlying issue in the domain validator, and > adds unit tests for Domain + Email validation of these. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VALIDATOR-292) [PATCH] @localhost and @localhost.localdomain email addresses aren't correctly detected as valid
[ https://issues.apache.org/jira/browse/VALIDATOR-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Burch updated VALIDATOR-292: - Attachment: (was: CommonsValidatorLocalhost.patch) > [PATCH] @localhost and @localhost.localdomain email addresses aren't > correctly detected as valid > > > Key: VALIDATOR-292 > URL: https://issues.apache.org/jira/browse/VALIDATOR-292 > Project: Commons Validator > Issue Type: Bug > Components: Routines >Affects Versions: 1.4 >Reporter: Nick Burch > Attachments: CommonsValidatorLocalhost.patch > > > Email addresses of the form @localhost and > @localhost.localdomain are valid, but the Email Validator doesn't > detect this. > The attached patch fixes the underlying issue in the domain validator, and > adds unit tests for Domain + Email validation of these. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VALIDATOR-292) [PATCH] @localhost and @localhost.localdomain email addresses aren't correctly detected as valid
[ https://issues.apache.org/jira/browse/VALIDATOR-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Burch updated VALIDATOR-292: - Attachment: CommonsValidatorLocalhost.patch > [PATCH] @localhost and @localhost.localdomain email addresses aren't > correctly detected as valid > > > Key: VALIDATOR-292 > URL: https://issues.apache.org/jira/browse/VALIDATOR-292 > Project: Commons Validator > Issue Type: Bug > Components: Routines >Affects Versions: 1.4 >Reporter: Nick Burch > Attachments: CommonsValidatorLocalhost.patch, > CommonsValidatorLocalhost.patch > > > Email addresses of the form @localhost and > @localhost.localdomain are valid, but the Email Validator doesn't > detect this. > The attached patch fixes the underlying issue in the domain validator, and > adds unit tests for Domain + Email validation of these. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-578) Decrease DescriptiveStatistics performance from 2.0 to 2.2
[
https://issues.apache.org/jira/browse/MATH-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034094#comment-13034094
]
Mikkel Meyer Andersen commented on MATH-578:
Also, it seems like FastMath is new to 2.2. I'll try to investigate what causes
this.
> Decrease DescriptiveStatistics performance from 2.0 to 2.2
> --
>
> Key: MATH-578
> URL: https://issues.apache.org/jira/browse/MATH-578
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Linux
>Reporter: Paolo Repele
>Assignee: Mikkel Meyer Andersen
>Priority: Minor
> Attachments: percentile.png
>
>
> Switching between commons-math 2.0 to 2.2 we note how the
> DescriptiveStatistics.addValue(double) has decrease the performance.
> I tested with 2 million values.
> DescriptiveStatistics ds = new DescriptiveStatistics();
> for(int i = 0; i<1000*1000*2; i++) { //2 million values
> ds.addValue(v);
> }
> ds.getPercentile(50);
> Seems that depending by the values inserted in the DescriptiveStatistics it
> takes different time:
> * with a single value (0)
> ** 2.0 -> take ~500 ms
> ** 2.2 -> take more than 10 minutes
> * with 50% fixed value (0) and 50% Math.random()
> ** 2.0 -> take ~500 ms
> ** 2.2 -> take ~25 ms -> ~250 second
> * with 100% Math.random()
> ** 2.0 -> take ~500 ms
> ** 2.2 -> take ~70 ms
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-9) Upgrade JUnit to version4
[ https://issues.apache.org/jira/browse/OGNL-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034088#comment-13034088 ] Maurizio Cucchiara commented on OGNL-9: --- Hi Simone, good news! I'm working on it and it's almost done. Most of the unit test is passing now ! Stay tuned > Upgrade JUnit to version4 > - > > Key: OGNL-9 > URL: https://issues.apache.org/jira/browse/OGNL-9 > Project: OGNL (Incubating) > Issue Type: Task >Reporter: Simone Tripodi >Assignee: Simone Tripodi > Attachments: ognl-9.patch > > > Actually OGNL is tested using JUnit3; in Commons we've been migrating tests > to JUnit4, as a first step just upgrading the dependency and refactoring the > Test classes just by dropping the TestCase inheritance and using the > annotation would be enough (methods refactoring dropping the 'test' prefix > can be postponed). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MATH-578) Decrease DescriptiveStatistics performance from 2.0 to 2.2
[
https://issues.apache.org/jira/browse/MATH-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034070#comment-13034070
]
Paolo Repele edited comment on MATH-578 at 5/16/11 3:57 PM:
No Problem :)
* yep, the time was only for the getPercentile() method.
* I added an image where you can see the profile snapshot
Usually we use this library to analyze some grids. These grids can be very huge
and can be generated using the same values for all the cells or a continue
function around the grid or any combination of both.
Then we have really no idea how these grids can be generated.
was (Author: paolo.repele):
* yep, the time was only for the getPercentile() method.
* I added an image where you can see the profile snapshot
Usually we use this library to analyze some grids. These grids can be very huge
and can be generated using the same values for all the cells or a continue
function around the grid or any combination of both.
Then we have really no idea how these grids can be generated.
> Decrease DescriptiveStatistics performance from 2.0 to 2.2
> --
>
> Key: MATH-578
> URL: https://issues.apache.org/jira/browse/MATH-578
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Linux
>Reporter: Paolo Repele
>Assignee: Mikkel Meyer Andersen
>Priority: Minor
> Attachments: percentile.png
>
>
> Switching between commons-math 2.0 to 2.2 we note how the
> DescriptiveStatistics.addValue(double) has decrease the performance.
> I tested with 2 million values.
> DescriptiveStatistics ds = new DescriptiveStatistics();
> for(int i = 0; i<1000*1000*2; i++) { //2 million values
> ds.addValue(v);
> }
> ds.getPercentile(50);
> Seems that depending by the values inserted in the DescriptiveStatistics it
> takes different time:
> * with a single value (0)
> ** 2.0 -> take ~500 ms
> ** 2.2 -> take more than 10 minutes
> * with 50% fixed value (0) and 50% Math.random()
> ** 2.0 -> take ~500 ms
> ** 2.2 -> take ~25 ms -> ~250 second
> * with 100% Math.random()
> ** 2.0 -> take ~500 ms
> ** 2.2 -> take ~70 ms
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-578) Decrease DescriptiveStatistics performance from 2.0 to 2.2
[
https://issues.apache.org/jira/browse/MATH-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034070#comment-13034070
]
Paolo Repele commented on MATH-578:
---
* yep, the time was only for the getPercentile() method.
* I added an image where you can see the profile snapshot
Usually we use this library to analyze some grids. These grids can be very huge
and can be generated using the same values for all the cells or a continue
function around the grid or any combination of both.
Then we have really no idea how these grids can be generated.
> Decrease DescriptiveStatistics performance from 2.0 to 2.2
> --
>
> Key: MATH-578
> URL: https://issues.apache.org/jira/browse/MATH-578
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Linux
>Reporter: Paolo Repele
>Assignee: Mikkel Meyer Andersen
>Priority: Minor
> Attachments: percentile.png
>
>
> Switching between commons-math 2.0 to 2.2 we note how the
> DescriptiveStatistics.addValue(double) has decrease the performance.
> I tested with 2 million values.
> DescriptiveStatistics ds = new DescriptiveStatistics();
> for(int i = 0; i<1000*1000*2; i++) { //2 million values
> ds.addValue(v);
> }
> ds.getPercentile(50);
> Seems that depending by the values inserted in the DescriptiveStatistics it
> takes different time:
> * with a single value (0)
> ** 2.0 -> take ~500 ms
> ** 2.2 -> take more than 10 minutes
> * with 50% fixed value (0) and 50% Math.random()
> ** 2.0 -> take ~500 ms
> ** 2.2 -> take ~25 ms -> ~250 second
> * with 100% Math.random()
> ** 2.0 -> take ~500 ms
> ** 2.2 -> take ~70 ms
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-578) Decrease DescriptiveStatistics performance from 2.0 to 2.2
[
https://issues.apache.org/jira/browse/MATH-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034068#comment-13034068
]
Mikkel Meyer Andersen commented on MATH-578:
Sorry for my (too) short first answer. Thanks for your proper introduction,
Phil.
I'll try a more detailed profiling to see what's causing the performance
problems.
> Decrease DescriptiveStatistics performance from 2.0 to 2.2
> --
>
> Key: MATH-578
> URL: https://issues.apache.org/jira/browse/MATH-578
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Linux
>Reporter: Paolo Repele
>Assignee: Mikkel Meyer Andersen
>Priority: Minor
> Attachments: percentile.png
>
>
> Switching between commons-math 2.0 to 2.2 we note how the
> DescriptiveStatistics.addValue(double) has decrease the performance.
> I tested with 2 million values.
> DescriptiveStatistics ds = new DescriptiveStatistics();
> for(int i = 0; i<1000*1000*2; i++) { //2 million values
> ds.addValue(v);
> }
> ds.getPercentile(50);
> Seems that depending by the values inserted in the DescriptiveStatistics it
> takes different time:
> * with a single value (0)
> ** 2.0 -> take ~500 ms
> ** 2.2 -> take more than 10 minutes
> * with 50% fixed value (0) and 50% Math.random()
> ** 2.0 -> take ~500 ms
> ** 2.2 -> take ~25 ms -> ~250 second
> * with 100% Math.random()
> ** 2.0 -> take ~500 ms
> ** 2.2 -> take ~70 ms
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-578) Decrease DescriptiveStatistics performance from 2.0 to 2.2
[
https://issues.apache.org/jira/browse/MATH-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paolo Repele updated MATH-578:
--
Attachment: percentile.png
Image file to show the profile snapshot
> Decrease DescriptiveStatistics performance from 2.0 to 2.2
> --
>
> Key: MATH-578
> URL: https://issues.apache.org/jira/browse/MATH-578
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Linux
>Reporter: Paolo Repele
>Assignee: Mikkel Meyer Andersen
>Priority: Minor
> Attachments: percentile.png
>
>
> Switching between commons-math 2.0 to 2.2 we note how the
> DescriptiveStatistics.addValue(double) has decrease the performance.
> I tested with 2 million values.
> DescriptiveStatistics ds = new DescriptiveStatistics();
> for(int i = 0; i<1000*1000*2; i++) { //2 million values
> ds.addValue(v);
> }
> ds.getPercentile(50);
> Seems that depending by the values inserted in the DescriptiveStatistics it
> takes different time:
> * with a single value (0)
> ** 2.0 -> take ~500 ms
> ** 2.2 -> take more than 10 minutes
> * with 50% fixed value (0) and 50% Math.random()
> ** 2.0 -> take ~500 ms
> ** 2.2 -> take ~25 ms -> ~250 second
> * with 100% Math.random()
> ** 2.0 -> take ~500 ms
> ** 2.2 -> take ~70 ms
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-578) Decrease DescriptiveStatistics performance from 2.0 to 2.2
[
https://issues.apache.org/jira/browse/MATH-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034061#comment-13034061
]
Phil Steitz commented on MATH-578:
--
Thanks for reporting this. I assume the timings include the percentile
calculation, right?
This could be related to the changes in the Percentile implementation in 2.2.
If isolating the timing to just the percentile calculation shows that is where
the latency difference is, we should reopen MATH-417. The changes there were
to improve Percentile performance, which in most cases they do. The first two
results above are disturbing, however. If your data is largely constant and
this creates a problem in your application, as a workaround, you can provide an
alternative Percentile implementation to DescriptiveStatistics using
setPercentileImpl.
> Decrease DescriptiveStatistics performance from 2.0 to 2.2
> --
>
> Key: MATH-578
> URL: https://issues.apache.org/jira/browse/MATH-578
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Linux
>Reporter: Paolo Repele
>Assignee: Mikkel Meyer Andersen
>Priority: Minor
>
> Switching between commons-math 2.0 to 2.2 we note how the
> DescriptiveStatistics.addValue(double) has decrease the performance.
> I tested with 2 million values.
> DescriptiveStatistics ds = new DescriptiveStatistics();
> for(int i = 0; i<1000*1000*2; i++) { //2 million values
> ds.addValue(v);
> }
> ds.getPercentile(50);
> Seems that depending by the values inserted in the DescriptiveStatistics it
> takes different time:
> * with a single value (0)
> ** 2.0 -> take ~500 ms
> ** 2.2 -> take more than 10 minutes
> * with 50% fixed value (0) and 50% Math.random()
> ** 2.0 -> take ~500 ms
> ** 2.2 -> take ~25 ms -> ~250 second
> * with 100% Math.random()
> ** 2.0 -> take ~500 ms
> ** 2.2 -> take ~70 ms
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-578) Decrease DescriptiveStatistics performance from 2.0 to 2.2
[
https://issues.apache.org/jira/browse/MATH-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034056#comment-13034056
]
Mikkel Meyer Andersen commented on MATH-578:
Have you tried more detailed profiling? E.g. in Eclipse to see which methods
are using the majority of time?
> Decrease DescriptiveStatistics performance from 2.0 to 2.2
> --
>
> Key: MATH-578
> URL: https://issues.apache.org/jira/browse/MATH-578
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Linux
>Reporter: Paolo Repele
>Priority: Minor
>
> Switching between commons-math 2.0 to 2.2 we note how the
> DescriptiveStatistics.addValue(double) has decrease the performance.
> I tested with 2 million values.
> DescriptiveStatistics ds = new DescriptiveStatistics();
> for(int i = 0; i<1000*1000*2; i++) { //2 million values
> ds.addValue(v);
> }
> ds.getPercentile(50);
> Seems that depending by the values inserted in the DescriptiveStatistics it
> takes different time:
> * with a single value (0)
> ** 2.0 -> take ~500 ms
> ** 2.2 -> take more than 10 minutes
> * with 50% fixed value (0) and 50% Math.random()
> ** 2.0 -> take ~500 ms
> ** 2.2 -> take ~25 ms -> ~250 second
> * with 100% Math.random()
> ** 2.0 -> take ~500 ms
> ** 2.2 -> take ~70 ms
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-350) Reading from an input stream to a .tar.gz ends up with a 'reading from an output buffer' exception
[
https://issues.apache.org/jira/browse/VFS-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034055#comment-13034055
]
Benson Margulies commented on VFS-350:
--
This is only triggered if, in the middle of reading from one file in the tgz, I
open other files and read those.
> Reading from an input stream to a .tar.gz ends up with a 'reading from an
> output buffer' exception
> --
>
> Key: VFS-350
> URL: https://issues.apache.org/jira/browse/VFS-350
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Benson Margulies
>
> I can turn this into a test case if needed.
> A source snippet:
> {noformat}
> FileObject annotations = root.getChild("annotations");
> FileContent annotationsContent = annotations.getContent();
> InputStream input = annotationsContent.getInputStream();
> InputStreamReader isr = new InputStreamReader(input,
> Charset.forName("utf-8"));
> BufferedReader lineReader = new BufferedReader(isr);
> String line;
> while ((line = lineReader.readLine()) != null) {
> }
> java.io.IOException: reading from an output buffer
> at
> org.apache.commons.vfs.provider.tar.TarBuffer.readRecord(TarBuffer.java:213)
> at
> org.apache.commons.vfs.provider.tar.TarInputStream.read(TarInputStream.java:386)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
> at
> org.apache.commons.vfs.util.MonitorInputStream.read(MonitorInputStream.java:74)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158)
> at java.io.InputStreamReader.read(InputStreamReader.java:167)
> at java.io.BufferedReader.fill(BufferedReader.java:136)
> at java.io.BufferedReader.readLine(BufferedReader.java:299)
> at java.io.BufferedReader.readLine(BufferedReader.java:362)
> at com.basistech.lsh.utils.TdtTestData.(TdtTestData.java:130)
> at
> com.basistech.lsh.utils.TdtTestDataTest.testTestDataReader(TdtTestDataTest.java:36)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VFS-350) Reading from an input stream to a .tar.gz ends up with a 'reading from an output buffer' exception
Reading from an input stream to a .tar.gz ends up with a 'reading from an
output buffer' exception
--
Key: VFS-350
URL: https://issues.apache.org/jira/browse/VFS-350
Project: Commons VFS
Issue Type: Bug
Affects Versions: 1.0
Reporter: Benson Margulies
I can turn this into a test case if needed.
A source snippet:
{noformat}
FileObject annotations = root.getChild("annotations");
FileContent annotationsContent = annotations.getContent();
InputStream input = annotationsContent.getInputStream();
InputStreamReader isr = new InputStreamReader(input, Charset.forName("utf-8"));
BufferedReader lineReader = new BufferedReader(isr);
String line;
while ((line = lineReader.readLine()) != null) {
}
java.io.IOException: reading from an output buffer
at
org.apache.commons.vfs.provider.tar.TarBuffer.readRecord(TarBuffer.java:213)
at
org.apache.commons.vfs.provider.tar.TarInputStream.read(TarInputStream.java:386)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
at
org.apache.commons.vfs.util.MonitorInputStream.read(MonitorInputStream.java:74)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158)
at java.io.InputStreamReader.read(InputStreamReader.java:167)
at java.io.BufferedReader.fill(BufferedReader.java:136)
at java.io.BufferedReader.readLine(BufferedReader.java:299)
at java.io.BufferedReader.readLine(BufferedReader.java:362)
at com.basistech.lsh.utils.TdtTestData.(TdtTestData.java:130)
at
com.basistech.lsh.utils.TdtTestDataTest.testTestDataReader(TdtTestDataTest.java:36)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at
org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-578) Decrease DescriptiveStatistics performance from 2.0 to 2.2
Decrease DescriptiveStatistics performance from 2.0 to 2.2
--
Key: MATH-578
URL: https://issues.apache.org/jira/browse/MATH-578
Project: Commons Math
Issue Type: Bug
Affects Versions: 2.2
Environment: Linux
Reporter: Paolo Repele
Priority: Minor
Switching between commons-math 2.0 to 2.2 we note how the
DescriptiveStatistics.addValue(double) has decrease the performance.
I tested with 2 million values.
DescriptiveStatistics ds = new DescriptiveStatistics();
for(int i = 0; i<1000*1000*2; i++) { //2 million values
ds.addValue(v);
}
ds.getPercentile(50);
Seems that depending by the values inserted in the DescriptiveStatistics it
takes different time:
* with a single value (0)
** 2.0 -> take ~500 ms
** 2.2 -> take more than 10 minutes
* with 50% fixed value (0) and 50% Math.random()
** 2.0 -> take ~500 ms
** 2.2 -> take ~25 ms -> ~250 second
* with 100% Math.random()
** 2.0 -> take ~500 ms
** 2.2 -> take ~70 ms
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JEXL-111) expression execute error
expression execute error Key: JEXL-111 URL: https://issues.apache.org/jira/browse/JEXL-111 Project: Commons JEXL Issue Type: Bug Affects Versions: 2.0.1 Environment: sun hotspot Reporter: freish Priority: Minor i run jexl with bsf3.1. The jars are:bsf-api-3.1.jar,commons-jexl-2.0.1.jar and commons-logging-1.1.1.jar. the express is as follows: "((x>0)?\"FirstValue\"+(y-x):\"SecondValue\"+x)". however the value y is ,if x is a integer,the expression get right.but if x is a float point number such as 1.0,an Exception is thrown: org.apache.commons.jexl2.JexlException: org.apache.commons.jexl2.scripting.JexlScriptEngine.eval@214![0,5]: 'x > 0? 'FirstValue' + y - x : 'SecondValue' + x;' > error Then,what's the matter with this? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-574) Remove the restriction that the two vectors in RealVector.outerProduct have to be of the same size.
[ https://issues.apache.org/jira/browse/MATH-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13033993#comment-13033993 ] Gilles commented on MATH-574: - "OpenMapRealVector" fixed revision 1103716. > Remove the restriction that the two vectors in RealVector.outerProduct have > to be of the same size. > --- > > Key: MATH-574 > URL: https://issues.apache.org/jira/browse/MATH-574 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 2.2, 3.0 > Environment: All. >Reporter: Emile Ben Nasatyr >Priority: Minor > Labels: matrix, vector > Fix For: 3.0 > > Original Estimate: 24h > Remaining Estimate: 24h > > Currently RealMatrix M = x.outerProduct(y) throws an exception if x and y are > different sizes. This is as documented in the Javadoc but not what one > expects mathematically (see e.g. http://en.wikipedia.org/wiki/Outer_product) > - the vectors can be any size. > So please remove the restriction that the vectors should be the same size, as > this doesn't seem to be necessary either mathematically or in terms of the > implementation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-577) Enhance Complex.java
[
https://issues.apache.org/jira/browse/MATH-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arne Plöse updated MATH-577:
Description:
Add some double shorthand methods to Complex fix different NaN checks in add
and subtract ! Testcase testAddNaN will fail (what should be the result ?)
What is missing JavaDoc and testcases.
was:
Add some double shorthand methods to Complex fix different NaN checks in add
and subtract ! Testcase testAddNaN will fail (what should be the result ?)
What is missing JavaDoc and testcases.
Sorry, I can't find anything to attach a file?
Index: src/main/java/org/apache/commons/math/complex/Complex.java
===
--- src/main/java/org/apache/commons/math/complex/Complex.java (Revision
1103615)
+++ src/main/java/org/apache/commons/math/complex/Complex.java (Arbeitskopie)
@@ -80,6 +80,15 @@
private final transient boolean isInfinite;
/**
+ * Create a complex number given the real part.
+ *
+ * @param real the real part
+ */
+public Complex(double real) {
+this(real, 0);
+}
+
+/**
* Create a complex number given the real and imaginary parts.
*
* @param real the real part
@@ -147,10 +156,20 @@
* @throws NullPointerException if rhs is null
*/
public Complex add(Complex rhs) {
+if (isAnyNaN(rhs)) {
+return Complex.NaN;
+}
return createComplex(real + rhs.getReal(),
imaginary + rhs.getImaginary());
}
+public Complex add(double rhs) {
+if (isAnyNaN(rhs)) {
+return Complex.NaN;
+}
+return createComplex(real + rhs, imaginary);
+}
+
/**
* Return the conjugate of this complex number. The conjugate of
* "A + Bi" is "A - Bi".
@@ -167,7 +186,7 @@
*/
public Complex conjugate() {
if (isNaN()) {
-return NaN;
+return Complex.NaN;
}
return createComplex(real, -imaginary);
}
@@ -208,18 +227,18 @@
* @throws NullPointerException if rhs is null
*/
public Complex divide(Complex rhs) {
-if (isNaN() || rhs.isNaN()) {
-return NaN;
+if (isAnyNaN(rhs)) {
+return Complex.NaN;
}
double c = rhs.getReal();
double d = rhs.getImaginary();
if (c == 0.0 && d == 0.0) {
-return NaN;
+return Complex.NaN;
}
if (rhs.isInfinite() && !isInfinite()) {
-return ZERO;
+return Complex.ZERO;
}
if (FastMath.abs(c) < FastMath.abs(d)) {
@@ -236,6 +255,28 @@
}
/**
+ * Just a condensed variant of divide with rhs.imaginary == 0...
+ * @param rhs
+ * @return
+ */
+public Complex divide(double rhs) {
+if (isAnyNaN(rhs)) {
+return Complex.NaN;
+}
+
+double d0 = 0;
+if (rhs == 0.0) {
+return Complex.NaN;
+}
+
+if (Double.isInfinite(rhs) && !isInfinite()) {
+return Complex.ZERO;
+}
+
+return createComplex(real / rhs, imaginary / rhs);
+}
+
+/**
* Test for the equality of two Complex objects.
*
* If both the real and imaginary parts of two Complex numbers
@@ -269,6 +310,13 @@
return false;
}
+/** {@inheritDoc} */
+@Override
+public String toString() {
+return String.format("%s %si", Double.toString(real),
Double.toString(imaginary));
+}
+
+
/**
* Get a hashCode for the complex number.
*
@@ -355,8 +403,8 @@
* @throws NullPointerException if rhs is null
*/
public Complex multiply(Complex rhs) {
-if (isNaN() || rhs.isNaN()) {
-return NaN;
+if (isAnyNaN(rhs)) {
+return Complex.NaN;
}
if (Double.isInfinite(real) || Double.isInfinite(imaginary) ||
Double.isInfinite(rhs.real)|| Double.isInfinite(rhs.imaginary)) {
@@ -394,8 +442,8 @@
* @return the complex number product
*/
public Complex multiply(double rhs) {
-if (isNaN() || Double.isNaN(rhs)) {
-return NaN;
+if (isAnyNaN(rhs)) {
+return Complex.NaN;
}
if (Double.isInfinite(real) || Double.isInfinite(imaginary) ||
Double.isInfinite(rhs)) {
@@ -415,7 +463,7 @@
*/
public Complex negate() {
if (isNaN()) {
-return NaN;
+return Complex.NaN;
}
return createComplex(-real, -imaginary);
@@ -440,14 +488,28 @@
* @throws NullPointerException if rhs is null
*/
public Complex subtract(Complex rhs) {
-if (isNaN() || rhs.isNaN()) {
-return NaN;
+if (isAnyNaN(rhs)) {
+return Complex.NaN;
}
-
return createComplex(real
[jira] [Updated] (MATH-577) Enhance Complex.java
[
https://issues.apache.org/jira/browse/MATH-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arne Plöse updated MATH-577:
Attachment: Complex.diff
OK her is the diff
> Enhance Complex.java
>
>
> Key: MATH-577
> URL: https://issues.apache.org/jira/browse/MATH-577
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Arne Plöse
>Priority: Minor
> Attachments: Complex.diff
>
>
> Add some double shorthand methods to Complex fix different NaN checks in add
> and subtract ! Testcase testAddNaN will fail (what should be the result ?)
> What is missing JavaDoc and testcases.
> Sorry, I can't find anything to attach a file?
> Index: src/main/java/org/apache/commons/math/complex/Complex.java
> ===
> --- src/main/java/org/apache/commons/math/complex/Complex.java
> (Revision 1103615)
> +++ src/main/java/org/apache/commons/math/complex/Complex.java
> (Arbeitskopie)
> @@ -80,6 +80,15 @@
> private final transient boolean isInfinite;
>
> /**
> + * Create a complex number given the real part.
> + *
> + * @param real the real part
> + */
> +public Complex(double real) {
> +this(real, 0);
> +}
> +
> +/**
> * Create a complex number given the real and imaginary parts.
> *
> * @param real the real part
> @@ -147,10 +156,20 @@
> * @throws NullPointerException if rhs is null
> */
> public Complex add(Complex rhs) {
> +if (isAnyNaN(rhs)) {
> +return Complex.NaN;
> +}
> return createComplex(real + rhs.getReal(),
> imaginary + rhs.getImaginary());
> }
>
> +public Complex add(double rhs) {
> +if (isAnyNaN(rhs)) {
> +return Complex.NaN;
> +}
> +return createComplex(real + rhs, imaginary);
> +}
> +
> /**
> * Return the conjugate of this complex number. The conjugate of
> * "A + Bi" is "A - Bi".
> @@ -167,7 +186,7 @@
> */
> public Complex conjugate() {
> if (isNaN()) {
> -return NaN;
> +return Complex.NaN;
> }
> return createComplex(real, -imaginary);
> }
> @@ -208,18 +227,18 @@
> * @throws NullPointerException if rhs is null
> */
> public Complex divide(Complex rhs) {
> -if (isNaN() || rhs.isNaN()) {
> -return NaN;
> +if (isAnyNaN(rhs)) {
> +return Complex.NaN;
> }
>
> double c = rhs.getReal();
> double d = rhs.getImaginary();
> if (c == 0.0 && d == 0.0) {
> -return NaN;
> +return Complex.NaN;
> }
>
> if (rhs.isInfinite() && !isInfinite()) {
> -return ZERO;
> +return Complex.ZERO;
> }
>
> if (FastMath.abs(c) < FastMath.abs(d)) {
> @@ -236,6 +255,28 @@
> }
>
> /**
> + * Just a condensed variant of divide with rhs.imaginary == 0...
> + * @param rhs
> + * @return
> + */
> +public Complex divide(double rhs) {
> +if (isAnyNaN(rhs)) {
> +return Complex.NaN;
> +}
> +
> +double d0 = 0;
> +if (rhs == 0.0) {
> +return Complex.NaN;
> +}
> +
> +if (Double.isInfinite(rhs) && !isInfinite()) {
> +return Complex.ZERO;
> +}
> +
> +return createComplex(real / rhs, imaginary / rhs);
> +}
> +
> +/**
> * Test for the equality of two Complex objects.
> *
> * If both the real and imaginary parts of two Complex numbers
> @@ -269,6 +310,13 @@
> return false;
> }
>
> +/** {@inheritDoc} */
> +@Override
> +public String toString() {
> +return String.format("%s %si", Double.toString(real),
> Double.toString(imaginary));
> +}
> +
> +
> /**
> * Get a hashCode for the complex number.
> *
> @@ -355,8 +403,8 @@
> * @throws NullPointerException if rhs is null
> */
> public Complex multiply(Complex rhs) {
> -if (isNaN() || rhs.isNaN()) {
> -return NaN;
> +if (isAnyNaN(rhs)) {
> +return Complex.NaN;
> }
> if (Double.isInfinite(real) || Double.isInfinite(imaginary) ||
> Double.isInfinite(rhs.real)|| Double.isInfinite(rhs.imaginary)) {
> @@ -394,8 +442,8 @@
> * @return the complex number product
> */
> public Complex multiply(double rhs) {
> -if (isNaN() || Double.isNaN(rhs)) {
> -return NaN;
> +if (isAnyNaN(rhs)) {
> +return Complex.NaN;
> }
> if (Double.isInfinite(real) || Double.isInfinite(imaginary) ||
> Double.isInfinite(rhs)) {
> @@ -415,7 +463,7 @@
>
[jira] [Created] (MATH-577) Enhance Complex.java
Enhance Complex.java
Key: MATH-577
URL: https://issues.apache.org/jira/browse/MATH-577
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.0
Reporter: Arne Plöse
Priority: Minor
Add some double shorthand methods to Complex fix different NaN checks in add
and subtract ! Testcase testAddNaN will fail (what should be the result ?)
What is missing JavaDoc and testcases.
Sorry, I can't find anything to attach a file?
Index: src/main/java/org/apache/commons/math/complex/Complex.java
===
--- src/main/java/org/apache/commons/math/complex/Complex.java (Revision
1103615)
+++ src/main/java/org/apache/commons/math/complex/Complex.java (Arbeitskopie)
@@ -80,6 +80,15 @@
private final transient boolean isInfinite;
/**
+ * Create a complex number given the real part.
+ *
+ * @param real the real part
+ */
+public Complex(double real) {
+this(real, 0);
+}
+
+/**
* Create a complex number given the real and imaginary parts.
*
* @param real the real part
@@ -147,10 +156,20 @@
* @throws NullPointerException if rhs is null
*/
public Complex add(Complex rhs) {
+if (isAnyNaN(rhs)) {
+return Complex.NaN;
+}
return createComplex(real + rhs.getReal(),
imaginary + rhs.getImaginary());
}
+public Complex add(double rhs) {
+if (isAnyNaN(rhs)) {
+return Complex.NaN;
+}
+return createComplex(real + rhs, imaginary);
+}
+
/**
* Return the conjugate of this complex number. The conjugate of
* "A + Bi" is "A - Bi".
@@ -167,7 +186,7 @@
*/
public Complex conjugate() {
if (isNaN()) {
-return NaN;
+return Complex.NaN;
}
return createComplex(real, -imaginary);
}
@@ -208,18 +227,18 @@
* @throws NullPointerException if rhs is null
*/
public Complex divide(Complex rhs) {
-if (isNaN() || rhs.isNaN()) {
-return NaN;
+if (isAnyNaN(rhs)) {
+return Complex.NaN;
}
double c = rhs.getReal();
double d = rhs.getImaginary();
if (c == 0.0 && d == 0.0) {
-return NaN;
+return Complex.NaN;
}
if (rhs.isInfinite() && !isInfinite()) {
-return ZERO;
+return Complex.ZERO;
}
if (FastMath.abs(c) < FastMath.abs(d)) {
@@ -236,6 +255,28 @@
}
/**
+ * Just a condensed variant of divide with rhs.imaginary == 0...
+ * @param rhs
+ * @return
+ */
+public Complex divide(double rhs) {
+if (isAnyNaN(rhs)) {
+return Complex.NaN;
+}
+
+double d0 = 0;
+if (rhs == 0.0) {
+return Complex.NaN;
+}
+
+if (Double.isInfinite(rhs) && !isInfinite()) {
+return Complex.ZERO;
+}
+
+return createComplex(real / rhs, imaginary / rhs);
+}
+
+/**
* Test for the equality of two Complex objects.
*
* If both the real and imaginary parts of two Complex numbers
@@ -269,6 +310,13 @@
return false;
}
+/** {@inheritDoc} */
+@Override
+public String toString() {
+return String.format("%s %si", Double.toString(real),
Double.toString(imaginary));
+}
+
+
/**
* Get a hashCode for the complex number.
*
@@ -355,8 +403,8 @@
* @throws NullPointerException if rhs is null
*/
public Complex multiply(Complex rhs) {
-if (isNaN() || rhs.isNaN()) {
-return NaN;
+if (isAnyNaN(rhs)) {
+return Complex.NaN;
}
if (Double.isInfinite(real) || Double.isInfinite(imaginary) ||
Double.isInfinite(rhs.real)|| Double.isInfinite(rhs.imaginary)) {
@@ -394,8 +442,8 @@
* @return the complex number product
*/
public Complex multiply(double rhs) {
-if (isNaN() || Double.isNaN(rhs)) {
-return NaN;
+if (isAnyNaN(rhs)) {
+return Complex.NaN;
}
if (Double.isInfinite(real) || Double.isInfinite(imaginary) ||
Double.isInfinite(rhs)) {
@@ -415,7 +463,7 @@
*/
public Complex negate() {
if (isNaN()) {
-return NaN;
+return Complex.NaN;
}
return createComplex(-real, -imaginary);
@@ -440,14 +488,28 @@
* @throws NullPointerException if rhs is null
*/
public Complex subtract(Complex rhs) {
-if (isNaN() || rhs.isNaN()) {
-return NaN;
+if (isAnyNaN(rhs)) {
+return Complex.NaN;
}
-
return createComplex(real - rhs.getReal(),
imaginary - rhs.getImaginary());
}
+protected boolean isAnyNaN
