[jira] [Commented] (VFS-589) SFTP moveTo operation hangs if the server does not support SSH channelExec.
[ https://issues.apache.org/jira/browse/VFS-589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16226410#comment-16226410 ] L commented on VFS-589: --- The fix looks OK. As for verifying it: I have proposed a test to verify the fix, see patch_sftp_tests_hang_no_exec.diff. I think it is a good idea to add this test case to the set of SFTP tests. This way you get the automatic verification. > SFTP moveTo operation hangs if the server does not support SSH channelExec. > --- > > Key: VFS-589 > URL: https://issues.apache.org/jira/browse/VFS-589 > Project: Commons VFS > Issue Type: Bug >Affects Versions: Nightly Builds >Reporter: L > Fix For: 2.3 > > Attachments: patch_sftp_tests_hang_no_exec.diff, > patch_sftp_timeouts.diff > > > In our case the server was explicitly configured to disable SSH channelExec. > Our code was hanging trying to execute moveTo(). Stacktrace: > {code} >java.lang.Thread.State: TIMED_WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > at java.io.PipedInputStream.read(PipedInputStream.java:326) > - locked <0x0006a7a184d0> (a > com.jcraft.jsch.Channel$MyPipedInputStream) > at java.io.PipedInputStream.read(PipedInputStream.java:377) > - locked <0x0006a7a184d0> (a > com.jcraft.jsch.Channel$MyPipedInputStream) > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284) > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178) > - locked <0x0006a7a184b8> (a java.io.InputStreamReader) > at java.io.InputStreamReader.read(InputStreamReader.java:184) > at > org.apache.commons.vfs2.provider.sftp.SftpFileSystem.executeCommand(SftpFileSystem.java:328) > at > org.apache.commons.vfs2.provider.sftp.SftpFileSystem.getGroupsIds(SftpFileSystem.java:260) > at > org.apache.commons.vfs2.provider.sftp.SftpFileObject.getPermissions(SftpFileObject.java:317) > at > org.apache.commons.vfs2.provider.sftp.SftpFileObject.doIsWriteable(SftpFileObject.java:357) > at > org.apache.commons.vfs2.provider.AbstractFileObject.isWriteable(AbstractFileObject.java:1791) > at > org.apache.commons.vfs2.impl.DecoratedFileObject.isWriteable(DecoratedFileObject.java:229) > at > org.apache.commons.vfs2.cache.OnCallRefreshFileObject.isWriteable(OnCallRefreshFileObject.java:156) > at > org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1857) > at > org.apache.commons.vfs2.impl.DecoratedFileObject.moveTo(DecoratedFileObject.java:241) > at > org.apache.commons.vfs2.cache.OnCallRefreshFileObject.moveTo(OnCallRefreshFileObject.java:184) > ... > {code} > Technically the connection was alive because the session had a configured > timeout and the jcraft code kept sending keepalive SSH_MSG_GLOBAL_REQUEST > messages, but the thread performing FileObject.moveTo() did not return from > moveTo(). > I have changed SftpProviderTestCase to reproduce the problem: > testRenameFile() hangs. > The patch (patch_sftp_tests_hang_no_exec.diff) is attached. > I traced the problem to the fact that VFS invokes method > com.jcraft.jsch.Channel.connect(). This method uses timeout value 0, in which > case class com.jcraft.jsch.ChannelExec creates an instance of class > com.jcraft.jsch.RequestExec that sends an SSH packet SSH_MSG_CHANNEL_REQUEST > with "want reply" set to 0. > Correspondingly, if the server supports SSH channelExec, it executes the > specified command and returns some data. > But if the server *does not* support SSH channelExec it sends nothing back > while jcraft code tries to read something. This is the hang I am observing. > The fix would be to invoke com.jcraft.jsch.Channel.connect(int > connectTimeout). > As a result jcraft sends an SSH packet SSH_MSG_CHANNEL_REQUEST with "want > reply" set to 1 *and* it waits for an answer *and* it reacts to the answer. > Correspondingly, if the server supports SSH channelExec, it sends an SSH > packet SSH_MSG_CHANNEL_SUCCESS and the executes the specified command and > returns some data. > If the server *does not* support SSH channelExec it sends an SSH packet > SSH_MSG_CHANNEL_FAILURE. > jcraft reacts on either of this messages because if waits for one of them. If > it receives SSH_MSG_CHANNEL_SUCCESS it goes further and reads the response of > the executed command. > If it receives SSH_MSG_CHANNEL_FAILURE it immediately reports this by > throwing JSchException with message "failed to send channel request". > There is no hang whatsoever. Instead all tests from ProviderRenameTests fail > with errors like > {code} > Could not determine if file "sftp://testtest@localhost:50036/write-tests"; is > writeable. > {code} > The test suite actu
[GitHub] commons-lang issue #299: Add module-info for Java 9
Github user jodastephen commented on the issue: https://github.com/apache/commons-lang/pull/299 @namannigam You need to check it out and run `mvn clean install site` on Java 9. ---
[jira] [Commented] (COMMONSRDF-66) JenaDatasetImpl.toString() throws RIOT exception
[ https://issues.apache.org/jira/browse/COMMONSRDF-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16226467#comment-16226467 ] ASF GitHub Bot commented on COMMONSRDF-66: -- Github user christopher-johnson commented on the issue: https://github.com/apache/commons-rdf/pull/42 CI error is currently noted by Travis as an [open issue](https://www.traviscistatus.com/incidents/xgpn2tq6mx7k). > JenaDatasetImpl.toString() throws RIOT exception > > > Key: COMMONSRDF-66 > URL: https://issues.apache.org/jira/browse/COMMONSRDF-66 > Project: Apache Commons RDF > Issue Type: Bug > Components: jena >Affects Versions: 0.3.0 >Reporter: Christopher Johnson >Assignee: Sergio Fernández > Fix For: 0.5.0 > > > Occurs from this method > [https://github.com/apache/commons-rdf/blob/master/jena/src/main/java/org/apache/commons/rdf/jena/impl/JenaDatasetImpl.java#L152] > on instantiation: > The exception message is "No dataset writer for N-Triples/utf-8". > The source is RDFWriterRegistry that builds a registryDataset HashMap of 17 > +Dataset+ RDFFormats that does not include this serialization. The > registryGraph HashMap has 25 RDFFormats that does include "N-Triples/utf-8". > No exception is thrown if Lang.NQUADS is set in the toString() method. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (JEXL-244) Webapp classloader memory leaks
Dmitri Blinov created JEXL-244: -- Summary: Webapp classloader memory leaks Key: JEXL-244 URL: https://issues.apache.org/jira/browse/JEXL-244 Project: Commons JEXL Issue Type: Bug Affects Versions: 3.1 Environment: Inside J2EE container when Jexl library is included in the deployed .war file Reporter: Dmitri Blinov I have spotted that the following constructions, like for example in JexlEngine.java {code} public static final Object TRY_FAILED = new Object() { @Override public String toString() { return "tryExecute failed"; } }; {code} are not garbage collected when web-app is reloaded and its classloader is released. This is because circular references are created when static class members are initialized with non-static inner/anonymous classes, which are holding implicit references to its enclosing class and thus to its static class type. There are other such examples in JexlEngine.java like {code} protected static final java.lang.ThreadLocal CONTEXT = new java.lang.ThreadLocal() {.. protected static final java.lang.ThreadLocal ENGINE = new java.lang.ThreadLocal() {... {code} The issue is easily resolved if for example the following pattern is followed {code} public static class FailObject extends Object { @Override public String toString() { return "tryExecute failed"; } } public static final Object TRY_FAILED = new FailObject(); {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (POOL-332) ObjectPool and KeyedObject pool should extend Closeable
Gary Gregory created POOL-332: - Summary: ObjectPool and KeyedObject pool should extend Closeable Key: POOL-332 URL: https://issues.apache.org/jira/browse/POOL-332 Project: Commons Pool Issue Type: New Feature Reporter: Gary Gregory Fix For: 2.5 {{ObjectPool}} and {{KeyedObject}} pool should extend {{java.io.Closeable}}. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (COMMONSRDF-66) JenaDatasetImpl.toString() throws RIOT exception
[ https://issues.apache.org/jira/browse/COMMONSRDF-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16227061#comment-16227061 ] ASF GitHub Bot commented on COMMONSRDF-66: -- Github user wikier commented on the issue: https://github.com/apache/commons-rdf/pull/42 LGTM > JenaDatasetImpl.toString() throws RIOT exception > > > Key: COMMONSRDF-66 > URL: https://issues.apache.org/jira/browse/COMMONSRDF-66 > Project: Apache Commons RDF > Issue Type: Bug > Components: jena >Affects Versions: 0.3.0 >Reporter: Christopher Johnson >Assignee: Sergio Fernández > Fix For: 0.5.0 > > > Occurs from this method > [https://github.com/apache/commons-rdf/blob/master/jena/src/main/java/org/apache/commons/rdf/jena/impl/JenaDatasetImpl.java#L152] > on instantiation: > The exception message is "No dataset writer for N-Triples/utf-8". > The source is RDFWriterRegistry that builds a registryDataset HashMap of 17 > +Dataset+ RDFFormats that does not include this serialization. The > registryGraph HashMap has 25 RDFFormats that does include "N-Triples/utf-8". > No exception is thrown if Lang.NQUADS is set in the toString() method. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (DAEMON-376) Update Daemon to also search registry for JRE with Java 9 JRE location
[ https://issues.apache.org/jira/browse/DAEMON-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DAEMON-376. Resolution: Fixed Fix Version/s: 1.1 Fixed by switching to using a list of registry keys to look in. Adding a new one is fairly simple should we ever need to. > Update Daemon to also search registry for JRE with Java 9 JRE location > -- > > Key: DAEMON-376 > URL: https://issues.apache.org/jira/browse/DAEMON-376 > Project: Commons Daemon > Issue Type: Bug > Environment: Windows only >Reporter: Mark Thomas > Fix For: 1.1 > > > Java 9: > HKLM\SOFTWARE\JavaSoft\JRE > Java 8 and earlier: > HKLM\SOFTWARE\JavaSoft\Java Runtime Environment -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (DAEMON-311) Commons Daemon procrun failed with exit value: 5 (Failed to start service)
[ https://issues.apache.org/jira/browse/DAEMON-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DAEMON-311. Resolution: Fixed Fix Version/s: 1.1 Fixed by switching to using a list of registry keys to look in. Adding a new one is fairly simple should we ever need to. > Commons Daemon procrun failed with exit value: 5 (Failed to start service) > -- > > Key: DAEMON-311 > URL: https://issues.apache.org/jira/browse/DAEMON-311 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.15 > Environment: OS : Windows 7 (64bit) > Jre : 7 (32bit) and 7(64bit) installed, the 32bit one is used by default. > Hardware specifications : > - Processor : Intel Core i7 > - RAM : 8 GB >Reporter: Vincent Tonus > Fix For: 1.1 > > > I use the Amd64 version of procrun to run a .jar as a service, it works on > several machines with the same configuration but on one of them, It's > impossible to start the service. > When the service is installed (with this command) : > {quote}xx.exe //IS//xx --Install=xx.exe" --Description="xx" --Jvm=auto > --Classpath=xx.jar --Startup=auto --StartMode=jvm > --StartClass=Controller.ServiceMain --StartMethod=main --StartParams=start > --StopMode=jvm --StopClass=Controller.ServiceMain --StopMethod=main > --StopParams=stop --LogPath="./Logs" --StdOutput=auto --StdError=auto > --StopTimeout=120 --LogLevel=debug{quote} > it generates this log : > {quote} > [2013-11-28 13:10:06] [debug] ( prunsrv.c:1679) [ 9444] Commons Daemon > procrun log initialized > [2013-11-28 13:10:06] [info] ( prunsrv.c:1683) [ 9444] Commons Daemon > procrun (1.0.15.0 64-bit) started > [2013-11-28 13:10:06] [debug] ( prunsrv.c:561 ) [ 9444] Installing service... > [2013-11-28 13:10:06] [info] ( prunsrv.c:600 ) [ 9444] Service xx name > [2013-11-28 13:10:07] [debug] ( prunsrv.c:616 ) [ 9444] Setting service > description xx > [2013-11-28 13:10:07] [info] ( prunsrv.c:634 ) [ 9444] Service 'xx' installed > [2013-11-28 13:10:07] [info] ( prunsrv.c:1764) [ 9444] Commons Daemon > procrun finished > [2013-11-28 13:10:07] [debug] ( prunsrv.c:1679) [ 9724] Commons Daemon > procrun log initialized > [2013-11-28 13:10:07] [info] ( prunsrv.c:1683) [ 9724] Commons Daemon > procrun (1.0.15.0 64-bit) started > [2013-11-28 13:10:07] [info] ( prunsrv.c:725 ) [ 9724] Starting service 'xx' > ... > [2013-11-28 13:10:10] [error] ( prunsrv.c:746 ) [ 9724] Failed to start 'xx' > service > [2013-11-28 13:10:10] [error] ( prunsrv.c:746 ) [ 9724] The data area passed > to a system call is too small. > [2013-11-28 13:10:10] [info] ( prunsrv.c:754 ) [ 9724] Start service > finished. > [2013-11-28 13:10:10] [error] ( prunsrv.c:1755) [ 9724] Commons Daemon > procrun failed with exit value: 5 (Failed to start service) > [2013-11-28 13:10:10] [error] ( prunsrv.c:1755) [ 9724] The data area passed > to a system call is too small. > {quote} > And if I try to start the service again after the installation, no log is > generated anymore. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LANG-1352) EnumUtils.getEnumIgnoreCase and isValidEnumIgnoreCase methods added
[ https://issues.apache.org/jira/browse/LANG-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16227396#comment-16227396 ] Ruslan Sibgatullin commented on LANG-1352: -- [~kinow], hi, I've wrote to [Commons Developer list|https://commons.apache.org/mail-lists.html], but still no answer. :( would you please, assist with this? Thanks! Best Ruslan. > EnumUtils.getEnumIgnoreCase and isValidEnumIgnoreCase methods added > --- > > Key: LANG-1352 > URL: https://issues.apache.org/jira/browse/LANG-1352 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Reporter: Ruslan Sibgatullin >Priority: Minor > > EnumUtils.getEnumIgnoreCase and isValidEnumIgnoreCase methods added. > I truly believe that such handy method must exist in this utility class. > [This|https://stackoverflow.com/questions/28332924/case-insensitive-matching-of-a-string-to-a-java-enum] > SO thread is just a prove of it. And also in the project I work for we need > to perform this operation quite often. -- This message was sent by Atlassian JIRA (v6.4.14#64029)