[jira] [Commented] (NET-606) Thread hangs when invoke connect method

2017-01-06 Thread zhengweixiong (JIRA) 

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

zhengweixiong commented on NET-606:
---

is this an issue on 2.2. if yes. anyone knows which version can solved this.

> Thread hangs when invoke connect method
> ---
>
> Key: NET-606
> URL: https://issues.apache.org/jira/browse/NET-606
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 2.2
>Reporter: zhengweixiong
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> ftp hangs when trying connect. stack as follows. 
> {noformat}
> "UpdateBrowSerParam" #633 prio=5 os_prio=0 tid=0x7f60610cc000 nid=0x2165 
> runnable [0x7f6037403000]
>java.lang.Thread.State: RUNNABLE
>   at java.net.SocketInputStream.socketRead0(Native Method)
>   at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
>   at java.net.SocketInputStream.read(SocketInputStream.java:170)
>   at java.net.SocketInputStream.read(SocketInputStream.java:141)
>   at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
>   at sun.security.ssl.InputRecord.read(InputRecord.java:503)
>   at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
>   - locked <0x0006d44fdd70> (a java.lang.Object)
>   at 
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
>   - locked <0x0006d44fdda0> (a java.lang.Object)
>   at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
>   at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
>   at 
> org.apache.commons.net.ftp.FTPSClient.sslNegotiation(FTPSClient.java:263)
>   at 
> org.apache.commons.net.ftp.FTPSClient._connectAction_(FTPSClient.java:192)
>   at org.apache.commons.net.SocketClient.connect(SocketClient.java:164)
>   at org.apache.commons.net.SocketClient.connect(SocketClient.java:184)
>   at 
> com.swimap.prs.utils.ftp.FTPSTransfer.initFTPSClient(FTPSTransfer.java:96)
>   at 
> com.swimap.prs.utils.ftp.FTPSTransfer.initFtpsClient(FTPSTransfer.java:336)
>   at com.swimap.prs.utils.ftp.FTPSTransfer.upload(FTPSTransfer.java:236)
>   at 
> com.swimap.prs.application.paimgr.session.impl.TransferFileService.uploadFile(TransferFileService.java:57)
> {noformat}
> this issue happen sometimes when the other times is ok.
> code as follows:
> {code}
> ftps = new FTPSClient("TLSv1.2", true);
> ftps.setConnectTimeout(1);
> ftps.setDataTimeout(2);
> ftps.setControlEncoding("UTF-8");
> ftps.connect(ftpServerInfo.getIp());
> ftps.setSoTimeout(2);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NET-606) Thread hangs when invoke connect method

2017-01-06 Thread zhengweixiong (JIRA) 

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

zhengweixiong commented on NET-606:
---

I'm using 2.2

> Thread hangs when invoke connect method
> ---
>
> Key: NET-606
> URL: https://issues.apache.org/jira/browse/NET-606
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 2.2
>Reporter: zhengweixiong
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> ftp hangs when trying connect. stack as follows. 
> {noformat}
> "UpdateBrowSerParam" #633 prio=5 os_prio=0 tid=0x7f60610cc000 nid=0x2165 
> runnable [0x7f6037403000]
>java.lang.Thread.State: RUNNABLE
>   at java.net.SocketInputStream.socketRead0(Native Method)
>   at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
>   at java.net.SocketInputStream.read(SocketInputStream.java:170)
>   at java.net.SocketInputStream.read(SocketInputStream.java:141)
>   at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
>   at sun.security.ssl.InputRecord.read(InputRecord.java:503)
>   at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
>   - locked <0x0006d44fdd70> (a java.lang.Object)
>   at 
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
>   - locked <0x0006d44fdda0> (a java.lang.Object)
>   at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
>   at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
>   at 
> org.apache.commons.net.ftp.FTPSClient.sslNegotiation(FTPSClient.java:263)
>   at 
> org.apache.commons.net.ftp.FTPSClient._connectAction_(FTPSClient.java:192)
>   at org.apache.commons.net.SocketClient.connect(SocketClient.java:164)
>   at org.apache.commons.net.SocketClient.connect(SocketClient.java:184)
>   at 
> com.swimap.prs.utils.ftp.FTPSTransfer.initFTPSClient(FTPSTransfer.java:96)
>   at 
> com.swimap.prs.utils.ftp.FTPSTransfer.initFtpsClient(FTPSTransfer.java:336)
>   at com.swimap.prs.utils.ftp.FTPSTransfer.upload(FTPSTransfer.java:236)
>   at 
> com.swimap.prs.application.paimgr.session.impl.TransferFileService.uploadFile(TransferFileService.java:57)
> {noformat}
> this issue happen sometimes when the other times is ok.
> code as follows:
> {code}
> ftps = new FTPSClient("TLSv1.2", true);
> ftps.setConnectTimeout(1);
> ftps.setDataTimeout(2);
> ftps.setControlEncoding("UTF-8");
> ftps.connect(ftpServerInfo.getIp());
> ftps.setSoTimeout(2);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NET-606) Thread hangs when invoke connect method

