[jira] Issue Comment Edited: (MATH-545) Feature Request: RealVector cosine

2011-03-10 Thread Benjamin McCann (JIRA)

[ 
https://issues.apache.org/jira/browse/MATH-545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005517#comment-13005517
 ] 

Benjamin McCann edited comment on MATH-545 at 3/11/11 6:36 AM:
---

I guess it's pretty simple, but it still might be nice as a convenience method:
{noformat} 
  public double cosine(double[] a1, double[] a2) {
ArrayRealVector v1 = new ArrayRealVector(a1);
ArrayRealVector v2 = new ArrayRealVector(a2);
return v1.dotProduct(v2) / (v1.getNorm() * v2.getNorm());
  }
{noformat}

  was (Author: bmccann):
I guess it's pretty simple, but it still might be nice as a convenience 
method:

public double cosine(double[] a1, double[] a2) {
  ArrayRealVector v1 = new ArrayRealVector(a1);
  ArrayRealVector v2 = new ArrayRealVector(a2);
  return v1.dotProduct(v2) / (v1.getNorm() * v2.getNorm());
}
  
> Feature Request: RealVector cosine
> --
>
> Key: MATH-545
> URL: https://issues.apache.org/jira/browse/MATH-545
> Project: Commons Math
>  Issue Type: New Feature
>Reporter: Benjamin McCann
>
> I'd like a method to compute the cosine similarity between vectors.
> http://en.wikipedia.org/wiki/Cosine_similarity

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] Issue Comment Edited: (MATH-545) Feature Request: RealVector cosine

2011-03-10 Thread Benjamin McCann (JIRA)

[ 
https://issues.apache.org/jira/browse/MATH-545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005517#comment-13005517
 ] 

Benjamin McCann edited comment on MATH-545 at 3/11/11 6:33 AM:
---

I guess it's pretty simple, but it still might be nice as a convenience method:

public double cosine(double[] a1, double[] a2) {
  ArrayRealVector v1 = new ArrayRealVector(a1);
  ArrayRealVector v2 = new ArrayRealVector(a2);
  return v1.dotProduct(v2) / (v1.getNorm() * v2.getNorm());
}

  was (Author: bmccann):
I guess it's pretty simple, but it still might be nice as a convenience 
method:
  public double cosine(double[] a1, double[] a2) {
ArrayRealVector v1 = new ArrayRealVector(a1);
ArrayRealVector v2 = new ArrayRealVector(a2);
return v1.dotProduct(v2) / (v1.getNorm() * v2.getNorm());
  }
  
> Feature Request: RealVector cosine
> --
>
> Key: MATH-545
> URL: https://issues.apache.org/jira/browse/MATH-545
> Project: Commons Math
>  Issue Type: New Feature
>Reporter: Benjamin McCann
>
> I'd like a method to compute the cosine similarity between vectors.
> http://en.wikipedia.org/wiki/Cosine_similarity

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] Commented: (MATH-545) Feature Request: RealVector cosine

2011-03-10 Thread Benjamin McCann (JIRA)

[ 
https://issues.apache.org/jira/browse/MATH-545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005517#comment-13005517
 ] 

Benjamin McCann commented on MATH-545:
--

I guess it's pretty simple, but it still might be nice as a convenience method:
  public double cosine(double[] a1, double[] a2) {
ArrayRealVector v1 = new ArrayRealVector(a1);
ArrayRealVector v2 = new ArrayRealVector(a2);
return v1.dotProduct(v2) / (v1.getNorm() * v2.getNorm());
  }

> Feature Request: RealVector cosine
> --
>
> Key: MATH-545
> URL: https://issues.apache.org/jira/browse/MATH-545
> Project: Commons Math
>  Issue Type: New Feature
>Reporter: Benjamin McCann
>
> I'd like a method to compute the cosine similarity between vectors.
> http://en.wikipedia.org/wiki/Cosine_similarity

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] Created: (MATH-545) Feature Request: RealVector cosine

2011-03-10 Thread Benjamin McCann (JIRA)
Feature Request: RealVector cosine
--

 Key: MATH-545
 URL: https://issues.apache.org/jira/browse/MATH-545
 Project: Commons Math
  Issue Type: New Feature
