[jira] [Commented] (MATH-579) FastMath.pow much slower than Math.pow
[ https://issues.apache.org/jira/browse/MATH-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13035213#comment-13035213 ] Arne Plöse commented on MATH-579: - How it I stumbled over it: I did debug my app, and came across the call to FastMath.pow() (first call) it took some time (100 ms) to complete the call. Then I searched the javadoc for pow - nothing the same for class FastMath - nothing. So I decided must be a bug. As you wrote FastMath is no general replacement of Math as the name Fast* would suggest, but it is intended for large scale operation. If you want prevent confusion by end users (developers), a hint would be fine. FastMath.pow much slower than Math.pow -- Key: MATH-579 URL: https://issues.apache.org/jira/browse/MATH-579 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Environment: java version 1.6.0_22 OpenJDK Runtime Environment (IcedTea6 1.10.1) (6b22-1.10.1-0ubuntu1) OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode) java version 1.6.0_24 Java(TM) SE Runtime Environment (build 1.6.0_24-b07) Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode) Reporter: Arne Plöse calculating FastMath.pow(10, 0.1 / 20) is approximately 65 times slower as the Math.pow() function. Ether this is a bug or a javadoc comment is missing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-408) problem connecting to ProFTPD with FTPES
[
https://issues.apache.org/jira/browse/NET-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13035250#comment-13035250
]
Sebb commented on NET-408:
--
Are you able to connect to the server with other FTP clients? If so which, and
what settings do you use?
It would help if you could attach a sample of the code you are using.
problem connecting to ProFTPD with FTPES
Key: NET-408
URL: https://issues.apache.org/jira/browse/NET-408
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 2.2, 3.0
Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1
32bit, Kernel 2.6.16.46-0.12-default (config file attached)
ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
Java 1.5
Reporter: Michael Voigt
Attachments: proftpd.conf
I have a problem with the FTPClient connecting to a ProFTPD server.
If the server uses the configuration option TLSProtocol TLSv1, I
cannot connect to it at all. I recieve the following error message:
- javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
On the server side I see in the log:
unable to accept TLS connection: protocol error:
- (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
certificate unknown
- TLS/TLS-C negotiation failed on control channel
If the server uses the configuration option TLSProtocol SSLv23, I
can connect to it but I cant transfer any files. In the server log I
see:
- starting TLS negotiation on data connection
- TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
- client did not reuse SSL session, rejecting data connection (see
TLSOption NoSessionReuseRequired)
- unable to open data connection: TLS negotiation failed
If I add the NoSessionReuseRequired parameter to the ProFTPD config
everything works fine.
Here is my code:
FTPClient ftpClient = new FTPClient();
ftpClient = new FTPSClient(TLS);
// this throws an exception with TLSProtocol TLSv1
ftpClient.connect(host, port);
int reply = ftpClient.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
ftpClient.disconnect();
log.error(The FTP Server did not return a positive
completion reply!);
throw new
FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
}
boolean loginSuccessful = ftpClient.login(userName, password);
if (!loginSuccessful) {
log.error(Login to the FTP Server failed! The
credentials are not valid.);
throw new
FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
}
ftpClient.execPBSZ(0);
ftpClient.execPROT(P);
boolean success = ftpClient.storeFile(fileName, fis);
if (!success) {
// this is false if NoSessionReuseRequired is not set
}
Now my question is if it is generally possible to connect to a server
with TLSProtocol TLSv1 or TLSProtocol SSLv23 without the
NoSessionReuseRequired parameter? Could someone provide a piece of
example code for this?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OGNL-13) Ant maintenance
[ https://issues.apache.org/jira/browse/OGNL-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi updated OGNL-13: --- Summary: Ant maintenance (was: Ant maintainance) Ant maintenance --- Key: OGNL-13 URL: https://issues.apache.org/jira/browse/OGNL-13 Project: OGNL (Incubating) Issue Type: Task Reporter: Simone Tripodi I propose to drop existing ant build and replace with a fresh new one once we will have closed all build related issues (i.e. OGNL-8). If there are no objects, I will proceed on removing ant related stuff -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-13) Ant maintenance
[ https://issues.apache.org/jira/browse/OGNL-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13035255#comment-13035255 ] Hudson commented on OGNL-13: Integrated in ognl #63 (See [https://builds.apache.org/hudson/job/ognl/63/]) [OGNL-13] Ant maintenance part one: dropped old OpenSymphony related stuff simonetripodi : http://svn.apache.org/viewvc/?view=revrev=1124145 Files : * /incubator/ognl/trunk/build.xml * /incubator/ognl/trunk/build.properties * /incubator/ognl/trunk/osbuild.xml Ant maintenance --- Key: OGNL-13 URL: https://issues.apache.org/jira/browse/OGNL-13 Project: OGNL (Incubating) Issue Type: Task Reporter: Simone Tripodi I propose to drop existing ant build and replace with a fresh new one once we will have closed all build related issues (i.e. OGNL-8). If there are no objects, I will proceed on removing ant related stuff -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-579) FastMath.pow much slower than Math.pow
[ https://issues.apache.org/jira/browse/MATH-579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-579. Resolution: Fixed Fix Version/s: 3.0 So I have added a thorough explanation in the class javadoc without any code change as of r1124151. Thanks for reporting the issue and discussing about it. FastMath.pow much slower than Math.pow -- Key: MATH-579 URL: https://issues.apache.org/jira/browse/MATH-579 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Environment: java version 1.6.0_22 OpenJDK Runtime Environment (IcedTea6 1.10.1) (6b22-1.10.1-0ubuntu1) OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode) java version 1.6.0_24 Java(TM) SE Runtime Environment (build 1.6.0_24-b07) Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode) Reporter: Arne Plöse Fix For: 3.0 calculating FastMath.pow(10, 0.1 / 20) is approximately 65 times slower as the Math.pow() function. Ether this is a bug or a javadoc comment is missing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-579) FastMath.pow much slower than Math.pow
[ https://issues.apache.org/jira/browse/MATH-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13035259#comment-13035259 ] Gilles commented on MATH-579: - In the end, it is the _absolute_ running time that counts. If you call pow _once_ in an application, why would it matter that it takes 100 ms or 1 ms? Could it be that the Math class is already loaded (as part of the JVM initialization), so that FastMath is at a disadvantage in your benchmark (because it still needs to be loaded at the first call to pow)? I maintain that such a disclaimer (large scale usage) provides more confusion that it clears: What is large-scale? People who are worried will profile their (complete) application and can decide which implementation (of any interface) to use, based on realistic timings, not on a micro-benchmark (which can provide contradictory results). What we could do is add a link to the performance test class. FastMath.pow much slower than Math.pow -- Key: MATH-579 URL: https://issues.apache.org/jira/browse/MATH-579 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Environment: java version 1.6.0_22 OpenJDK Runtime Environment (IcedTea6 1.10.1) (6b22-1.10.1-0ubuntu1) OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode) java version 1.6.0_24 Java(TM) SE Runtime Environment (build 1.6.0_24-b07) Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode) Reporter: Arne Plöse Fix For: 3.0 calculating FastMath.pow(10, 0.1 / 20) is approximately 65 times slower as the Math.pow() function. Ether this is a bug or a javadoc comment is missing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CODEC-122) Bug in ColognePhonetic.java
Bug in ColognePhonetic.java --- Key: CODEC-122 URL: https://issues.apache.org/jira/browse/CODEC-122 Project: Commons Codec Issue Type: Bug Affects Versions: 1.5 Reporter: Dominic Herrmann During the use of org.apache.commons.codec.language.ColognePhonetic I recognized an error in method public String colognePhonetic(String text). The method does not handle the character 'J'. Thus Strings containig a J will not completely by calculated to the phonetic code. The characters 'J' will remain. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-408) problem connecting to ProFTPD with FTPES
[
https://issues.apache.org/jira/browse/NET-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13035279#comment-13035279
]
Michael Voigt commented on NET-408:
---
Yes, I can connect to the FTP Server with FileZilla. I attached a screenshot of
the settings.
The posted the code I'm using in the issue description.
problem connecting to ProFTPD with FTPES
Key: NET-408
URL: https://issues.apache.org/jira/browse/NET-408
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 2.2, 3.0
Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1
32bit, Kernel 2.6.16.46-0.12-default (config file attached)
ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
Java 1.5
Reporter: Michael Voigt
Attachments: ftpes.jpg, proftpd.conf
I have a problem with the FTPClient connecting to a ProFTPD server.
If the server uses the configuration option TLSProtocol TLSv1, I
cannot connect to it at all. I recieve the following error message:
- javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
On the server side I see in the log:
unable to accept TLS connection: protocol error:
- (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
certificate unknown
- TLS/TLS-C negotiation failed on control channel
If the server uses the configuration option TLSProtocol SSLv23, I
can connect to it but I cant transfer any files. In the server log I
see:
- starting TLS negotiation on data connection
- TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
- client did not reuse SSL session, rejecting data connection (see
TLSOption NoSessionReuseRequired)
- unable to open data connection: TLS negotiation failed
If I add the NoSessionReuseRequired parameter to the ProFTPD config
everything works fine.
Here is my code:
FTPClient ftpClient = new FTPClient();
ftpClient = new FTPSClient(TLS);
// this throws an exception with TLSProtocol TLSv1
ftpClient.connect(host, port);
int reply = ftpClient.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
ftpClient.disconnect();
log.error(The FTP Server did not return a positive
completion reply!);
throw new
FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
}
boolean loginSuccessful = ftpClient.login(userName, password);
if (!loginSuccessful) {
log.error(Login to the FTP Server failed! The
credentials are not valid.);
throw new
FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
}
ftpClient.execPBSZ(0);
ftpClient.execPROT(P);
boolean success = ftpClient.storeFile(fileName, fis);
if (!success) {
// this is false if NoSessionReuseRequired is not set
}
Now my question is if it is generally possible to connect to a server
with TLSProtocol TLSv1 or TLSProtocol SSLv23 without the
NoSessionReuseRequired parameter? Could someone provide a piece of
example code for this?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-408) problem connecting to ProFTPD with FTPES
[
https://issues.apache.org/jira/browse/NET-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Voigt updated NET-408:
--
Attachment: ftpes.jpg
problem connecting to ProFTPD with FTPES
Key: NET-408
URL: https://issues.apache.org/jira/browse/NET-408
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 2.2, 3.0
Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1
32bit, Kernel 2.6.16.46-0.12-default (config file attached)
ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
Java 1.5
Reporter: Michael Voigt
Attachments: ftpes.jpg, proftpd.conf
I have a problem with the FTPClient connecting to a ProFTPD server.
If the server uses the configuration option TLSProtocol TLSv1, I
cannot connect to it at all. I recieve the following error message:
- javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
On the server side I see in the log:
unable to accept TLS connection: protocol error:
- (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
certificate unknown
- TLS/TLS-C negotiation failed on control channel
If the server uses the configuration option TLSProtocol SSLv23, I
can connect to it but I cant transfer any files. In the server log I
see:
- starting TLS negotiation on data connection
- TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
- client did not reuse SSL session, rejecting data connection (see
TLSOption NoSessionReuseRequired)
- unable to open data connection: TLS negotiation failed
If I add the NoSessionReuseRequired parameter to the ProFTPD config
everything works fine.
Here is my code:
FTPClient ftpClient = new FTPClient();
ftpClient = new FTPSClient(TLS);
// this throws an exception with TLSProtocol TLSv1
ftpClient.connect(host, port);
int reply = ftpClient.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
ftpClient.disconnect();
log.error(The FTP Server did not return a positive
completion reply!);
throw new
FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
}
boolean loginSuccessful = ftpClient.login(userName, password);
if (!loginSuccessful) {
log.error(Login to the FTP Server failed! The
credentials are not valid.);
throw new
FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
}
ftpClient.execPBSZ(0);
ftpClient.execPROT(P);
boolean success = ftpClient.storeFile(fileName, fis);
if (!success) {
// this is false if NoSessionReuseRequired is not set
}
Now my question is if it is generally possible to connect to a server
with TLSProtocol TLSv1 or TLSProtocol SSLv23 without the
NoSessionReuseRequired parameter? Could someone provide a piece of
example code for this?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-122) Bug in ColognePhonetic.java
[ https://issues.apache.org/jira/browse/CODEC-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13035298#comment-13035298 ] Gary D. Gregory commented on CODEC-122: --- Can you provide an example with the expected answer? Bug in ColognePhonetic.java --- Key: CODEC-122 URL: https://issues.apache.org/jira/browse/CODEC-122 Project: Commons Codec Issue Type: Bug Affects Versions: 1.5 Reporter: Dominic Herrmann During the use of org.apache.commons.codec.language.ColognePhonetic I recognized an error in method public String colognePhonetic(String text). The method does not handle the character 'J'. Thus Strings containig a J will not completely by calculated to the phonetic code. The characters 'J' will remain. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-122) Bug in ColognePhonetic.java
[ https://issues.apache.org/jira/browse/CODEC-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13035338#comment-13035338 ] Dominic Herrmann commented on CODEC-122: For example the call colognePhonetic(Aychlmajr) delivers 0456J7, but it should be 04567 Bug in ColognePhonetic.java --- Key: CODEC-122 URL: https://issues.apache.org/jira/browse/CODEC-122 Project: Commons Codec Issue Type: Bug Affects Versions: 1.5 Reporter: Dominic Herrmann During the use of org.apache.commons.codec.language.ColognePhonetic I recognized an error in method public String colognePhonetic(String text). The method does not handle the character 'J'. Thus Strings containig a J will not completely by calculated to the phonetic code. The characters 'J' will remain. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CODEC-123) ColognePhonetic Javadoc should use HTML entities for special characters.
ColognePhonetic Javadoc should use HTML entities for special characters. Key: CODEC-123 URL: https://issues.apache.org/jira/browse/CODEC-123 Project: Commons Codec Issue Type: Bug Affects Versions: 1.5 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 Assignee: Gary D. Gregory Priority: Minor Fix For: 2.0 The ColognePhonetic class contains Javadoc with umlauts and other characters that do not always play well in editors. Change these characters to HTML entities. This means we should also be able to remove the UTF-8 settings in the POM for Javadoc. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-122) Bug in ColognePhonetic.java
[ https://issues.apache.org/jira/browse/CODEC-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13035351#comment-13035351 ] Gary D. Gregory commented on CODEC-122: --- I created a unit test for your example in trunk and it passes. Please see the trunk source. This code has not changed in trunk since the 1.5 release. Could you please double check your example? Bug in ColognePhonetic.java --- Key: CODEC-122 URL: https://issues.apache.org/jira/browse/CODEC-122 Project: Commons Codec Issue Type: Bug Affects Versions: 1.5 Reporter: Dominic Herrmann During the use of org.apache.commons.codec.language.ColognePhonetic I recognized an error in method public String colognePhonetic(String text). The method does not handle the character 'J'. Thus Strings containig a J will not completely by calculated to the phonetic code. The characters 'J' will remain. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CODEC-123) ColognePhonetic Javadoc should use HTML entities for special characters.
[ https://issues.apache.org/jira/browse/CODEC-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved CODEC-123. --- Resolution: Fixed Fixed in trunk. ColognePhonetic Javadoc should use HTML entities for special characters. Key: CODEC-123 URL: https://issues.apache.org/jira/browse/CODEC-123 Project: Commons Codec Issue Type: Bug Affects Versions: 1.5 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 Assignee: Gary D. Gregory Priority: Minor Fix For: 2.0 The ColognePhonetic class contains Javadoc with umlauts and other characters that do not always play well in editors. Change these characters to HTML entities. This means we should also be able to remove the UTF-8 settings in the POM for Javadoc. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CODEC-120) Migrate to JUnit 4
[ https://issues.apache.org/jira/browse/CODEC-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved CODEC-120. --- Resolution: Fixed In trunk now. Migrate to JUnit 4 -- Key: CODEC-120 URL: https://issues.apache.org/jira/browse/CODEC-120 Project: Commons Codec Issue Type: Improvement Reporter: Gary D. Gregory Fix For: 2.0 Migrate to JUnit 4 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-579) FastMath.pow much slower than Math.pow
[ https://issues.apache.org/jira/browse/MATH-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13035426#comment-13035426 ] Phil Steitz commented on MATH-579: -- I think Luc did a great job providing the right information to users. In answer to your question, Gilles, there are some applications where 100ms is a big deal and if they just make one or two calls, the associated latency will be surprising and could cause problems for them. If we get a lot of feedback from users indicating that this latency is a material practical problem for them, or prevents them using the library, we may want to consider making the embedded use configurable. I can think of only a few cases in my experience where this might be an issue; but I am thankful to Arne for having pointed it out and Luc for improving the documentation. FastMath.pow much slower than Math.pow -- Key: MATH-579 URL: https://issues.apache.org/jira/browse/MATH-579 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Environment: java version 1.6.0_22 OpenJDK Runtime Environment (IcedTea6 1.10.1) (6b22-1.10.1-0ubuntu1) OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode) java version 1.6.0_24 Java(TM) SE Runtime Environment (build 1.6.0_24-b07) Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode) Reporter: Arne Plöse Fix For: 3.0 calculating FastMath.pow(10, 0.1 / 20) is approximately 65 times slower as the Math.pow() function. Ether this is a bug or a javadoc comment is missing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-579) FastMath.pow much slower than Math.pow
[
https://issues.apache.org/jira/browse/MATH-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13035464#comment-13035464
]
Gilles commented on MATH-579:
-
{quote}
In answer to your question, Gilles, there are some applications where 100ms is
a big deal and if they just make one or two calls [...]
{quote}
This does not answer my question, which could be restated as: How can 100 ms
matter when the JVM can take several seconds to start up?
I'm curious of what real applications (that use CM) would run for less than a
few seconds...
{quote}
If we get a lot of feedback from users indicating that this latency is a
material practical problem for them, or prevents them using the library, we may
want to consider making the embedded use configurable.
{quote}
I surely hope that micro-benchmarks are not going to be taken into
consideration...
{quote}
I am thankful to Arne for having pointed it out [...]
{quote}
At the time FastMath was introduced, I had already pointed out the relative
slowness of some functions, to which it had been answered that the fast in
FastMath would kick in only when doing several millions calls (i.e. after the
JIT compiler would compile the methods to native code).
{quote}
I am thankful to [...] Luc for improving the documentation.
{quote}
+1
FastMath.pow much slower than Math.pow
--
Key: MATH-579
URL: https://issues.apache.org/jira/browse/MATH-579
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Environment: java version 1.6.0_22
OpenJDK Runtime Environment (IcedTea6 1.10.1) (6b22-1.10.1-0ubuntu1)
OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
java version 1.6.0_24
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
Reporter: Arne Plöse
Fix For: 3.0
calculating FastMath.pow(10, 0.1 / 20) is approximately 65 times slower as
the Math.pow() function.
Ether this is a bug or a javadoc comment is missing.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-408) problem connecting to ProFTPD with FTPES
[
https://issues.apache.org/jira/browse/NET-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13035478#comment-13035478
]
Bogdan Drozdowski commented on NET-408:
---
Try adding the TLSv1 protocol to the FTPSClient (if it's not there yet) with
the getEnabledProtocols() and setEnabledProtocols() methods. Also, the server
displays certificate unknown. Perhaps a client certificate was required by
the server and none was provided to the FTPSCilent class.
About session reusing: it doesn't look like it's implemented in FTPSClient (all
connections are created fresh), so right now you have to disable requiring
session reuse in your server.
Try implicit SSL mode and see if you get the same error when connecting.
I won't be much of a help, because my ProFTPd is not SSL-enabled and rejects
AUTH TLS.
problem connecting to ProFTPD with FTPES
Key: NET-408
URL: https://issues.apache.org/jira/browse/NET-408
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 2.2, 3.0
Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1
32bit, Kernel 2.6.16.46-0.12-default (config file attached)
ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
Java 1.5
Reporter: Michael Voigt
Attachments: ftpes.jpg, proftpd.conf
I have a problem with the FTPClient connecting to a ProFTPD server.
If the server uses the configuration option TLSProtocol TLSv1, I
cannot connect to it at all. I recieve the following error message:
- javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
On the server side I see in the log:
unable to accept TLS connection: protocol error:
- (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
certificate unknown
- TLS/TLS-C negotiation failed on control channel
If the server uses the configuration option TLSProtocol SSLv23, I
can connect to it but I cant transfer any files. In the server log I
see:
- starting TLS negotiation on data connection
- TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
- client did not reuse SSL session, rejecting data connection (see
TLSOption NoSessionReuseRequired)
- unable to open data connection: TLS negotiation failed
If I add the NoSessionReuseRequired parameter to the ProFTPD config
everything works fine.
Here is my code:
FTPClient ftpClient = new FTPClient();
ftpClient = new FTPSClient(TLS);
// this throws an exception with TLSProtocol TLSv1
ftpClient.connect(host, port);
int reply = ftpClient.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
ftpClient.disconnect();
log.error(The FTP Server did not return a positive
completion reply!);
throw new
FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
}
boolean loginSuccessful = ftpClient.login(userName, password);
if (!loginSuccessful) {
log.error(Login to the FTP Server failed! The
credentials are not valid.);
throw new
FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
}
ftpClient.execPBSZ(0);
ftpClient.execPROT(P);
boolean success = ftpClient.storeFile(fileName, fis);
if (!success) {
// this is false if NoSessionReuseRequired is not set
}
Now my question is if it is generally possible to connect to a server
with TLSProtocol TLSv1 or TLSProtocol SSLv23 without the
NoSessionReuseRequired parameter? Could someone provide a piece of
example code for this?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-579) FastMath.pow much slower than Math.pow
[
https://issues.apache.org/jira/browse/MATH-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13035501#comment-13035501
]
Luc Maisonobe commented on MATH-579:
{quote}
This does not answer my question, which could be restated as: How can 100 ms
matter when the JVM can take several seconds to start up?
I'm curious of what real applications (that use CM) would run for less than a
few seconds...
{quote}
I think mainly about hosted application, in environments like Eclipse, web
servers, service oriented architectures, perhaps even Android devices. The JVM
is already started but I'm not sure the class are reused between requests, I
think a new fresh context is set up with a new classloader, which involves
reloading the class.
For sure, micro-benchmark should be avoided. Despite it is quite old, the paper
about flawed micro benchmark by Brian Goetz
[http://www.ibm.com/developerworks/java/library/j-jtp02225/index.html] is
really enlightening.
If we get further reports about this latency, we may look at a way to
pre-compute the tables at compile time rather than at runtime to see if we can
save some milliseconds.
FastMath.pow much slower than Math.pow
--
Key: MATH-579
URL: https://issues.apache.org/jira/browse/MATH-579
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Environment: java version 1.6.0_22
OpenJDK Runtime Environment (IcedTea6 1.10.1) (6b22-1.10.1-0ubuntu1)
OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
java version 1.6.0_24
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
Reporter: Arne Plöse
Fix For: 3.0
calculating FastMath.pow(10, 0.1 / 20) is approximately 65 times slower as
the Math.pow() function.
Ether this is a bug or a javadoc comment is missing.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OGNL-8) use javacc to generate AST* java sources
[
https://issues.apache.org/jira/browse/OGNL-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi updated OGNL-8:
--
Attachment: OGNL-8.patch
Salut Olivier!
please review the attached patch; it is not complete at all but at least is a
helpful starting point, it plugs the necessary components to compile the jjt
grammar to generate the parser and then the Java classes (that I dropped from
the src dir).
As you can see, if you run {{mvn compile}} a lot of errors happen because,
during its history, generated classes by JavaCC have been versioned in the SCM
and modified.
Hope it helps, unfortunately I don't have enough knowledge ATM about JavaCC to
help more, to modify the grammar :(
Feel free to ping me directly if any help is needed!
use javacc to generate AST* java sources
Key: OGNL-8
URL: https://issues.apache.org/jira/browse/OGNL-8
Project: OGNL (Incubating)
Issue Type: Task
Reporter: Olivier Lamy
Assignee: Olivier Lamy
Attachments: OGNL-8.patch
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OGNL-8) use javacc to generate AST* and OGNLParser Java sources
[ https://issues.apache.org/jira/browse/OGNL-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi updated OGNL-8: -- Summary: use javacc to generate AST* and OGNLParser Java sources (was: use javacc to generate AST* java sources) use javacc to generate AST* and OGNLParser Java sources --- Key: OGNL-8 URL: https://issues.apache.org/jira/browse/OGNL-8 Project: OGNL (Incubating) Issue Type: Task Reporter: Olivier Lamy Assignee: Olivier Lamy Attachments: OGNL-8.patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-8) use javacc to generate AST* and OGNLParser Java sources
[ https://issues.apache.org/jira/browse/OGNL-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13035638#comment-13035638 ] Olivier Lamy commented on OGNL-8: - I have started this locally too. But AST* has been modified too much with *non grammar* related code ! use javacc to generate AST* and OGNLParser Java sources --- Key: OGNL-8 URL: https://issues.apache.org/jira/browse/OGNL-8 Project: OGNL (Incubating) Issue Type: Task Reporter: Olivier Lamy Assignee: Olivier Lamy Attachments: OGNL-8.patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-579) FastMath.pow much slower than Math.pow
[
https://issues.apache.org/jira/browse/MATH-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13035648#comment-13035648
]
Gilles commented on MATH-579:
-
{quote}
hosted application, in environments like [...] web servers, [...]
{quote}
From what I've just been reading, servlets are only reloaded when their
.class file has changed. And they refer to this as a feature (to allow code
to be modified without needing a server restart) but also as a hack (because
the usual class loader of the JVM does not do that)...
I don't know how Eclipse or Android works but I don't see why a class would be
reloaded inside a given application. For Android, the recompilation argument
doesn't even apply.
FastMath.pow much slower than Math.pow
--
Key: MATH-579
URL: https://issues.apache.org/jira/browse/MATH-579
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Environment: java version 1.6.0_22
OpenJDK Runtime Environment (IcedTea6 1.10.1) (6b22-1.10.1-0ubuntu1)
OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
java version 1.6.0_24
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
Reporter: Arne Plöse
Fix For: 3.0
calculating FastMath.pow(10, 0.1 / 20) is approximately 65 times slower as
the Math.pow() function.
Ether this is a bug or a javadoc comment is missing.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-122) Bug in ColognePhonetic.java
[ https://issues.apache.org/jira/browse/CODEC-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13035997#comment-13035997 ] Dominic Herrmann commented on CODEC-122: Sorry for waisting your time. You are rigth your code works correctly. The problem was I have got a beta version, not the version 1.5 of the jar. Only the beta version has this bug. The issue can be closed. Bug in ColognePhonetic.java --- Key: CODEC-122 URL: https://issues.apache.org/jira/browse/CODEC-122 Project: Commons Codec Issue Type: Bug Affects Versions: 1.5 Reporter: Dominic Herrmann During the use of org.apache.commons.codec.language.ColognePhonetic I recognized an error in method public String colognePhonetic(String text). The method does not handle the character 'J'. Thus Strings containig a J will not completely by calculated to the phonetic code. The characters 'J' will remain. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