2017-01-06 Thread Sebb (JIRA) 

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

Sebb commented on NET-606:
--

Which version are you actually using?
The issue says 2.2.
The current version is 3.5.


> Thread hangs when invoke connect method
> ---
>
> Key: NET-606
> URL: https://issues.apache.org/jira/browse/NET-606
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 2.2
>Reporter: zhengweixiong
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> ftp hangs when trying connect. stack as follows. 
> {noformat}
> "UpdateBrowSerParam" #633 prio=5 os_prio=0 tid=0x7f60610cc000 nid=0x2165 
> runnable [0x7f6037403000]
>java.lang.Thread.State: RUNNABLE
>   at java.net.SocketInputStream.socketRead0(Native Method)
>   at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
>   at java.net.SocketInputStream.read(SocketInputStream.java:170)
>   at java.net.SocketInputStream.read(SocketInputStream.java:141)
>   at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
>   at sun.security.ssl.InputRecord.read(InputRecord.java:503)
>   at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
>   - locked <0x0006d44fdd70> (a java.lang.Object)
>   at 
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
>   - locked <0x0006d44fdda0> (a java.lang.Object)
>   at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
>   at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
>   at 
> org.apache.commons.net.ftp.FTPSClient.sslNegotiation(FTPSClient.java:263)
>   at 
> org.apache.commons.net.ftp.FTPSClient._connectAction_(FTPSClient.java:192)
>   at org.apache.commons.net.SocketClient.connect(SocketClient.java:164)
>   at org.apache.commons.net.SocketClient.connect(SocketClient.java:184)
>   at 
> com.swimap.prs.utils.ftp.FTPSTransfer.initFTPSClient(FTPSTransfer.java:96)
>   at 
> com.swimap.prs.utils.ftp.FTPSTransfer.initFtpsClient(FTPSTransfer.java:336)
>   at com.swimap.prs.utils.ftp.FTPSTransfer.upload(FTPSTransfer.java:236)
>   at 
> com.swimap.prs.application.paimgr.session.impl.TransferFileService.uploadFile(TransferFileService.java:57)
> {noformat}
> this issue happen sometimes when the other times is ok.
> code as follows:
> {code}
> ftps = new FTPSClient("TLSv1.2", true);
> ftps.setConnectTimeout(1);
> ftps.setDataTimeout(2);
> ftps.setControlEncoding("UTF-8");
> ftps.connect(ftpServerInfo.getIp());
> ftps.setSoTimeout(2);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NET-606) Thread hangs when invoke connect method

2017-01-06 Thread Sebb (JIRA) 

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

Sebb updated NET-606:
-
Priority: Major  (was: Critical)

> Thread hangs when invoke connect method
> ---
>
> Key: NET-606
> URL: https://issues.apache.org/jira/browse/NET-606
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 2.2
>Reporter: zhengweixiong
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> ftp hangs when trying connect. stack as follows. 
> {noformat}
> "UpdateBrowSerParam" #633 prio=5 os_prio=0 tid=0x7f60610cc000 nid=0x2165 
> runnable [0x7f6037403000]
>java.lang.Thread.State: RUNNABLE
>   at java.net.SocketInputStream.socketRead0(Native Method)
>   at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
>   at java.net.SocketInputStream.read(SocketInputStream.java:170)
>   at java.net.SocketInputStream.read(SocketInputStream.java:141)
>   at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
>   at sun.security.ssl.InputRecord.read(InputRecord.java:503)
>   at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
>   - locked <0x0006d44fdd70> (a java.lang.Object)
>   at 
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
>   - locked <0x0006d44fdda0> (a java.lang.Object)
>   at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
>   at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
>   at 
> org.apache.commons.net.ftp.FTPSClient.sslNegotiation(FTPSClient.java:263)
>   at 
> org.apache.commons.net.ftp.FTPSClient._connectAction_(FTPSClient.java:192)
>   at org.apache.commons.net.SocketClient.connect(SocketClient.java:164)
>   at org.apache.commons.net.SocketClient.connect(SocketClient.java:184)
>   at 
> com.swimap.prs.utils.ftp.FTPSTransfer.initFTPSClient(FTPSTransfer.java:96)
>   at 
> com.swimap.prs.utils.ftp.FTPSTransfer.initFtpsClient(FTPSTransfer.java:336)
>   at com.swimap.prs.utils.ftp.FTPSTransfer.upload(FTPSTransfer.java:236)
>   at 
> com.swimap.prs.application.paimgr.session.impl.TransferFileService.uploadFile(TransferFileService.java:57)
> {noformat}
> this issue happen sometimes when the other times is ok.
> code as follows:
> {code}
> ftps = new FTPSClient("TLSv1.2", true);
> ftps.setConnectTimeout(1);
> ftps.setDataTimeout(2);
> ftps.setControlEncoding("UTF-8");
> ftps.connect(ftpServerInfo.getIp());
> ftps.setSoTimeout(2);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NET-606) Thread hangs when invoke connect method