Reporter: Benjamin McCann


I'd like a method to compute the cosine similarity between vectors.
http://en.wikipedia.org/wiki/Cosine_similarity

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] Updated: (POOL-184) Premature starvation in GenericObjectPool when borrowObject() and evict() are executed concurrently

2011-03-10 Thread Phil Steitz (JIRA)

 [ 
https://issues.apache.org/jira/browse/POOL-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz updated POOL-184:
-

Summary: Premature starvation in GenericObjectPool when borrowObject() and 
evict() are executed concurrently  (was: Deadlock in GenericObjectPool. Between 
borrowObject() and evict())

> Premature starvation in GenericObjectPool when borrowObject() and evict() are 
> executed concurrently
> ---
>
> Key: POOL-184
> URL: https://issues.apache.org/jira/browse/POOL-184
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 1.5.5
> Environment: java 1.6.0_24
> Ubuntu 10.10
>Reporter: Adrian Nistor
> Attachments: Test01.java, stall.txt
>
>
> Hi,
> I am encountering a deadlock in GenericObjectPool. It appears in version 
> 1.5.5 
> and also in revision 1079385 (March 8th 2011).
> The deadlock manifests when calling borrowObject() and evict() in parallel. I 
> have inlined a test that exposes this problem. For this test, the expected 
> output is:
> Expected output:
> 0
> 1
> 2
> 3
> 4
> .
> 498
> 499
> DONE
> But when the bug manifests (almost always for this test), the output is:
> Bug output:
> 0
> 1
> 2
> 3
> 4
> When the bug manifests, the test does not finish, it just gets stuck after
> printing several values (in this run: 0 1 2 3 4, but in other runs may be
> 0 1 2 .. 18 or 0 1 2 or some other value).
> When the loop limit is small (e.g., 11 instead of 5000), the test does finish.
> Also, when running sequentially:
>  
> Pool.borrowObject();
> Pool.evict();
> or vice-versa
> Pool.evict();
> Pool.borrowObject();
> the test still finishes. 
> Is this a bug? Is there a patch for it?
> Thanks!
> Adrian
> 
> This test is for version 1.5.5. For revision 1079385 one should replace 
> setMaxActive() with setMaxTotal()
> 
> package org.apache.commons.pool.impl;
> import org.apache.commons.pool.PoolableObjectFactory;
> public class Test01 
> {
> public static void main(String[] args) throws Exception 
> {
> Test01 test = new Test01();
> test.test();
> }
> 
> SimpleFactory Factory = null;
> GenericObjectPool Pool = null;
> Object Obj = null;
> public void test() throws Exception 
> {
> Factory = new SimpleFactory();
> Pool = new GenericObjectPool(Factory);
> Pool.setMaxActive(1);
> Pool.addObject();
> 
> for(int i=0; i<5000; i++)
> {
> Thread one = new MyThread(1);
> Thread two = new MyThread(2);
> one.start();
> two.start();
> one.join();
> two.join();
> 
> Pool.returnObject(Obj);
> if(i%10==0)
> {
> System.out.println(i/10);
> }
> }
> System.out.println("DONE");
> }
> private class MyThread extends Thread 
> {
> int _tid;
> public MyThread(int tid) 
> {
> _tid = tid;
> }
> public void run() 
> {
> try 
> {
> if(_tid == 1) 
> {
> Obj = Pool.borrowObject();
> }
> if (_tid == 2) 
> {
> try
> {
> Pool.evict();
> } catch (Exception e) {}
> }
> } 
> catch(Exception e) 
> {
> throw new RuntimeException(e);
> }
> }
> }
> private class SimpleFactory implements PoolableObjectFactory
> {
> public SimpleFactory() {}
> public Object makeObject() { return new String("testing"); }
> public void destroyObject(Object obj) {}
> public boolean validateObject(Object obj) {return true;}
> public void activateObject(Object obj) throws Exception {}
> public void passivateObject(Object obj) throws Exception {}
> public boolean isThrowExceptionOnActivate() {return true;}
> }
> }
> 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] Commented: (LANG-686) StringUtils.replaceEachRepeatedly("aaa", new String[]{"aa"}, new String[]{"aXa"}); throw an exception

