[jira] Issue Comment Edited: (MATH-545) Feature Request: RealVector cosine
[ 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
[ 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
[ 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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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()
[ 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()
[ 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
[ 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
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
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