2017-01-06 Thread zhengweixiong (JIRA) 

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

zhengweixiong updated NET-606:
--
Description: 
ftp hangs when trying connect. stack as follows. 

{noformat}
"UpdateBrowSerParam" #633 prio=5 os_prio=0 tid=0x7f60610cc000 nid=0x2165 
runnable [0x7f6037403000]
   java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:170)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
at sun.security.ssl.InputRecord.read(InputRecord.java:503)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
- locked <0x0006d44fdd70> (a java.lang.Object)
at 
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
- locked <0x0006d44fdda0> (a java.lang.Object)
at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
at 
org.apache.commons.net.ftp.FTPSClient.sslNegotiation(FTPSClient.java:263)
at 
org.apache.commons.net.ftp.FTPSClient._connectAction_(FTPSClient.java:192)
at org.apache.commons.net.SocketClient.connect(SocketClient.java:164)
at org.apache.commons.net.SocketClient.connect(SocketClient.java:184)
at 
com.swimap.prs.utils.ftp.FTPSTransfer.initFTPSClient(FTPSTransfer.java:96)
at 
com.swimap.prs.utils.ftp.FTPSTransfer.initFtpsClient(FTPSTransfer.java:336)
at com.swimap.prs.utils.ftp.FTPSTransfer.upload(FTPSTransfer.java:236)
at 
com.swimap.prs.application.paimgr.session.impl.TransferFileService.uploadFile(TransferFileService.java:57)
{noformat}

this issue happen sometimes when the other times is ok.
code as follows:

{code}
ftps = new FTPSClient("TLSv1.2", true);
ftps.setConnectTimeout(1);
ftps.setDataTimeout(2);
ftps.setControlEncoding("UTF-8");
ftps.connect(ftpServerInfo.getIp());
ftps.setSoTimeout(2);
{code}

  was:
ftp hangs when trying connect. stack as follows. 

{noformat}
"UpdateBrowSerParam" #633 prio=5 os_prio=0 tid=0x7f60610cc000 nid=0x2165 
runnable [0x7f6037403000]
   java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:170)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
at sun.security.ssl.InputRecord.read(InputRecord.java:503)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
- locked <0x0006d44fdd70> (a java.lang.Object)
at 
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
- locked <0x0006d44fdda0> (a java.lang.Object)
at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
at 
org.apache.commons.net.ftp.FTPSClient.sslNegotiation(FTPSClient.java:263)
at 
org.apache.commons.net.ftp.FTPSClient._connectAction_(FTPSClient.java:192)
at org.apache.commons.net.SocketClient.connect(SocketClient.java:164)
at org.apache.commons.net.SocketClient.connect(SocketClient.java:184)
at 
com.swimap.prs.utils.ftp.FTPSTransfer.initFTPSClient(FTPSTransfer.java:96)
at 
com.swimap.prs.utils.ftp.FTPSTransfer.initFtpsClient(FTPSTransfer.java:336)
at com.swimap.prs.utils.ftp.FTPSTransfer.upload(FTPSTransfer.java:236)
at 
com.swimap.prs.application.paimgr.session.impl.TransferFileService.uploadFile(TransferFileService.java:57)
{noformat}

this issue happen something when the other times is ok.
code as follows:

{code}
ftps = new FTPSClient("TLSv1.2", true);
ftps.setConnectTimeout(1);
ftps.setDataTimeout(2);
ftps.setControlEncoding("UTF-8");
ftps.connect(ftpServerInfo.getIp());
ftps.setSoTimeout(2);
{code}


> Thread hangs when invoke connect method
> ---
>
> Key: NET-606
> URL: https://issues.apache.org/jira/browse/NET-606
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 2.2
>Reporter: zhengweixiong
>Priority: Critical
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> ftp hangs when trying connect. stack as follows. 
> {noformat}
> "UpdateBrowSerParam" #633 prio=5 os_prio=0 tid=0x7f60610cc000 nid=0x2165 
> runnable [0x7f6037403000]
>

[jira] [Updated] (NET-606) Thread hangs when invoke connect method

2017-01-06 Thread zhengweixiong (JIRA) 

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

zhengweixiong updated NET-606:
--
Priority: Critical  (was: Minor)