2011-03-10 Thread qed (JIRA)

[ 
https://issues.apache.org/jira/browse/LANG-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005226#comment-13005226
 ] 

qed commented on LANG-686:
--

I solved this problem by making this call instead:

StringUtils.replaceEachRepeatedly("aaa", new String[]{"aa", ""}, new 
String[]{"aXa", ""});

Maybe there should be a limit to number of iterations or something similar. I 
didn't know that this function is not supposed to support recursion. I think 
this function is good suited when (java) regex fail in matching already 
replaced part of string and hence it shouldn't be dicouraged to use this 
function as a solution imho.

> StringUtils.replaceEachRepeatedly("aaa", new String[]{"aa"}, new 
> String[]{"aXa"}); throw an exception
> -
>
> Key: LANG-686
> URL: https://issues.apache.org/jira/browse/LANG-686
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.*
>Affects Versions: 2.6
> Environment: jdk 1.6.24, windows xp pro sp3, eclipse helios
>Reporter: qed
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> After executing line
> StringUtils.replaceEachRepeatedly("aaa", new String[]{"aa"}, new 
> String[]{"aXa"});
> exception is thrown:
> Exception in thread "main" java.lang.IllegalStateException: TimeToLive of -1 
> is less than 0: aXaXa
>   at 
> org.apache.commons.lang.StringUtils.replaceEach(StringUtils.java:3986)
>   at 
> org.apache.commons.lang.StringUtils.replaceEach(StringUtils.java:4099)
>   at 
> org.apache.commons.lang.StringUtils.replaceEach(StringUtils.java:4099)
>   at 
> org.apache.commons.lang.StringUtils.replaceEachRepeatedly(StringUtils.java:3920)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] Commented: (NET-326) A KeyManager is required when the protection level is set to 'P' with FTPSClient on active mode

2011-03-10 Thread Sebb (JIRA)

[ 
https://issues.apache.org/jira/browse/NET-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005151#comment-13005151
 ] 

Sebb commented on NET-326:
--

Would there be any point in including the SSLContext setup code in NET? e.g. in 
a utility module.
Or is it too specific to the SSL protocol?

> A KeyManager is required when the protection level is set to 'P' with 
> FTPSClient on active mode
> ---
>
> Key: NET-326
> URL: https://issues.apache.org/jira/browse/NET-326
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 2.0
> Environment: Windows XP profesional service pack 2, Java Java 
> 1.6.0_12-b04 
>Reporter: Terence Dudouit
>
> Using a simple FTPS client that list a directory, when execPROT("P") is set 
> and the active mode is on, the following exception is thrown :
> javax.net.ssl.SSLException: No available certificate or key corresponds to 
> the SSL cipher suites which are enabled.
>   at 
> com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:303)
>   at 
> com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:253)
>   at 
> org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:489)
>   at 
> org.apache.commons.net.ftp.FTPSClient._openDataConnection_(FTPSClient.java:494)
>   at org.apache.commons.net.ftp.FTPClient.listNames(FTPClient.java:1950)
>   at org.apache.commons.net.ftp.FTPClient.listNames(FTPClient.java:1996)
>   at 
> fr.enovacom.eai.actions.dynamiques.protocole.ftp.FTPGet.testFTPS(FTPGet.java:379)
>   at 
> fr.enovacom.eai.actions.dynamiques.protocole.ftp.FTPGet.main(FTPGet.java:401)
> This doesn't occur on passive mode.
> The only way to make it work is to set a keyManager although there is no need 
> for a client authentication.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] Resolved: (NET-327) "Unconnected sockets not implemented" when using FTPSClient

