[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)