> Thread hangs when invoke connect method
> ---
>
> Key: NET-606
> URL: https://issues.apache.org/jira/browse/NET-606
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 2.2
>Reporter: zhengweixiong
>Priority: Critical
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> ftp hangs when trying connect. stack as follows. 
> {noformat}
> "UpdateBrowSerParam" #633 prio=5 os_prio=0 tid=0x7f60610cc000 nid=0x2165 
> runnable [0x7f6037403000]
>java.lang.Thread.State: RUNNABLE
>   at java.net.SocketInputStream.socketRead0(Native Method)
>   at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
>   at java.net.SocketInputStream.read(SocketInputStream.java:170)
>   at java.net.SocketInputStream.read(SocketInputStream.java:141)
>   at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
>   at sun.security.ssl.InputRecord.read(InputRecord.java:503)
>   at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
>   - locked <0x0006d44fdd70> (a java.lang.Object)
>   at 
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
>   - locked <0x0006d44fdda0> (a java.lang.Object)
>   at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
>   at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
>   at 
> org.apache.commons.net.ftp.FTPSClient.sslNegotiation(FTPSClient.java:263)
>   at 
> org.apache.commons.net.ftp.FTPSClient._connectAction_(FTPSClient.java:192)
>   at org.apache.commons.net.SocketClient.connect(SocketClient.java:164)
>   at org.apache.commons.net.SocketClient.connect(SocketClient.java:184)
>   at 
> com.swimap.prs.utils.ftp.FTPSTransfer.initFTPSClient(FTPSTransfer.java:96)
>   at 
> com.swimap.prs.utils.ftp.FTPSTransfer.initFtpsClient(FTPSTransfer.java:336)
>   at com.swimap.prs.utils.ftp.FTPSTransfer.upload(FTPSTransfer.java:236)
>   at 
> com.swimap.prs.application.paimgr.session.impl.TransferFileService.uploadFile(TransferFileService.java:57)
> {noformat}
> this issue happen something when the other times is ok.
> code as follows:
> {code}
> ftps = new FTPSClient("TLSv1.2", true);
> ftps.setConnectTimeout(1);
> ftps.setDataTimeout(2);
> ftps.setControlEncoding("UTF-8");
> ftps.connect(ftpServerInfo.getIp());
> ftps.setSoTimeout(2);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ATTRIBUTES-15) Attributes on Resources

2017-01-06 Thread Gabriel Hartmann (JIRA) 
Gabriel Hartmann created ATTRIBUTES-15:
--

 Summary: Attributes on Resources
 Key: ATTRIBUTES-15
 URL: https://issues.apache.org/jira/browse/ATTRIBUTES-15
 Project: Commons Attributes
  Issue Type: Improvement
Reporter: Gabriel Hartmann


Resources (particularly disks) need attributes so that they can be selectively 
consumed by frameworks depending on characteristics like whether they are SSDs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JCS-171) Multiple CacheEventQueue.QProcessor spawned for the same cache region

2017-01-06 Thread Wiktor N (JIRA) 

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

Wiktor N updated JCS-171:
-
Attachment: CacheEventQueue.patch

> Multiple CacheEventQueue.QProcessor spawned for the same cache region
> -
>
> Key: JCS-171
> URL: https://issues.apache.org/jira/browse/JCS-171
> Project: Commons JCS
>  Issue Type: Bug
>  Components: Composite Cache
>Affects Versions: jcs-2.0
>Reporter: Wiktor N
> Attachments: CacheEventQueue.patch
>
>
> I noticed that running on new version of JCS I get multiple 
> CacheEventQueue.QProcessor thread. They spawn from time to time.
> I've checked recent changes and changes few things in r1774925 look 
> suspicious:
> 1. In previous code we spawned a new thread in synchronized section. This got 
> us a guarantee, that there will be no two threads trying to spawn a new 
> thread in the same time. Maybe some locking is needed around thread creation?
> 2. QProcessor uses isAlive() method. But this is defined by Thread.isAlive() 
> while it should probably check for CacheEventQueue.this.isAlive()



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCS-171) Multiple CacheEventQueue.QProcessor spawned for the same cache region

2017-01-06 Thread Wiktor N (JIRA) 

[ 
https://issues.apache.org/jira/browse/JCS-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15806379#comment-15806379
 ] 

Wiktor N commented on JCS-171:
--

Using only second change I can see that CacheEventQueue.QProcessor threads die 
after sometime instead live forever.

Please find patch attached.

> Multiple CacheEventQueue.QProcessor spawned for the same cache region
> -
>
> Key: JCS-171
> URL: https://issues.apache.org/jira/browse/JCS-171
> Project: Commons JCS
>  Issue Type: Bug
>  Components: Composite Cache
>Affects Versions: jcs-2.0
>Reporter: Wiktor N
>
> I noticed that running on new version of JCS I get multiple 
> CacheEventQueue.QProcessor thread. They spawn from time to time.
> I've checked recent changes and changes few things in r1774925 look 
> suspicious:
> 1. In previous code we spawned a new thread in synchronized section. This got 
> us a guarantee, that there will be no two threads trying to spawn a new 
> thread in the same time. Maybe some locking is needed around thread creation?
> 2. QProcessor uses isAlive() method. But this is defined by Thread.isAlive() 
> while it should probably check for CacheEventQueue.this.isAlive()



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (JCS-171) Multiple CacheEventQueue.QProcessor spawned for the same cache region