2011-03-10 Thread Sebb (JIRA)

 [ 
https://issues.apache.org/jira/browse/NET-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb resolved NET-327.
--

   Resolution: Fixed
Fix Version/s: 3.0

Thanks again.

Solution looks good, committed to SVN.

> "Unconnected sockets not implemented" when using FTPSClient
> ---
>
> Key: NET-327
> URL: https://issues.apache.org/jira/browse/NET-327
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 2.0
> Environment: Windows XP SP3, Java 1.6.0_18, Apache Karaf 1.6.0
>Reporter: Bengt Rodehav
> Fix For: 3.0
>
> Attachments: ftps-reconn.diff
>
>
> I'm using Apache Camel as an integration platform. Specifically, at the 
> moment, I depend on the ftp/ftps/sftp support in the camel-ftp component. 
> Under the hood Camel uses Commons Net for ftp and ftps support.
> Recently, the camel-ftp component was enhanced (on my request) with the 
> possibility to use a secure data channel. This is accomplished by using the 
> execProt() (and execPsbz()) method in class FTPSClient.
> However, later on (in case Camel needs to reconnect), one of the connect() 
> methods in the base class to FTPSClient is called. Unfortunately all the 
> connect methods first create an unconnected socket and then tries to connect 
> it. The connection factory now associated with the FTPSClient then throws an 
> exception stating: "Unconnected sockets not implemented".
> It seems like the FTPSClient does not support "re-connect" once it has 
> entered secure communications mode.
> See also: http://www.mail-archive.com/user@commons.apache.org/msg04933.html
> and http://www.mail-archive.com/users@camel.apache.org/msg08732.html

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] Commented: (LANG-686) StringUtils.replaceEachRepeatedly("aaa", new String[]{"aa"}, new String[]{"aXa"}); throw an exception

2011-03-10 Thread Maurizio Cucchiara (JIRA)

[ 
https://issues.apache.org/jira/browse/LANG-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005142#comment-13005142
 ] 

Maurizio Cucchiara commented on LANG-686:
-

I'm not sure this is a bug. The IllegalStateException was throwned because your 
substitution pattern triggers a (though little) recursion, it's a kind of 
prevention, in order to avoid StackOverflowError

> StringUtils.replaceEachRepeatedly("aaa", new String[]{"aa"}, new 
> String[]{"aXa"}); throw an exception
> -
>
> Key: LANG-686
> URL: https://issues.apache.org/jira/browse/LANG-686
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.*
>Affects Versions: 2.6
> Environment: jdk 1.6.24, windows xp pro sp3, eclipse helios
>Reporter: qed
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> After executing line
> StringUtils.replaceEachRepeatedly("aaa", new String[]{"aa"}, new 
> String[]{"aXa"});
> exception is thrown:
> Exception in thread "main" java.lang.IllegalStateException: TimeToLive of -1 
> is less than 0: aXaXa
>   at 
> org.apache.commons.lang.StringUtils.replaceEach(StringUtils.java:3986)
>   at 
> org.apache.commons.lang.StringUtils.replaceEach(StringUtils.java:4099)
>   at 
> org.apache.commons.lang.StringUtils.replaceEach(StringUtils.java:4099)
>   at 
> org.apache.commons.lang.StringUtils.replaceEachRepeatedly(StringUtils.java:3920)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] Updated: (NET-327) "Unconnected sockets not implemented" when using FTPSClient

