[jira] [Commented] (MATH-581) Support for iterative linear solvers
[ https://issues.apache.org/jira/browse/MATH-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13054851#comment-13054851 ] Luc Maisonobe commented on MATH-581: I also think MathJax is very interesting, and I have seen another taglet about this here: [http://chadretz.wordpress.com/2010/12/19/mathml-inside-javadoc-using-mathjax-and-a-custom-taglet/]. However I don't think we can use it. MathJax is really really large (git clone is 163 Mbytes) so distributing it would be really cumbersome. It is distributed under the terms of the Apache 2 licence, by the way. It can be used from an external server through a Content Distribution Frameworl. This would imply we rely on a service outside from the Apache infrastructure which is frowned upon. The terms of service of this CDN can be also changed at will without notice and stopped by MathJax sponsors. The last way would be to have MathJax installed on Apache servers and not distributed in the Apache Commons Math component. I don't know if this would prevent or not people to build and use the javadoc without links to Apache (say when they are on a secured network not connected to Internet). If this is possible, we should open a dedicated JIRA issue for this. If this is not possible (i.e. javadoc could not be rendered without access to the MathJax resources), then we cannot ue it. Support for iterative linear solvers Key: MATH-581 URL: https://issues.apache.org/jira/browse/MATH-581 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0, Nightly Builds Reporter: Sébastien Brisard Labels: iterative, linear, solver Attachments: MATH-581-01.patch, linearoperator.zip Dear all, this issue has already been discussed on the forum. The idea is to implement the most popular linear iterative solvers (CG, SYMMLQ, etc...) in commons-math. The beauty of these solvers is that they do not need direct access to the coefficients of the matrix, only matrix-vector products are necessary. This is goof, as sometimes it is inetficient to store the coefficients of the matrix. So basically, before implementing the iterative solvers, we need to define an interface slightly more general than a matrix, namely LinearOperator, with only one basic operation: matrix-vector product. Here are a few interfaces and abstract classes that do that. Nothing fancy yet, I just wanted to have you advice on the implementation before I commit some solvers. I thought these classes could go in a package org.apache.commons.math.linearoperator, but really, I haven't got a clue... Best regards, Sebastien -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-581) Support for iterative linear solvers
[
https://issues.apache.org/jira/browse/MATH-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13054862#comment-13054862
]
Sébastien Brisard commented on MATH-581:
As for my taglet, the idea is to embed a little piece of javascript in order to
render the mathml code in a html page (instead of xhtml). So it is very (very)
lightweight, with two drawbacks
* portability : the javascript code would be different for every single browser
(tested on firefox for the moment)
* file management : each equation must be kept in a separate file : this is not
a big concern, all files are stored in the {{doc-files/}} directory. I also
have implemented a taglet called {{@inlineMathML}}, where the MathML code is
typed directly in the {{*.java}} file, but it applies only to very small
formulae, since the source file gets very quickly blotted. Anyway, as I said,
I'm very happy to contribute this code if you think it can be of any use. We
can start a new JIRA ticket on this.
I think I kind of agree with Gilles' point of view on javadoc sticking with
ASCII. However, the code I develop at work is numerically oriented, and I do
not have enough time to write both a thorough Javadoc *and* a math-oriented
doc. So I decided to go for a detailed Javadoc, with MathML formulas.
BTW, I only used a tip found
[here|https://developer.mozilla.org/en/Mozilla_MathML_Project/Authoring]. I
remember having found on the internet the corresponding code for IE.
Support for iterative linear solvers
Key: MATH-581
URL: https://issues.apache.org/jira/browse/MATH-581
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0, Nightly Builds
Reporter: Sébastien Brisard
Labels: iterative, linear, solver
Attachments: MATH-581-01.patch, linearoperator.zip
Dear all,
this issue has already been discussed on the forum. The idea is to implement
the most popular linear iterative solvers (CG, SYMMLQ, etc...) in
commons-math. The beauty of these solvers is that they do not need direct
access to the coefficients of the matrix, only matrix-vector products are
necessary. This is goof, as sometimes it is inetficient to store the
coefficients of the matrix.
So basically, before implementing the iterative solvers, we need to define an
interface slightly more general than a matrix, namely LinearOperator, with
only one basic operation: matrix-vector product.
Here are a few interfaces and abstract classes that do that. Nothing fancy
yet, I just wanted to have you advice on the implementation before I commit
some solvers.
I thought these classes could go in a package
org.apache.commons.math.linearoperator, but really, I haven't got a clue...
Best regards,
Sebastien
--
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=13054937#comment-13054937
]
Bogdan Drozdowski commented on NET-408:
---
I finally got some time to look at this. I confirm the problem exists when
connecting by IP in both active and passive mode to ProFTPd 1.3.3e. I confirm
the sessions are different for the control and data connections (as per
.toString()) despite using one SSLContext everywhere. Disabling session
creating in server sockets or disabling client mode in them doesn't help.
I looked more closely at the JSSE Reference and yes, you can reuse sessions,
but the only way you can do it is by passing the same host and port to the
SSLEngine creation methods. These don't need to be the actual host and port
you're connecting to (luckily) - they're just a marker or connection
identifier. The first bad news is that these are just a hint, so the
implementation might just as well ignore these and always create new SSL
sessions. The second bad news is that you can't use an SSLEngine anywhere. You
can't create contexts or sockets with it. The only thing you can do is creating
your own subset of TLS implementation for your needs, just like in the example
in the JSSE Reference Guide - you check message types, wrap and unwrap them
etc. Just creating an SSLEngine from an SSLContext doesn't work, you have to
use it.
Now better news that I've found: the PureTLS library
(http://www.rtfm.com/puretls/) seems to do it in an easier way - you specify
the host and port in the constructors and they're used to find sessions, so
re-using sessions looks possible. The drawback is that the whole FTPSClient
would have to be re-written to use this library and a new project dependency
would have to be introduced, not to mention that PureTLS may not be as secure
as the original SSL code in the JRE. There also is ftp4j, but it doesn't semm
to do more that the Commons-Net FTP Client in terms of SSL.
The whole SSL stuff is so wrapped in Java that you can't access the details and
you don't have full control over what's being done unless you write your own
implementation.
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
[jira] [Commented] (POOL-161) ContextClassLoader problems for the Evictor thread
[ https://issues.apache.org/jira/browse/POOL-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13055006#comment-13055006 ] Craig Ringer commented on POOL-161: --- This has been biting me rather severely. It's not only a classloader leak because, by leaking the classloader it can become impossible to unload huge parts of the web application because so many Java libraries like to keep static caches. Mark Thomas: It's not correct to state that having each app use its own copy of commons-pool will fix the issue. In fact, I encountered the issue precisely *because* my app deploys its own copy of commons-pool. I landed up with a timer thread used by commons-pool in a ThreadGroup owned by the app server. The timer thread holds a reference to my classloader via contextClassLoader, so my app's classloader cannot be unloaded. An effective workaround appears to be to move apache commons pool into the application server's set of provided classes. For Glassfish, that's glassfish/domains/domain1/lib . ContextClassLoader problems for the Evictor thread -- Key: POOL-161 URL: https://issues.apache.org/jira/browse/POOL-161 Project: Commons Pool Issue Type: Bug Affects Versions: 1.5.4 Reporter: Sylvain Laurent Fix For: 2.0 Attachments: TestGenericObjectPoolClassLoader.patch.txt, patch_Evictor_CCL.txt Since a single Timer is used for several GenericObjectPool instances, this may create classloader issues and a memory leak of one classloader : Let's imagine the following scenario : - commons-pool.jar is in the classpath of a webapp container (e.g. tomcat). - 2 webapps A and B are deployed, each creating an instance of GenericObjectPool for its own usage. - each webapp makes use of the idle object evictor and sets a positive number for minIdle - first, webapp A instantiates its GenericObjectPool. Since this is the first TimerTask to be created, the Timer instance is created, thus creating a Thread whose ContextClassLoader is the current one, that is webapp A's ContextClassLoader. The TimerTask properly creates instances of idle objects in the pool, making use of the ObjectFactory provided by A. - then B instantiates its GenericObjectPool. A new TimerTask is created, and it tries to invoke the ObjectFactory provided by B. But when it needs a class that only exists in B webapp, it cannot find it because the ContextClassLoader of the Timer Thread is A's classloader. Other side effect : if webapp A is undeployed, but B is still running, then A's webappClassLoader cannot be GCed because the Timer Thread keeps a strong reference to A's classloader (as its context classloader). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