2017-01-06 Thread Wiktor N (JIRA) 
Wiktor N created JCS-171:


 Summary: Multiple CacheEventQueue.QProcessor spawned for the same 
cache region
 Key: JCS-171
 URL: https://issues.apache.org/jira/browse/JCS-171
 Project: Commons JCS
  Issue Type: Bug
  Components: Composite Cache
Affects Versions: jcs-2.0
Reporter: Wiktor N


I noticed that running on new version of JCS I get multiple 
CacheEventQueue.QProcessor thread. They spawn from time to time.

I've checked recent changes and changes few things in r1774925 look suspicious:
1. In previous code we spawned a new thread in synchronized section. This got 
us a guarantee, that there will be no two threads trying to spawn a new thread 
in the same time. Maybe some locking is needed around thread creation?

2. QProcessor uses isAlive() method. But this is defined by Thread.isAlive() 
while it should probably check for CacheEventQueue.this.isAlive()



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COMPLEX-1) Testing fails due to poor null handling in newly created local equals() and equals-type methods

2017-01-06 Thread Raymond DeCampo (JIRA) 

[ 
https://issues.apache.org/jira/browse/COMPLEX-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15806014#comment-15806014
 ] 

Raymond DeCampo commented on COMPLEX-1:
---

Created a pull request on github to replace the patches previously emailed 
directly to Eric:

https://github.com/apache/commons-complex/pull/1

This fixes ComplexTest, QuaternionTest and RootsOfUnityTest.

> Testing fails due to poor null handling in newly created local equals() and 
> equals-type methods
> ---
>
> Key: COMPLEX-1
> URL: https://issues.apache.org/jira/browse/COMPLEX-1
> Project: Commons Complex
>  Issue Type: Bug
>Reporter: Eric Barnhill
>  Labels: patch, test
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> commons-complex currently compiles but fails tests. Patches are needed to 
> handle null in the testing methods.
> Local equals() methods have been created to eliminate dependencies on other 
> Math packages, but these appear to not handle null.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COMPLEX-1) Testing fails due to poor null handling in newly created local equals() and equals-type methods

2017-01-06 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/COMPLEX-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15806010#comment-15806010
 ] 

ASF GitHub Bot commented on COMPLEX-1:
--

GitHub user RayDeCampo opened a pull request:

https://github.com/apache/commons-complex/pull/1

[COMPLEX-1] Testing fails

Fix equals methods in Complex and Quaternion by copying over Precision from 
commons-math.  Made Precision package protected and removed parts not used by 
code currently in commons-complex.  This fixes ComplexTest and QuaternionTest 
unit tests.

Fix RootsOfUnityTest by changing test methods to expect the correct 
exception class.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/RayDeCampo/commons-complex COMPLEX-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-complex/pull/1.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1


commit f7cca80f4a6913f22829ad5dfcebd980ce5289cd
Author: Ray DeCampo 
Date:   2017-01-06T22:35:51Z

[COMPLEX-1] Fix equals methods in Complex and Quaternion by copying over 
Precision from commons-math.  Made Precision package protected and removed 
parts not used by code currently in commons-complex.  This fixes ComplexTest 
and QuaternionTest unit tests.
Fix RootsOfUnityTest by changing test methods to expect the correct 
exception class.




> Testing fails due to poor null handling in newly created local equals() and 
> equals-type methods
> ---
>
> Key: COMPLEX-1
> URL: https://issues.apache.org/jira/browse/COMPLEX-1
> Project: Commons Complex
>  Issue Type: Bug
>Reporter: Eric Barnhill
>  Labels: patch, test
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> commons-complex currently compiles but fails tests. Patches are needed to 
> handle null in the testing methods.
> Local equals() methods have been created to eliminate dependencies on other 
> Math packages, but these appear to not handle null.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (COMPLEX-2) Potential performance issues in "ComplexUtils"

2017-01-06 Thread Gilles (JIRA) 
Gilles created COMPLEX-2:


 Summary: Potential performance issues in "ComplexUtils"
 Key: COMPLEX-2
 URL: https://issues.apache.org/jira/browse/COMPLEX-2
 Project: Commons Complex
  Issue Type: Improvement
Reporter: Gilles
Priority: Minor


See http://markmail.org/message/qnzauv65nb3gmz2h

To be checked with JMH benchmarking code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COMPLEX-1) Testing fails due to poor null handling in newly created local equals() and equals-type methods

2017-01-06 Thread Gilles (JIRA) 

[ 
https://issues.apache.org/jira/browse/COMPLEX-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15805017#comment-15805017
 ] 

Gilles commented on COMPLEX-1:
--

{{target}} was removed.