2011-03-10 Thread Bogdan Drozdowski (JIRA)

 [ 
https://issues.apache.org/jira/browse/NET-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bogdan Drozdowski updated NET-327:
--

Attachment: ftps-reconn.diff

A code sample would be nice. But I've managed to do my own: executing the 
sequence "connect, execPROT(P), login, disconnect" twice on the same client 
instance causes the error. My patch fixes this issue - it overrides the 
disconnect() method of FTPClient in FTPSClient to re-set the SocketFactories 
(null is allowed, because the SocketClient knows how to deal with it). Thanks 
goes to Bengt Rodehav 
(http://www.mail-archive.com/user@commons.apache.org/msg04935.html) for 
pointing this out.

> "Unconnected sockets not implemented" when using FTPSClient
> ---
>
> Key: NET-327
> URL: https://issues.apache.org/jira/browse/NET-327
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 2.0
> Environment: Windows XP SP3, Java 1.6.0_18, Apache Karaf 1.6.0
>Reporter: Bengt Rodehav
> Attachments: ftps-reconn.diff
>
>
> I'm using Apache Camel as an integration platform. Specifically, at the 
> moment, I depend on the ftp/ftps/sftp support in the camel-ftp component. 
> Under the hood Camel uses Commons Net for ftp and ftps support.
> Recently, the camel-ftp component was enhanced (on my request) with the 
> possibility to use a secure data channel. This is accomplished by using the 
> execProt() (and execPsbz()) method in class FTPSClient.
> However, later on (in case Camel needs to reconnect), one of the connect() 
> methods in the base class to FTPSClient is called. Unfortunately all the 
> connect methods first create an unconnected socket and then tries to connect 
> it. The connection factory now associated with the FTPSClient then throws an 
> exception stating: "Unconnected sockets not implemented".
> It seems like the FTPSClient does not support "re-connect" once it has 
> entered secure communications mode.
> See also: http://www.mail-archive.com/user@commons.apache.org/msg04933.html
> and http://www.mail-archive.com/users@camel.apache.org/msg08732.html

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] Commented: (NET-326) A KeyManager is required when the protection level is set to 'P' with FTPSClient on active mode

2011-03-10 Thread Bogdan Drozdowski (JIRA)

[ 
https://issues.apache.org/jira/browse/NET-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005100#comment-13005100
 ] 

Bogdan Drozdowski commented on NET-326:
---

Terence, you didn't show us:
* your code
* the way you're running your code
* the server's configuration.

Since you're saying that a KeyManager is required, I'm guessing that the FTP 
server connecting to you in active mode as a "client" requires you to provide 
your certificate/key. Since there's no default certificate, the connection 
fails. If this is true, then to reproduce this (if anyone's interested):
* install vsftpd (the easiest, I guess) and set in the config file:
** require_ssl_reuse=no
** ssl_enable=yes
** ssl_sslv3=yes
** ssl_tlsv1=yes
** rsa_cert_file=/path/to/your_certificate_and_key_file
** ssl_request_cert=yes
** require_cert=yes
* run the following code:
{code}
FTPSClient c = new FTPSClient ();
c.connect ("127.0.0.1", 21);
c.enterLocalActiveMode();
System.out.println (c.getReplyString());
c.login ("login", "password");

System.out.println (c.getReplyString());
c.execPROT ("P");
System.out.println (c.getReplyString());
String[] names = c.listNames();
{code}

Now, to the point: for this to work automatically, the FTPSClient class would 
have to have all the possible key/certificates. Because of the number of these, 
this is impossible to have. The solution is the FTPSClient constructor with the 
SSLContext parameter. A quick search on the Web (with the errors as the search 
term) made me produce the following code:
{code}
private static X509TrustManager s_x509TrustManager;
static {
s_x509TrustManager = new X509TrustManager() {
public java.security.cert.X509Certificate[] getAcceptedIssuers() {
return new java.security.cert.X509Certificate[] {}; }
public boolean isClientTrusted(java.security.cert.X509Certificate[] 
chain) { return true; }
public boolean isServerTrusted(java.security.cert.X509Certificate[] 
chain) { return true; }
public void checkServerTrusted(java.security.cert.X509Certificate[] 
certificates, String authType)
{}
public void checkClientTrusted(java.security.cert.X509Certificate[] 
certificates, String authType) {}
};
}

private static void testFTPS () throws Exception
{
SSLContext ctx;
KeyManagerFactory kmf;
KeyStore ks;
char[] passphrase = "aa".toCharArray();

ctx = SSLContext.getInstance("TLS");
kmf = KeyManagerFactory.getInstance("SunX509");
ks = KeyStore.getInstance("JKS");

ks.load(new FileInputStream("keystore"), passphrase);

kmf.init(ks, passphrase);
ctx.init(kmf.getKeyManagers(), new X509TrustManager[] 
{s_x509TrustManager}, null);

FTPSClient c = new FTPSClient (ctx);
c.connect ("127.0.0.1", 21);
c.enterLocalActiveMode();
System.out.println (c.getReplyString());
c.login ("login", "password");

System.out.println (c.getReplyString());
c.execPROT ("P");
System.out.println (c.getReplyString());
String[] names = c.listNames();
}
{code}
This code *works* when connecting to *the same* vsftpd server as before (when 
the previous code caused an exception). To run this code, add the following 
command-line options to "java" (don't know if still required actually, but 
won't hurt):
* -Djavax.net.ssl.trustStore=truststore
* -Djavax.net.ssl.trustStorePassword=aa

Please read the [JSSE Reference 
Guide|http://download.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html],
 especially the "Code Examples" section. That's where I got most of the 
information I needed (especially about creating the keystores in files: 
"keystore" used by the code, and "truststore" used on the command-line). I 
think that only a certificate for "localhost" is required, but just in case, 
I've also added a certificate for my hostname in the keystores.

Furthermore, if there's a KeyManager missing, you can always install your own 
with the FTPSClient.setKeyManager method.

> A KeyManager is required when the protection level is set to 'P' with 
> FTPSClient on active mode
> ---
>
> Key: NET-326
> URL: https://issues.apache.org/jira/browse/NET-326
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 2.0
> Environment: Windows XP profesional service pack 2, Java Java 
> 1.6.0_12-b04 
>Reporter: Terence Dudouit
>
> Using a simple FTPS client that list a directory, when execPROT("P") is set 
> and the active mode is on, the following exception is thrown :
> javax.net.ssl.SSLException: No available certificate or key corresponds to 
> the SSL cipher suites which are enabled.
>   at 
> com.sun.net.

[jira] Updated: (POOL-184) Deadlock in GenericObjectPool. Between borrowObject() and evict()

2011-03-10 Thread Phil Steitz (JIRA)

 [ 
https://issues.apache.org/jira/browse/POOL-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz updated POOL-184:
-

Attachment: stall.txt

Thread dump during stalled execution of TestO1.java

> Deadlock in GenericObjectPool. Between borrowObject() and evict()
> -
>
> Key: POOL-184
> URL: https://issues.apache.org/jira/browse/POOL-184
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 1.5.5
> Environment: java 1.6.0_24
> Ubuntu 10.10
>Reporter: Adrian Nistor
> Attachments: Test01.java, stall.txt
>
>
> Hi,
> I am encountering a deadlock in GenericObjectPool. It appears in version 
> 1.5.5 
> and also in revision 1079385 (March 8th 2011).
> The deadlock manifests when calling borrowObject() and evict() in parallel. I 
> have inlined a test that exposes this problem. For this test, the expected 
> output is:
> Expected output:
> 0
> 1
> 2
> 3
> 4
> .
> 498
> 499
> DONE
> But when the bug manifests (almost always for this test), the output is:
> Bug output:
> 0
> 1
> 2
> 3
> 4
> When the bug manifests, the test does not finish, it just gets stuck after
> printing several values (in this run: 0 1 2 3 4, but in other runs may be
> 0 1 2 .. 18 or 0 1 2 or some other value).
> When the loop limit is small (e.g., 11 instead of 5000), the test does finish.
> Also, when running sequentially:
>  
> Pool.borrowObject();
> Pool.evict();
> or vice-versa
> Pool.evict();
> Pool.borrowObject();
> the test still finishes. 
> Is this a bug? Is there a patch for it?
> Thanks!
> Adrian
> 
> This test is for version 1.5.5. For revision 1079385 one should replace 
> setMaxActive() with setMaxTotal()
> 
> package org.apache.commons.pool.impl;
> import org.apache.commons.pool.PoolableObjectFactory;
> public class Test01 
> {
> public static void main(String[] args) throws Exception 
> {
> Test01 test = new Test01();
> test.test();
> }
> 
> SimpleFactory Factory = null;
> GenericObjectPool Pool = null;
> Object Obj = null;
> public void test() throws Exception 
> {
> Factory = new SimpleFactory();
> Pool = new GenericObjectPool(Factory);
> Pool.setMaxActive(1);
> Pool.addObject();
> 
> for(int i=0; i<5000; i++)
> {
> Thread one = new MyThread(1);
> Thread two = new MyThread(2);
> one.start();
> two.start();
> one.join();
> two.join();
> 
> Pool.returnObject(Obj);
> if(i%10==0)
> {
> System.out.println(i/10);
> }
> }
> System.out.println("DONE");
> }
> private class MyThread extends Thread 
> {
> int _tid;
> public MyThread(int tid) 
> {
> _tid = tid;
> }
> public void run() 
> {
> try 
> {
> if(_tid == 1) 
> {
> Obj = Pool.borrowObject();
> }
> if (_tid == 2) 
> {
> try
> {
> Pool.evict();
> } catch (Exception e) {}
> }
> } 
> catch(Exception e) 
> {
> throw new RuntimeException(e);
> }
> }
> }
> private class SimpleFactory implements PoolableObjectFactory
> {
> public SimpleFactory() {}
> public Object makeObject() { return new String("testing"); }
> public void destroyObject(Object obj) {}
> public boolean validateObject(Object obj) {return true;}
> public void activateObject(Object obj) throws Exception {}
> public void passivateObject(Object obj) throws Exception {}
> public boolean isThrowExceptionOnActivate() {return true;}
> }
> }
> 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] Commented: (POOL-184) Deadlock in GenericObjectPool. Between borrowObject() and evict()

2011-03-10 Thread Phil Steitz (JIRA)

[ 
https://issues.apache.org/jira/browse/POOL-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005085#comment-13005085
 ] 

Phil Steitz commented on POOL-184:
--

Thanks for reporting this and thanks especially for providing a test case.  I 
am attaching a thread dump during a stalled execution.

I think what is going on here is not deadlock, but inappropriate starvation.  
With maxActive set to 1 (or whenever maxActive is about to be attained by a 
borrowObject with one idle instance in the pool), if one thread does a borrow 
while the evictor is visiting the idle instance, the borrowing thread will 
stall until another thread does a borrow or return.  When there is only one 
active thread, this will never happen, so the test program stalls.

If my analysis is correct, this is a bug, which is caused by the fact that 
evict() temporarily removes idle instances being examined, but does not call 
allocate() when it returns them.  The stall here happens when the borrowing 
thread makes its request when evict is examining the idle instance.  It never 
gets notified when the instance is returned to the pool. 

A simple fix is to insert an allocate() at the end of evict().  We need to 
verify though that this will not cause any other problems.

> Deadlock in GenericObjectPool. Between borrowObject() and evict()
> -
>
> Key: POOL-184
> URL: https://issues.apache.org/jira/browse/POOL-184
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 1.5.5
> Environment: java 1.6.0_24
> Ubuntu 10.10
>Reporter: Adrian Nistor
> Attachments: Test01.java
>
>
> Hi,
> I am encountering a deadlock in GenericObjectPool. It appears in version 
> 1.5.5 
> and also in revision 1079385 (March 8th 2011).
> The deadlock manifests when calling borrowObject() and evict() in parallel. I 
> have inlined a test that exposes this problem. For this test, the expected 
> output is:
> Expected output:
> 0
> 1
> 2
> 3
> 4
> .
> 498
> 499
> DONE
> But when the bug manifests (almost always for this test), the output is:
> Bug output:
> 0
> 1
> 2
> 3
> 4
> When the bug manifests, the test does not finish, it just gets stuck after
> printing several values (in this run: 0 1 2 3 4, but in other runs may be
> 0 1 2 .. 18 or 0 1 2 or some other value).
> When the loop limit is small (e.g., 11 instead of 5000), the test does finish.
> Also, when running sequentially:
>  
> Pool.borrowObject();
> Pool.evict();
> or vice-versa
> Pool.evict();
> Pool.borrowObject();
> the test still finishes. 
> Is this a bug? Is there a patch for it?
> Thanks!
> Adrian
> 
> This test is for version 1.5.5. For revision 1079385 one should replace 
> setMaxActive() with setMaxTotal()
> 
> package org.apache.commons.pool.impl;
> import org.apache.commons.pool.PoolableObjectFactory;
> public class Test01 
> {
> public static void main(String[] args) throws Exception 
> {
> Test01 test = new Test01();
> test.test();
> }
> 
> SimpleFactory Factory = null;
> GenericObjectPool Pool = null;
> Object Obj = null;
> public void test() throws Exception 
> {
> Factory = new SimpleFactory();
> Pool = new GenericObjectPool(Factory);
> Pool.setMaxActive(1);
> Pool.addObject();
> 
> for(int i=0; i<5000; i++)
> {
> Thread one = new MyThread(1);
> Thread two = new MyThread(2);
> one.start();
> two.start();
> one.join();
> two.join();
> 
> Pool.returnObject(Obj);
> if(i%10==0)
> {
> System.out.println(i/10);
> }
> }
> System.out.println("DONE");
> }
> private class MyThread extends Thread 
> {
> int _tid;
> public MyThread(int tid) 
> {
> _tid = tid;
> }
> public void run() 
> {
> try 
> {
> if(_tid == 1) 
> {
> Obj = Pool.borrowObject();
> }
> if (_tid == 2) 
> {
> try
> {
> Pool.evict();
> } catch (Exception e) {}
> }
> } 
> catch(Exception e) 
> {
> throw new RuntimeException(e);
> }
> }
> }
> private class SimpleFactory implements PoolableObjectFactory
> {
> public SimpleFactory() {}
> public Object makeObject() { return new St

[jira] Commented: (MATH-542) Allow the addition of multiple messages to the exceptions generated by CM

2011-03-10 Thread Gilles (JIRA)

[ 
https://issues.apache.org/jira/browse/MATH-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005071#comment-13005071
 ] 

Gilles commented on MATH-542:
-

"readObject" and "writeObject" methods implemented (revision 1080231), 
following Jörg's suggestion on the ML.


> Allow the addition of multiple messages to the exceptions generated by CM
> -
>
> Key: MATH-542
> URL: https://issues.apache.org/jira/browse/MATH-542
> Project: Commons Math
>  Issue Type: New Feature
>Reporter: Gilles
>Assignee: Gilles
>Priority: Minor
>  Labels: api-change
> Fix For: 3.0
>
>
> Borrowing on the idea of "ExceptionContext" implemented in [Lang], 
> "MathRuntimeException" (base class of all exceptions generated from CM) will 
> be enhanced so that an unlimited number of (localized) messages can be added 
> to an exception object.
> The "MathThrowable" interface (implemented by "MathRuntimeException") will 
> contain the following new method:
> {code}
> /**
>   * Sets a message.
>   *
>   * @param pattern Message pattern.
>   * @param arguments Values for replacing the placeholders in the message
>   * pattern.
>   */
>   public void addMessage(Localizable pattern,
>  Object ... arguments);
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] Created: (LANG-686) StringUtils.replaceEachRepeatedly("aaa", new String[]{"aa"}, new String[]{"aXa"}); throw an exception

2011-03-10 Thread qed (JIRA)
StringUtils.replaceEachRepeatedly("aaa", new String[]{"aa"}, new 
String[]{"aXa"}); throw an exception
-

 Key: LANG-686
 URL: https://issues.apache.org/jira/browse/LANG-686
 Project: Commons Lang
  Issue Type: Bug
  Components: lang.*
Affects Versions: 2.6
 Environment: jdk 1.6.24, windows xp pro sp3, eclipse helios
Reporter: qed


After executing line

StringUtils.replaceEachRepeatedly("aaa", new String[]{"aa"}, new 
String[]{"aXa"});

exception is thrown:

Exception in thread "main" java.lang.IllegalStateException: TimeToLive of -1 is 
less than 0: aXaXa
at 
org.apache.commons.lang.StringUtils.replaceEach(StringUtils.java:3986)
at 
org.apache.commons.lang.StringUtils.replaceEach(StringUtils.java:4099)
at 
org.apache.commons.lang.StringUtils.replaceEach(StringUtils.java:4099)
at 
org.apache.commons.lang.StringUtils.replaceEachRepeatedly(StringUtils.java:3920)



--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] Created: (IO-264) FileUtils.moveFile() JavaDoc should specify FileExistsException thrown

2011-03-10 Thread JIRA
FileUtils.moveFile() JavaDoc should specify FileExistsException thrown
--

 Key: IO-264
 URL: https://issues.apache.org/jira/browse/IO-264
 Project: Commons IO
  Issue Type: Bug
  Components: Utilities
Affects Versions: 2.0
Reporter: Maciej Biłas
Priority: Trivial


FileUtils.moveFile() JavaDoc does specify the behaviour of the method in a case 
when the destFile exists. It would be helpful to know from the JavaDoc that in 
such case an exception is thrown as it's not immediately obvious.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira