[GitHub] [commons-vfs] abashev commented on issue #62: Don’t fail on openjdk-ea builds
abashev commented on issue #62: Don’t fail on openjdk-ea builds URL: https://github.com/apache/commons-vfs/pull/62#issuecomment-487742500 @garydgregory done, but builds will take more time in compare to docker environment This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] abashev commented on issue #61: Fix CI builds for Java 11
abashev commented on issue #61: Fix CI builds for Java 11 URL: https://github.com/apache/commons-vfs/pull/61#issuecomment-487742076 https://github.com/apache/commons-vfs/pull/62 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] abashev closed pull request #61: Fix CI builds for Java 11
abashev closed pull request #61: Fix CI builds for Java 11 URL: https://github.com/apache/commons-vfs/pull/61 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] garydgregory edited a comment on issue #62: Don’t fail on openjdk-ea builds
garydgregory edited a comment on issue #62: Don’t fail on openjdk-ea builds URL: https://github.com/apache/commons-vfs/pull/62#issuecomment-487703396 I just don't understand why we have other builds in Commons that can use the OpenJDK EA without any issue. In this case, we can't we even start to use it. So there must be some configuration thing happening that is allowing some of our Travis builds to work with OpenJDK EA like https://travis-ci.org/apache/commons-text This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] garydgregory commented on issue #62: Don’t fail on openjdk-ea builds
garydgregory commented on issue #62: Don’t fail on openjdk-ea builds URL: https://github.com/apache/commons-vfs/pull/62#issuecomment-487703396 I just don't understand why we have other builds in Commons that can use the OpenJDK EA without any issue. In this case, we can't we even start to use it. So there must be some configuration thing happening that is allowing some of our Travis builds to work like https://travis-ci.org/apache/commons-text This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] abashev commented on issue #62: Don’t fail on openjdk-ea builds
abashev commented on issue #62: Don’t fail on openjdk-ea builds URL: https://github.com/apache/commons-vfs/pull/62#issuecomment-487693912 @garydgregory yes, it is a Travis issue - there is no way to specify path or version, just `- openjdk-ea ` as the environment. So it is like well-known workaround - https://www.deps.co/guides/travis-ci-latest-java/ 'Ignoring failures with pre-release JDK’s' This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] garydgregory commented on issue #61: Fix CI builds for Java 11
garydgregory commented on issue #61: Fix CI builds for Java 11 URL: https://github.com/apache/commons-vfs/pull/61#issuecomment-487689007 It seems like this would apply to ALL Java setups, which I do not think is what we want. For Java EAs, we should either get it to work, or not test on EAs. WDYT? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] garydgregory commented on issue #62: Don’t fail on openjdk-ea builds
garydgregory commented on issue #62: Don’t fail on openjdk-ea builds URL: https://github.com/apache/commons-vfs/pull/62#issuecomment-487680818 The problems seems like a Travis issue: ``` Installing openjdk-ea $ export JAVA_HOME=~/openjdk-ea $ export PATH="$JAVA_HOME/bin:$PATH" $ ~/bin/install-jdk.sh --target "/home/travis/openjdk-ea" --workspace "/home/travis/.cache/install-jdk" --feature "ea" --license "GPL" --cacerts install-jdk.sh 2019-04-18 Couldn't determine a download url for 13-GPL on linux-x64 The command "~/bin/install-jdk.sh --target "/home/travis/openjdk-ea" --workspace "/home/travis/.cache/install-jdk" --feature "ea" --license "GPL" --cacerts" failed and exited with 1 during . Your build has been stopped. ``` Maybe we have to specify a specific OS setup like 'trusty' or some other version? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] abashev commented on issue #61: Fix CI builds for Java 11
abashev commented on issue #61: Fix CI builds for Java 11 URL: https://github.com/apache/commons-vfs/pull/61#issuecomment-487661578 @garydgregory hm, ok, but travis builds should be green to get an understanding is everything alright. What do you think about this solution https://github.com/abashev/commons-vfs/commit/be31fce334fd2fbbd0a1953cfec2cc4e6cdc24b2 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] garydgregory commented on issue #61: Fix CI builds for Java 11
garydgregory commented on issue #61: Fix CI builds for Java 11 URL: https://github.com/apache/commons-vfs/pull/61#issuecomment-487639117 Thank you @abashev. I took a slightly different approach by activating a profile on Java 11 and above with the TLS arg line. This makes it clear IMO that we only need the hack (in the good sense of the word) on Java 11 and up. Gary This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] abashev opened a new pull request #62: Don’t fail on openjdk-ea builds
abashev opened a new pull request #62: Don’t fail on openjdk-ea builds URL: https://github.com/apache/commons-vfs/pull/62 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Resolved] (VFS-662) SftpFileSystem has Thread-safe issue about idleChannel
[
https://issues.apache.org/jira/browse/VFS-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved VFS-662.
--
Resolution: Fixed
Fix Version/s: 2.4
In git master. Please verify and close.
> SftpFileSystem has Thread-safe issue about idleChannel
> ---
>
> Key: VFS-662
> URL: https://issues.apache.org/jira/browse/VFS-662
> Project: Commons VFS
> Issue Type: Bug
>Reporter: qxo
>Priority: Critical
> Fix For: 2.4
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {code}
> {code:java}
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not connect to
> SFTP server at
> at org.apache.commons.vfs2.provider.sftp.SftpFileSystem.getChannel
> (SftpFileSystem.java:149)
> at org.apache.commons.vfs2.provider.sftp.SftpFileObject.statSelf
> (SftpFileObject.java:152)
> at org.apache.commons.vfs2.provider.sftp.SftpFileObject.doGetType
> (SftpFileObject.java:113)
> at org.apache.commons.vfs2.provider.AbstractFileObject.getType
> (AbstractFileObject.java:1517)
> at org.apache.commons.vfs2.provider.sftp.SftpFileObject.refresh
> (SftpFileObject.java:90)
> at org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile
> (AbstractFileSystem.java:364)
> at org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile
> (AbstractFileSystem.java:317)
> at org.apache.commons.vfs2.provider.AbstractFileObject.resolveFile
> (AbstractFileObject.java:2039)
> at org.apache.commons.vfs2.FileObject$resolveFile$23.call (Unknown Source)
> Caused by: com.jcraft.jsch.JSchException: java.io.IOException: channel is
> broken
> at com.jcraft.jsch.ChannelSftp.start (ChannelSftp.java:315)
> at com.jcraft.jsch.Channel.connect (Channel.java:152)
> at com.jcraft.jsch.Channel.connect (Channel.java:145)
> at org.apache.commons.vfs2.provider.sftp.SftpFileSystem.getChannel
> (SftpFileSystem.java:113)
> at org.apache.commons.vfs2.provider.sftp.SftpFileObject.doGetOutputStream
> (SftpFileObject.java:635)
> at org.apache.commons.vfs2.provider.AbstractFileObject.getOutputStream
> (AbstractFileObject.java:1399)
> at org.apache.commons.vfs2.provider.DefaultFileContent.getOutputStream
> (DefaultFileContent.java:479)
> at org.apache.commons.vfs2.provider.DefaultFileContent.getOutputStream
> (DefaultFileContent.java:457)
> Caused by: com.jcraft.jsch.JSchException: java.net.SocketException: Broken
> pipe (Write failed)
> at com.jcraft.jsch.Channel.connect (Channel.java:159)
> at com.jcraft.jsch.Channel.connect (Channel.java:145)
> at org.apache.commons.vfs2.provider.sftp.SftpFileSystem.getChannel
> (SftpFileSystem.java:113)
> at org.apache.commons.vfs2.provider.sftp.SftpFileObject.doGetOutputStream
> (SftpFileObject.java:635)
> at org.apache.commons.vfs2.provider.AbstractFileObject.getOutputStream
> (AbstractFileObject.java:1399)
> at org.apache.commons.vfs2.provider.DefaultFileContent.getOutputStream
> (DefaultFileContent.java:479)
> at org.apache.commons.vfs2.provider.DefaultFileContent.getOutputStream
> (DefaultFileContent.java:457)
> Caused by: java.io.IOException: inputstream is closed
> at com.jcraft.jsch.ChannelSftp.fill (ChannelSftp.java:2911)
> at com.jcraft.jsch.ChannelSftp.header (ChannelSftp.java:2935)
> at com.jcraft.jsch.ChannelSftp.checkStatus (ChannelSftp.java:2473)
> at com.jcraft.jsch.ChannelSftp.access$300 (ChannelSftp.java:36)
> at com.jcraft.jsch.ChannelSftp$1.flush (ChannelSftp.java:851)
> at java.io.BufferedOutputStream.flush (BufferedOutputStream.java:141)
> at org.apache.commons.vfs2.util.MonitorOutputStream.flush
> (MonitorOutputStream.java:134)
> at java.io.BufferedOutputStream.flush (BufferedOutputStream.java:141)
> at org.apache.commons.vfs2.util.MonitorOutputStream.flush
> (MonitorOutputStream.java:134)
> Caused by: com.jcraft.jsch.JSchException: session is down
> at com.jcraft.jsch.Channel.sendChannelOpen (Channel.java:762)
> at com.jcraft.jsch.Channel.connect (Channel.java:151)
> at com.jcraft.jsch.Channel.connect (Channel.java:145)
> at org.apache.commons.vfs2.provider.sftp.SftpFileSystem.getChannel
> (SftpFileSystem.java:113)
> at org.apache.commons.vfs2.provider.sftp.SftpFileObject.doGetOutputStream
> (SftpFileObject.java:635)
> at org.apache.commons.vfs2.provider.AbstractFileObject.getOutputStream
> (AbstractFileObject.java:1399)
> at org.apache.commons.vfs2.provider.DefaultFileContent.getOutputStream
> (DefaultFileContent.java:479)
> at org.apache.commons.vfs2.provider.DefaultFileContent.getOutputStream
> (DefaultFileContent.java:457)
> Caused by: java.net.SocketException: Broken pipe (Write failed)
> at java.net.SocketOutputStream.socketWrite0 (Native Method)
> at java.net.SocketOutputStream.socketWrite (SocketOutputStream.java:111)
> at java.net.SocketOutputStream.write (SocketOutputStream.java:155)
> at com.jcraft.jsch.IO.put (IO.java:60)
> at
[jira] [Work logged] (VFS-662) SftpFileSystem has Thread-safe issue about idleChannel
[
https://issues.apache.org/jira/browse/VFS-662?focusedWorklogId=234589=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-234589
]
ASF GitHub Bot logged work on VFS-662:
--
Author: ASF GitHub Bot
Created on: 29/Apr/19 15:49
Start Date: 29/Apr/19 15:49
Worklog Time Spent: 10m
Work Description: asfgit commented on pull request #36: fix for VFS-662:
SftpFileSystem has Thread-safe issue about idleChannel
URL: https://github.com/apache/commons-vfs/pull/36
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 234589)
Time Spent: 0.5h (was: 20m)
> SftpFileSystem has Thread-safe issue about idleChannel
> ---
>
> Key: VFS-662
> URL: https://issues.apache.org/jira/browse/VFS-662
> Project: Commons VFS
> Issue Type: Bug
>Reporter: qxo
>Priority: Critical
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {code}
> {code:java}
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not connect to
> SFTP server at
> at org.apache.commons.vfs2.provider.sftp.SftpFileSystem.getChannel
> (SftpFileSystem.java:149)
> at org.apache.commons.vfs2.provider.sftp.SftpFileObject.statSelf
> (SftpFileObject.java:152)
> at org.apache.commons.vfs2.provider.sftp.SftpFileObject.doGetType
> (SftpFileObject.java:113)
> at org.apache.commons.vfs2.provider.AbstractFileObject.getType
> (AbstractFileObject.java:1517)
> at org.apache.commons.vfs2.provider.sftp.SftpFileObject.refresh
> (SftpFileObject.java:90)
> at org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile
> (AbstractFileSystem.java:364)
> at org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile
> (AbstractFileSystem.java:317)
> at org.apache.commons.vfs2.provider.AbstractFileObject.resolveFile
> (AbstractFileObject.java:2039)
> at org.apache.commons.vfs2.FileObject$resolveFile$23.call (Unknown Source)
> Caused by: com.jcraft.jsch.JSchException: java.io.IOException: channel is
> broken
> at com.jcraft.jsch.ChannelSftp.start (ChannelSftp.java:315)
> at com.jcraft.jsch.Channel.connect (Channel.java:152)
> at com.jcraft.jsch.Channel.connect (Channel.java:145)
> at org.apache.commons.vfs2.provider.sftp.SftpFileSystem.getChannel
> (SftpFileSystem.java:113)
> at org.apache.commons.vfs2.provider.sftp.SftpFileObject.doGetOutputStream
> (SftpFileObject.java:635)
> at org.apache.commons.vfs2.provider.AbstractFileObject.getOutputStream
> (AbstractFileObject.java:1399)
> at org.apache.commons.vfs2.provider.DefaultFileContent.getOutputStream
> (DefaultFileContent.java:479)
> at org.apache.commons.vfs2.provider.DefaultFileContent.getOutputStream
> (DefaultFileContent.java:457)
> Caused by: com.jcraft.jsch.JSchException: java.net.SocketException: Broken
> pipe (Write failed)
> at com.jcraft.jsch.Channel.connect (Channel.java:159)
> at com.jcraft.jsch.Channel.connect (Channel.java:145)
> at org.apache.commons.vfs2.provider.sftp.SftpFileSystem.getChannel
> (SftpFileSystem.java:113)
> at org.apache.commons.vfs2.provider.sftp.SftpFileObject.doGetOutputStream
> (SftpFileObject.java:635)
> at org.apache.commons.vfs2.provider.AbstractFileObject.getOutputStream
> (AbstractFileObject.java:1399)
> at org.apache.commons.vfs2.provider.DefaultFileContent.getOutputStream
> (DefaultFileContent.java:479)
> at org.apache.commons.vfs2.provider.DefaultFileContent.getOutputStream
> (DefaultFileContent.java:457)
> Caused by: java.io.IOException: inputstream is closed
> at com.jcraft.jsch.ChannelSftp.fill (ChannelSftp.java:2911)
> at com.jcraft.jsch.ChannelSftp.header (ChannelSftp.java:2935)
> at com.jcraft.jsch.ChannelSftp.checkStatus (ChannelSftp.java:2473)
> at com.jcraft.jsch.ChannelSftp.access$300 (ChannelSftp.java:36)
> at com.jcraft.jsch.ChannelSftp$1.flush (ChannelSftp.java:851)
> at java.io.BufferedOutputStream.flush (BufferedOutputStream.java:141)
> at org.apache.commons.vfs2.util.MonitorOutputStream.flush
> (MonitorOutputStream.java:134)
> at java.io.BufferedOutputStream.flush (BufferedOutputStream.java:141)
> at org.apache.commons.vfs2.util.MonitorOutputStream.flush
> (MonitorOutputStream.java:134)
> Caused by: com.jcraft.jsch.JSchException: session is down
> at com.jcraft.jsch.Channel.sendChannelOpen (Channel.java:762)
> at com.jcraft.jsch.Channel.connect (Channel.java:151)
> at com.jcraft.jsch.Channel.connect (Channel.java:145)
> at org.apache.commons.vfs2.provider.sftp.SftpFileSystem.getChannel
> (SftpFileSystem.java:113)
> at
[GitHub] [commons-vfs] asfgit closed pull request #36: fix for VFS-662: SftpFileSystem has Thread-safe issue about idleChannel
asfgit closed pull request #36: fix for VFS-662: SftpFileSystem has Thread-safe issue about idleChannel URL: https://github.com/apache/commons-vfs/pull/36 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] abashev commented on issue #61: Fix CI builds for Java 11
abashev commented on issue #61: Fix CI builds for Java 11 URL: https://github.com/apache/commons-vfs/pull/61#issuecomment-487633110 @garydgregory done This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] abashev commented on issue #36: fix for VFS-662: SftpFileSystem has Thread-safe issue about idleChannel
abashev commented on issue #36: fix for VFS-662: SftpFileSystem has Thread-safe issue about idleChannel URL: https://github.com/apache/commons-vfs/pull/36#issuecomment-487626118 > This PR has nothing to do with concurrency but as I said @abashev's fork of VFS has some fixes in it which he wants to merge - and this PR is just the first one of a few to come as far as I understand. @garydgregory Yes, it will be my first submission into commons-vfs project and I want to understand how it works and the whole process. It looks like pom file was changed so I did rebase on latest master for this one https://github.com/apache/commons-vfs/pull/54 and add one more to fix Java 11 builds https://github.com/apache/commons-vfs/pull/61 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] garydgregory commented on issue #61: Fix CI builds for Java 11
garydgregory commented on issue #61: Fix CI builds for Java 11 URL: https://github.com/apache/commons-vfs/pull/61#issuecomment-487624983 You need to redo this PR: there appear to be many noisy changes due to line-ending changes or whitespace tab vs. space changes, or I do not know what. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] abashev opened a new pull request #61: Fix CI builds for Java 11
abashev opened a new pull request #61: Fix CI builds for Java 11 URL: https://github.com/apache/commons-vfs/pull/61 Bugfix for broken TLS 1.3 in latest Java 11 https://bugs.openjdk.java.net/browse/JDK-8211806 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Resolved] (VFS-711) [SFTP] SftpFileSystem can initialize underlying Session more than once while multithreading
[ https://issues.apache.org/jira/browse/VFS-711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved VFS-711. -- Resolution: Fixed In git master. > [SFTP] SftpFileSystem can initialize underlying Session more than once while > multithreading > --- > > Key: VFS-711 > URL: https://issues.apache.org/jira/browse/VFS-711 > Project: Commons VFS > Issue Type: Bug >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 2.4 > > > [SFTP] SftpFileSystem.getUid() can initialize underlying data more than once > while multithreading. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (VFS-711) [SFTP] SftpFileSystem can initialize underlying Session more than once while multithreading
Gary Gregory created VFS-711: Summary: [SFTP] SftpFileSystem can initialize underlying Session more than once while multithreading Key: VFS-711 URL: https://issues.apache.org/jira/browse/VFS-711 Project: Commons VFS Issue Type: Bug Reporter: Gary Gregory Assignee: Gary Gregory Fix For: 2.4 [SFTP] SftpFileSystem.getUid() can initialize underlying data more than once while multithreading. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (VFS-710) [SFTP] SftpFileSystem.getUid() can initialize underlying data more than once while multithreading
[ https://issues.apache.org/jira/browse/VFS-710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed VFS-710. Resolution: Fixed In git master. > [SFTP] SftpFileSystem.getUid() can initialize underlying data more than once > while multithreading > - > > Key: VFS-710 > URL: https://issues.apache.org/jira/browse/VFS-710 > Project: Commons VFS > Issue Type: Bug >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 2.4 > > > [SFTP] SftpFileSystem.getUid() can initialize underlying data more than once > while multithreading. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (STATISTICS-7) Stream-based Java statistical processing
[
https://issues.apache.org/jira/browse/STATISTICS-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16829243#comment-16829243
]
Gilles commented on STATISTICS-7:
-
Hi [~Udit Arora],
{quote}this is kinda fun...
{quote}
Glad to hear. :)
Such small changes can indeed be a good opportunity to learn the process:
# File an appropriate JIRA report: Almost every modification must be tracked
(a notable exception is made for Javadoc improvement, e.g. correcting typos, or
adding more unit tests, e.g. to improve code coverage).
# The commit message should be prepended by the name of the JIRA ticket (e.g.
"STATISTICS-123: ..."). See the output of the "git log" for examples of how
detailed the message should be.
Long time committers sometimes omit to open a JIRA ticket, but that should not
be emulated. ;)
# Describe the changes in the commit message: It's obvious that the commit
contains a "change", but the reviewer should know, by reading the commit
message, what was the purpose of the change.
# It's always good to specify that you ran the unit test suite, and that the
change is covered, and still produce the expected results. Side-note: We should
ask INFRA to activate [Travis|https://travis-ci.org/apache/commons-statistics]
for "Commons Statistics".
> Stream-based Java statistical processing
>
>
> Key: STATISTICS-7
> URL: https://issues.apache.org/jira/browse/STATISTICS-7
> Project: Apache Commons Statistics
> Issue Type: New Feature
>Reporter: Eric Barnhill
>Priority: Major
> Labels: GSoC2019, gsoc2019, statistics, streams
>
> The new component aims to be a library of commons statistics functions
> synchronized with the latest developments in the Java language, in particular
> Java's functional programming syntax.
> The library will make commonly used statistical functions available to an end
> user through a simple grammar comparable to commons-math-statistics or
> scikit-learn, while under the hood will implement Java's mapping, streaming,
> and other producer and consumer functions to ensure the statistical methods
> run optimally in new Java implementations.
> As functional programming grows increasingly central to big data applications
> we believe these libraries will play an important function in the data
> engineering ecosystem. In particular, data engineering is widely done with
> Java, then passed to other languages for data-scientific analyses; however,
> the common availability of functionally implemented statistical mapping and
> reductions in Java could prove very useful at the interface of data science
> and engineering, by enabling teams to more easily perform reductions on the
> engineering side before handing off to the analysis side.
> Developers working on the project will have the opportunity to demonstrate
> Java programming, functional programming, algorithm design, and data science
> skills and receive authorship on a commons project that is likely to be
> widely used.
> The ideal contributor will also be able to help with important architectural
> decision making. The old source of these libraries, commons-math, grew too
> large, hierarchically complex and interdependent for the commons mission. The
> developers on this project need to make architectural choices that will
> enable the statiscal code to be lightweight and reusable, with a minimum of
> outside dependencies while avoiding redundancy.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-vfs] garydgregory edited a comment on issue #36: fix for VFS-662: SftpFileSystem has Thread-safe issue about idleChannel
garydgregory edited a comment on issue #36: fix for VFS-662: SftpFileSystem has Thread-safe issue about idleChannel URL: https://github.com/apache/commons-vfs/pull/36#issuecomment-487569796 So, in the DCL+volatile dept, I did this: https://github.com/apache/commons-vfs/blob/master/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/sftp/SftpFileSystem.java#L220-L242 In this case, a single ivar is in play in one place. Reference: https://issues.apache.org/jira/browse/VFS-709 This should be the same for `uid`. Reference: https://issues.apache.org/jira/browse/VFS-710 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (VFS-710) [SFTP] SftpFileSystem.getUid() can initialize underlying data more than once while multithreading
[ https://issues.apache.org/jira/browse/VFS-710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated VFS-710: - Description: [SFTP] SftpFileSystem.getUid() can initialize underlying data more than once while multithreading. (was: [SFTP] SftpFileSystem.getGroupsIds() can initialize underlying data more than once while multithreading.) > [SFTP] SftpFileSystem.getUid() can initialize underlying data more than once > while multithreading > - > > Key: VFS-710 > URL: https://issues.apache.org/jira/browse/VFS-710 > Project: Commons VFS > Issue Type: Bug >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 2.4 > > > [SFTP] SftpFileSystem.getUid() can initialize underlying data more than once > while multithreading. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (VFS-710) [SFTP] SftpFileSystem.getUid() can initialize underlying data more than once while multithreading
Gary Gregory created VFS-710: Summary: [SFTP] SftpFileSystem.getUid() can initialize underlying data more than once while multithreading Key: VFS-710 URL: https://issues.apache.org/jira/browse/VFS-710 Project: Commons VFS Issue Type: Bug Reporter: Gary Gregory Assignee: Gary Gregory Fix For: 2.4 [SFTP] SftpFileSystem.getGroupsIds() can initialize underlying data more than once while multithreading. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-vfs] garydgregory edited a comment on issue #36: fix for VFS-662: SftpFileSystem has Thread-safe issue about idleChannel
garydgregory edited a comment on issue #36: fix for VFS-662: SftpFileSystem has Thread-safe issue about idleChannel URL: https://github.com/apache/commons-vfs/pull/36#issuecomment-487569796 So, in the DCL+volatile dept, I did this: https://github.com/apache/commons-vfs/blob/master/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/sftp/SftpFileSystem.java#L220-L242 In this case, a single ivar is in play in one place. Reference: https://issues.apache.org/jira/browse/VFS-709 This should be the same for `uid`. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] garydgregory edited a comment on issue #36: fix for VFS-662: SftpFileSystem has Thread-safe issue about idleChannel
garydgregory edited a comment on issue #36: fix for VFS-662: SftpFileSystem has Thread-safe issue about idleChannel URL: https://github.com/apache/commons-vfs/pull/36#issuecomment-487569796 So, in the DCL+volatile dept, I did this: https://github.com/apache/commons-vfs/blob/master/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/sftp/SftpFileSystem.java#L220-L242 In this case, a single ivar is in play in one place. Reference: https://issues.apache.org/jira/browse/VFS-709 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] garydgregory commented on issue #36: fix for VFS-662: SftpFileSystem has Thread-safe issue about idleChannel
garydgregory commented on issue #36: fix for VFS-662: SftpFileSystem has Thread-safe issue about idleChannel URL: https://github.com/apache/commons-vfs/pull/36#issuecomment-487569796 So, in the DCL+volatile dept, I did this: https://github.com/apache/commons-vfs/blob/master/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/sftp/SftpFileSystem.java#L220-L242 In this case, a single ivar is in play in one place. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Closed] (VFS-709) [SFTP] SftpFileSystem.getGroupsIds() can initialize underlying data more than once while multithreading
[ https://issues.apache.org/jira/browse/VFS-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed VFS-709. Resolution: Fixed Fix Version/s: 2.4 In git master. > [SFTP] SftpFileSystem.getGroupsIds() can initialize underlying data more than > once while multithreading > --- > > Key: VFS-709 > URL: https://issues.apache.org/jira/browse/VFS-709 > Project: Commons VFS > Issue Type: Bug >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 2.4 > > > [SFTP] SftpFileSystem.getGroupsIds() can initialize underlying data more than > once while multithreading. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (VFS-709) [SFTP] SftpFileSystem.getGroupsIds() can initialize underlying data more than once while multithreading
Gary Gregory created VFS-709: Summary: [SFTP] SftpFileSystem.getGroupsIds() can initialize underlying data more than once while multithreading Key: VFS-709 URL: https://issues.apache.org/jira/browse/VFS-709 Project: Commons VFS Issue Type: Bug Reporter: Gary Gregory Assignee: Gary Gregory [SFTP] SftpFileSystem.getGroupsIds() can initialize underlying data more than once while multithreading. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (VFS-609) SFTP provider doesn't support a private key as byte array
[ https://issues.apache.org/jira/browse/VFS-609?focusedWorklogId=234489=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-234489 ] ASF GitHub Bot logged work on VFS-609: -- Author: ASF GitHub Bot Created on: 29/Apr/19 12:27 Start Date: 29/Apr/19 12:27 Worklog Time Spent: 10m Work Description: RoTkay commented on pull request #60: VFS-609: VFS SFTP doesn't support a private key as byte array URL: https://github.com/apache/commons-vfs/pull/60 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 234489) Time Spent: 20m (was: 10m) > SFTP provider doesn't support a private key as byte array > - > > Key: VFS-609 > URL: https://issues.apache.org/jira/browse/VFS-609 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 2.1 > Environment: Java client running on Windows 7 >Reporter: stevezhuang >Priority: Minor > Fix For: 2.4 > > Attachments: IdentityInfo.java, SftpClientFactory.java > > Time Spent: 20m > Remaining Estimate: 0h > > Sometimes we would store the private key as a string\bytes in the remote > server site, and then access the SFTP functions, > The JSCH API already provides a possibility to add the private key as bytes, > while VFS doesn't support so, > JSch.java > public void addIdentity(String name, byte[] prvkey, byte[] pubkey, byte[] > passphrase) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-vfs] RoTkay closed pull request #60: VFS-609: VFS SFTP doesn't support a private key as byte array
RoTkay closed pull request #60: VFS-609: VFS SFTP doesn't support a private key as byte array URL: https://github.com/apache/commons-vfs/pull/60 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] RoTkay commented on issue #60: VFS-609: VFS SFTP doesn't support a private key as byte array
RoTkay commented on issue #60: VFS-609: VFS SFTP doesn't support a private key as byte array URL: https://github.com/apache/commons-vfs/pull/60#issuecomment-487559722 Okey, saw your solution. Thanks for adding bytes approach! And thanks for your comments too :) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] garydgregory commented on issue #36: fix for VFS-662: SftpFileSystem has Thread-safe issue about idleChannel
garydgregory commented on issue #36: fix for VFS-662: SftpFileSystem has Thread-safe issue about idleChannel URL: https://github.com/apache/commons-vfs/pull/36#issuecomment-487553780 Well, let just deal with `SftpFileSystem` here... we can await for other PRs to come in... Gary This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] boris-petrov commented on issue #36: fix for VFS-662: SftpFileSystem has Thread-safe issue about idleChannel
boris-petrov commented on issue #36: fix for VFS-662: SftpFileSystem has Thread-safe issue about idleChannel URL: https://github.com/apache/commons-vfs/pull/36#issuecomment-487551862 > The `session` ivar is not final and gets written in the private method `ensureSession()`, so it is possible for it to get initialized multiple times in a race-condition. The method `getChannel()` can end up writing to both `session` and `idleChanne`, so both values need to be published to other threads. The simplest way to do this is to synchronize the `getChannel()` method. > > Thoughts? Well, in that case there is still a race-condition because of the `executeCommand` method which also calls `ensureSession` so I guess it also should be `synchronized`...? > I do not see anything in that PR about concurrency. That PR just fiddles with POMs. What am I missing? This PR has nothing to do with concurrency but as I said @abashev's fork of VFS has some fixes in it which he wants to merge - and this PR is just the first one of a few to come as far as I understand. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] garydgregory commented on issue #60: VFS-609: VFS SFTP doesn't support a private key as byte array
garydgregory commented on issue #60: VFS-609: VFS SFTP doesn't support a private key as byte array URL: https://github.com/apache/commons-vfs/pull/60#issuecomment-487551530 Please see git master and the new class `org.apache.commons.vfs2.provider.sftp.BytesIdentityInfo`. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] garydgregory commented on issue #36: fix for VFS-662: SftpFileSystem has Thread-safe issue about idleChannel
garydgregory commented on issue #36: fix for VFS-662: SftpFileSystem has Thread-safe issue about idleChannel URL: https://github.com/apache/commons-vfs/pull/36#issuecomment-487550969 > @garydgregory, @ottobackwards - in that regards, please take a look at [this PR](https://github.com/apache/commons-vfs/pull/54) which is by @abashev. In his S3 provider he uses a fork of VFS in which he claims he's fixed a number of concurrency issues. He wants to merge them in the upstream repo (this one) so please take a look at the PR I linked (and accept it/comment on it) so he can continue on with the real issues he thinks he's resolved. I do not see anything in that PR about concurrency. That PR just fiddles with POMs. What am I missing? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] garydgregory commented on issue #36: fix for VFS-662: SftpFileSystem has Thread-safe issue about idleChannel
garydgregory commented on issue #36: fix for VFS-662: SftpFileSystem has Thread-safe issue about idleChannel URL: https://github.com/apache/commons-vfs/pull/36#issuecomment-487550096 Hi All: Back to https://github.com/apache/commons-vfs/pull/36#issuecomment-487393002: The `session` ivar is not final and gets written in the private method `ensureSession()`, so it is possible for it to get initialized multiple times in a race-condition. The method `getChannel()` can end up writing to both `session` and `idleChanne`, so both values need to be published to other threads. The simplest way to do this is to synchronize the `getChannel()` method. Thoughts? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] boris-petrov commented on issue #36: fix for VFS-662: SftpFileSystem has Thread-safe issue about idleChannel
boris-petrov commented on issue #36: fix for VFS-662: SftpFileSystem has Thread-safe issue about idleChannel URL: https://github.com/apache/commons-vfs/pull/36#issuecomment-487548091 @garydgregory, @ottobackwards - in that regards, please take a look at [this PR](https://github.com/apache/commons-vfs/pull/54) which is by @abashev. In his S3 provider he uses a fork of VFS in which he claims he's fixed a number of concurrency issues. He wants to merge them in the upstream repo (this one) so please take a look at the PR I linked (and accept it/comment on it) so he can continue on with the real issues he thinks he's resolved. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] garydgregory commented on issue #36: fix for VFS-662: SftpFileSystem has Thread-safe issue about idleChannel
garydgregory commented on issue #36: fix for VFS-662: SftpFileSystem has Thread-safe issue about idleChannel URL: https://github.com/apache/commons-vfs/pull/36#issuecomment-487547136 I'll second @boris-petrov's comment. We've been patching problems here and there when they pop up. I'm sure there are plenty of MT issues here and there. YMMV with each provider. The core probably has it's own issues too. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] boris-petrov commented on issue #36: fix for VFS-662: SftpFileSystem has Thread-safe issue about idleChannel
boris-petrov commented on issue #36: fix for VFS-662: SftpFileSystem has Thread-safe issue about idleChannel URL: https://github.com/apache/commons-vfs/pull/36#issuecomment-487544065 @ottobackwards - well, I've been using VFS for a while now in a multi-threaded environment and it mostly works fine. There are some issues here and there but I think they will be resolved one by one and all will be good in the end. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] ottobackwards commented on issue #36: fix for VFS-662: SftpFileSystem has Thread-safe issue about idleChannel
ottobackwards commented on issue #36: fix for VFS-662: SftpFileSystem has Thread-safe issue about idleChannel URL: https://github.com/apache/commons-vfs/pull/36#issuecomment-487534197 I'm just going to raise my hand and say from what I've seen, I didn't think VFS was thread safe. Even though some bugs like this have been fixed from time to time, in the main I don't think it is is it? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (LANG-1454) ToStringStyle.appendClassName() should use isUseShortClassName()
Giorgio Vespucci created LANG-1454:
--
Summary: ToStringStyle.appendClassName() should use
isUseShortClassName()
Key: LANG-1454
URL: https://issues.apache.org/jira/browse/LANG-1454
Project: Commons Lang
Issue Type: Bug
Components: lang.builder.*
Affects Versions: 3.8.1
Reporter: Giorgio Vespucci
I tried to implement a custom {{ToStringStyle}} and I wanted to get the short
class name in the printed text. My first thought was to override the method
{{isUseShortClassName}} in the subclass to make it returns always {{true}}, but
unexpectedly this didn't work, as the {{protected}} method
{{appendClassName(final StringBuffer buffer, final Object object)}} doesn't use
the boolean getter and directly access the {{private boolean
useShortClassName}} member.
I think the {{appendClassName}} method should act the same way, for example,
the method {{appendIdentityHashCode}} does, i.e. accessing the {{private
boolean useIdentityHashCode}} by its getter.
Thank you.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16828942#comment-16828942
]
Gilles commented on GEOMETRY-32:
bq. not hold up progress on other issues that might depend on this.
Are there such issues?
> BSPTree Updates
> ---
>
> Key: GEOMETRY-32
> URL: https://issues.apache.org/jira/browse/GEOMETRY-32
> Project: Apache Commons Geometry
> Issue Type: Improvement
> Components: core
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The following updates should be made to the BSPTree class:
> - add an {{isLeaf()}} method to replace all of the {{node.getCut() == null}}
> expressions
> - add unit tests
> _Edit [2019-02-17]:_
> Additional goals:
> - Refactor the API to split the idea of a general BSPTree and a BSPTree used
> for defining in/out regions. This could result in a BSPTree interface and a
> RegionBSPTree interface. The goal here is to allow end-users to create their
> own extensions of these classes and specialize them for their own
> applications (for example, to implement spatial sorting or other algorithms).
> This will be one of the only planned extension points in the library.
> - Make the API easier to use and extend and reduce the necessity of casting
> (especially unchecked casting) as much as possible.
> - Add the idea of convex subhyperplanes to allow for more efficient tree
> construction.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