You are right for {{site-content}} (handled by "subversion" rather than "git").


> Testing fails due to poor null handling in newly created local equals() and 
> equals-type methods
> ---
>
> Key: COMPLEX-1
> URL: https://issues.apache.org/jira/browse/COMPLEX-1
> Project: Commons Complex
>  Issue Type: Bug
>Reporter: Eric Barnhill
>  Labels: patch, test
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> commons-complex currently compiles but fails tests. Patches are needed to 
> handle null in the testing methods.
> Local equals() methods have been created to eliminate dependencies on other 
> Math packages, but these appear to not handle null.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COMPLEX-1) Testing fails due to poor null handling in newly created local equals() and equals-type methods

2017-01-06 Thread Raymond DeCampo (JIRA) 

[ 
https://issues.apache.org/jira/browse/COMPLEX-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15804972#comment-15804972
 ] 

Raymond DeCampo commented on COMPLEX-1:
---

We still need to remove the target/ directory (contains maven output including 
compiler output and test results) and the site-content/ directory (created by 
"mvn site").

> Testing fails due to poor null handling in newly created local equals() and 
> equals-type methods
> ---
>
> Key: COMPLEX-1
> URL: https://issues.apache.org/jira/browse/COMPLEX-1
> Project: Commons Complex
>  Issue Type: Bug
>Reporter: Eric Barnhill
>  Labels: patch, test
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> commons-complex currently compiles but fails tests. Patches are needed to 
> handle null in the testing methods.
> Local equals() methods have been created to eliminate dependencies on other 
> Math packages, but these appear to not handle null.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TEXT-56) Move CvsTranslators out of StringEscapeUtils and make them DRY

2017-01-06 Thread Pascal Schumacher (JIRA) 

[ 
https://issues.apache.org/jira/browse/TEXT-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15804896#comment-15804896
 ] 

Pascal Schumacher commented on TEXT-56:
---

StringEscapeUtils was moved from commons-lang to commons-text, so I moved the 
issue from lang to text.

> Move CvsTranslators out of StringEscapeUtils and make them DRY
> --
>
> Key: TEXT-56
> URL: https://issues.apache.org/jira/browse/TEXT-56
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Jarosław Strzelecki
>Priority: Minor
>
> CvsEscaper/CvsUnescaper are currently inner classes of StringEscapeUtils and 
> it does not seem like it is a proper place for them.
> Since they are package-private, they can be safely moved lang.text.translate 
> package.
> Moreover it's possible make them more DRY by introducing SinlgePassTranslator 
> as suggested in TODO.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (TEXT-56) Move CvsTranslators out of StringEscapeUtils and make them DRY

2017-01-06 Thread Pascal Schumacher (JIRA) 

[ 
https://issues.apache.org/jira/browse/TEXT-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15804896#comment-15804896
 ] 

Pascal Schumacher edited comment on TEXT-56 at 1/6/17 4:17 PM:
---

StringEscapeUtils was moved from commons-lang to commons-text, so I moved this 
issue from lang to text.


was (Author: pascalschumacher):
StringEscapeUtils was moved from commons-lang to commons-text, so I moved the 
issue from lang to text.

> Move CvsTranslators out of StringEscapeUtils and make them DRY
> --
>
> Key: TEXT-56
> URL: https://issues.apache.org/jira/browse/TEXT-56
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Jarosław Strzelecki
>Priority: Minor
>
> CvsEscaper/CvsUnescaper are currently inner classes of StringEscapeUtils and 
> it does not seem like it is a proper place for them.
> Since they are package-private, they can be safely moved lang.text.translate 
> package.
> Moreover it's possible make them more DRY by introducing SinlgePassTranslator 
> as suggested in TODO.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Moved] (TEXT-56) Move CvsTranslators out of StringEscapeUtils and make them DRY

2017-01-06 Thread Pascal Schumacher (JIRA) 

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

Pascal Schumacher moved LANG-1308 to TEXT-56:
-

Affects Version/s: (was: 3.5)
  Component/s: (was: lang.*)
   (was: lang.text.translate.*)
 Workflow: jira  (was: Default workflow, editable Closed status)
  Key: TEXT-56  (was: LANG-1308)
  Project: Commons Text  (was: Commons Lang)

> Move CvsTranslators out of StringEscapeUtils and make them DRY
> --
>
> Key: TEXT-56
> URL: https://issues.apache.org/jira/browse/TEXT-56
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Jarosław Strzelecki
>Priority: Minor
>
> CvsEscaper/CvsUnescaper are currently inner classes of StringEscapeUtils and 
> it does not seem like it is a proper place for them.
> Since they are package-private, they can be safely moved lang.text.translate 
> package.
> Moreover it's possible make them more DRY by introducing SinlgePassTranslator 
> as suggested in TODO.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COMPLEX-1) Testing fails due to poor null handling in newly created local equals() and equals-type methods

2017-01-06 Thread Gilles (JIRA) 

[ 
https://issues.apache.org/jira/browse/COMPLEX-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15804786#comment-15804786
 ] 

Gilles commented on COMPLEX-1:
--

I've done some cleanup. Please resync.

bq. Unfortunately I don't know enough about maven 

I also don't know much.
See the "commons-rng" repository; as a recent work space, I assume that it can 
be taken as an up-to-date example of what should be committed or not.


> Testing fails due to poor null handling in newly created local equals() and 
> equals-type methods
> ---
>
> Key: COMPLEX-1
> URL: https://issues.apache.org/jira/browse/COMPLEX-1
> Project: Commons Complex
>  Issue Type: Bug
>Reporter: Eric Barnhill
>  Labels: patch, test
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> commons-complex currently compiles but fails tests. Patches are needed to 
> handle null in the testing methods.
> Local equals() methods have been created to eliminate dependencies on other 
> Math packages, but these appear to not handle null.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COMPLEX-1) Testing fails due to poor null handling in newly created local equals() and equals-type methods

2017-01-06 Thread Raymond DeCampo (JIRA) 

[ 
https://issues.apache.org/jira/browse/COMPLEX-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15804534#comment-15804534
 ] 

Raymond DeCampo commented on COMPLEX-1:
---

I think the first order of business is to remove any files/directory in the 
.gitignore from the repository.  That will eliminate the spurious files that 
Gilles referred to on the mailing list.

> Testing fails due to poor null handling in newly created local equals() and 
> equals-type methods
> ---
>
> Key: COMPLEX-1
> URL: https://issues.apache.org/jira/browse/COMPLEX-1
> Project: Commons Complex
>  Issue Type: Bug
>Reporter: Eric Barnhill
>  Labels: patch, test
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> commons-complex currently compiles but fails tests. Patches are needed to 
> handle null in the testing methods.
> Local equals() methods have been created to eliminate dependencies on other 
> Math packages, but these appear to not handle null.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COMPLEX-1) Testing fails due to poor null handling in newly created local equals() and equals-type methods

2017-01-06 Thread Eric Barnhill (JIRA) 

[ 
https://issues.apache.org/jira/browse/COMPLEX-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15804481#comment-15804481
 ] 

Eric Barnhill commented on COMPLEX-1:
-

I reverted the changes for now. 

Unfortunately I don't know enough about maven to know if some of these files 
are expected files from Maven.

log.txt is mine , this is the output of the failed tests.

The eclipse files may be mine -- I might have done that by accident.

> Testing fails due to poor null handling in newly created local equals() and 
> equals-type methods
> ---
>
> Key: COMPLEX-1
> URL: https://issues.apache.org/jira/browse/COMPLEX-1
> Project: Commons Complex
>  Issue Type: Bug
>Reporter: Eric Barnhill
>  Labels: patch, test
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> commons-complex currently compiles but fails tests. Patches are needed to 
> handle null in the testing methods.
> Local equals() methods have been created to eliminate dependencies on other 
> Math packages, but these appear to not handle null.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (COMPLEX-1) Testing fails due to poor null handling in newly created local equals() and equals-type methods

2017-01-06 Thread Eric Barnhill (JIRA) 
Eric Barnhill created COMPLEX-1:
---

 Summary: Testing fails due to poor null handling in newly created 
local equals() and equals-type methods
 Key: COMPLEX-1
 URL: https://issues.apache.org/jira/browse/COMPLEX-1
 Project: Commons Complex
  Issue Type: Bug
Reporter: Eric Barnhill


commons-complex currently compiles but fails tests. Patches are needed to 
handle null in the testing methods.

Local equals() methods have been created to eliminate dependencies on other 
Math packages, but these appear to not handle null.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TEXT-36) Dependency on "Commons RNG"

2017-01-06 Thread Raymond DeCampo (JIRA) 

[ 
https://issues.apache.org/jira/browse/TEXT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15804394#comment-15804394
 ] 

Raymond DeCampo commented on TEXT-36:
-

bq. Whether the feature is out-of-scope is a good question. For this issue, the 
assumption was that the class is there already.

Understood.

bq. The "" tag would not impose a transitive dependency.

Yes, I missed this aspect, that would make it more palatable.

bq. You are welcome to implement it.

Pull request on github against the TEXT-51 branch:

https://github.com/apache/commons-text/pull/25


> Dependency on "Commons RNG"
> ---
>
> Key: TEXT-36
> URL: https://issues.apache.org/jira/browse/TEXT-36
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Gilles
>  Labels: api
> Fix For: 1.1
>
>
> This is a follow-up of a 
> [discussion|https://issues.apache.org/jira/browse/TEXT-34?focusedCommentId=15762623=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15762623]
>  held in TEXT-34.
> IMHO, there is no harm in depending on the ["commons-rng-client-api" 
> module|http://commons.apache.org/proper/commons-rng/commons-rng-client-api/javadocs/api-1.0/index.html]
>  of Commons RNG; the "zero dependency" mantra does not hold here, since TEXT 
> already depends on LANG.
> OTOH, I see that it is counter-productive (i.e. it harms the Commons project 
> as a whole) to not advertize or use other Commons components, despite the 
> "own dog food" phrase appearing recurrently on the "dev" ML.
> Rather than having people blindly use {{java.util.Random}}, we should allow 
> them to choose wisely, based on full information.
> IMO, that means to indeed use {{UniformRandomProvider}} in order to raise 
> awareness about alternatives to the sub-optimal algorithm used by the JDK.
> However, if some Commons developers do not trust that the 
> {{UniformRandomProvider}} interface can be stable enough for TEXT, then we 
> should follow Jochen Wiedemann's advice (cf. archive of the "dev" ML) and 
> define TEXT's own interface to random numbers, with bridges to it from 
> {{UniformRandomProvider}} and from {{java.util.Random}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NET-609) DefaultUnixFTPFileEntryParserFactory Issue (leading spaces removal configuration)

2017-01-06 Thread Tqup3 (JIRA) 

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

Tqup3 updated NET-609:
--
Labels:   (was: easyfix)

> DefaultUnixFTPFileEntryParserFactory Issue (leading spaces removal 
> configuration)
> -
>
> Key: NET-609
> URL: https://issues.apache.org/jira/browse/NET-609
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 3.4
>Reporter: Tqup3
>
> I have an issue when calling listFiles() method on a FTP server.
> The FTPFileEntry parser fail to parse the entry by adding a non existing 
> leading space in the filename.
> In the FTP library, a boolean field is existing to remove the leading spaces 
> and needs to be set to true (in my case).
> The issue is in the file DefaultUnixFTPFileEntryParserFactory.java 
> (L124-L128) :
> {code:java}
> if (parser == null) { // Now try for aliases
> String ukey = key.toUpperCase(java.util.Locale.ENGLISH);
> if (ukey.indexOf(FTPClientConfig.SYST_UNIX) >= 0)
> { // FTPClientConfig.SYST_UNIX = "UNIX"
> parser = new UnixFTPEntryParser(config, false);
> }
> else if  (ukey.indexOf(FTPClientConfig.SYST_UNIX_TRIM_LEADING) >= 
> 0)
> { // FTPClientConfig.SYST_UNIX_TRIM_LEADING = "UNIX_LTRIM"
> parser = new UnixFTPEntryParser(config, true);
> }
> // ...
> }
> {code}
> I think the issue is that the else if condition is unreachable because if 
> second condition is true, the first condition is matching too :
> FTPClientConfig.SYST_UNIX = "UNIX"
> FTPClientConfig.SYST_UNIX_TRIM_LEADING = "UNIX_LTRIM"
> I think the issue is related to the commit on NET-566 (commit: 
> http://svn.apache.org/viewvc?view=revision=1652696)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (NET-609) DefaultUnixFTPFileEntryParserFactory Issue (leading spaces removal configuration)

2017-01-06 Thread Tqup3 (JIRA) 
Tqup3 created NET-609:
-

 Summary: DefaultUnixFTPFileEntryParserFactory Issue (leading 
spaces removal configuration)
 Key: NET-609
 URL: https://issues.apache.org/jira/browse/NET-609
 Project: Commons Net
  Issue Type: Bug
  Components: FTP
Affects Versions: 3.4
Reporter: Tqup3


I have an issue when calling listFiles() method on a FTP server.
The FTPFileEntry parser fail to parse the entry by adding a non existing 
leading space in the filename.

In the FTP library, a boolean field is existing to remove the leading spaces 
and needs to be set to true (in my case).

The issue is in the file DefaultUnixFTPFileEntryParserFactory.java (L124-L128) :
{code:java}
if (parser == null) { // Now try for aliases
String ukey = key.toUpperCase(java.util.Locale.ENGLISH);
if (ukey.indexOf(FTPClientConfig.SYST_UNIX) >= 0)
{ // FTPClientConfig.SYST_UNIX = "UNIX"
parser = new UnixFTPEntryParser(config, false);
}
else if  (ukey.indexOf(FTPClientConfig.SYST_UNIX_TRIM_LEADING) >= 0)
{ // FTPClientConfig.SYST_UNIX_TRIM_LEADING = "UNIX_LTRIM"
parser = new UnixFTPEntryParser(config, true);
}
// ...
}
{code}

I think the issue is that the else if condition is unreachable because if 
second condition is true, the first condition is matching too :
FTPClientConfig.SYST_UNIX = "UNIX"
FTPClientConfig.SYST_UNIX_TRIM_LEADING = "UNIX_LTRIM"

I think the issue is related to the commit on NET-566 (commit: 
http://svn.apache.org/viewvc?view=revision=1652696)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)