[jira] [Commented] (NET-408) problem connecting to ProFTPD with FTPES

[Jouko Toivonoja (Jira)]

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

Jouko Toivonoja commented on NET-408:
-

[~elichtas] I was able to solve this by using the workaround from Cyberduck as 
same as [~mperktold] did.
{code:java}
// Extended implementation using https://trac.cyberduck.io/changeset/10760
public class FTPSClient_withSessionReuse extends FTPSClient {
boolean sessionReuse = false;public FTPSClient_withSessionReuse(boolean 
ftpsIsImplict, SSLContext sc,
boolean sessionReuse) {
super(ftpsIsImplict, sc);
this.sessionReuse = sessionReuse;
}public FTPSClient_withSessionReuse(boolean ftpsIsImplict, SSLContext 
sc) {
super(ftpsIsImplict, sc);
}public FTPSClient_withSessionReuse(boolean ftpsIsImplict) {
super(ftpsIsImplict);
}
// adapted from: https://trac.cyberduck.io/changeset/10760
@Override
protected void _prepareDataSocket_(final Socket socket) throws IOException {
// If session reuse not selected, then go with the original code
if (!sessionReuse) {
super._prepareDataSocket_(socket);
return;
}if (socket instanceof SSLSocket) {
final SSLSession session = ((SSLSocket) _socket_).getSession();
final SSLSessionContext context = session.getSessionContext();
try {
final Field sessionHostPortCache = context.getClass()
.getDeclaredField("sessionHostPortCache");
sessionHostPortCache.setAccessible(true);
final Object cache = sessionHostPortCache.get(context);
final Method putMethod = cache.getClass().getDeclaredMethod(
"put", Object.class, Object.class);
putMethod.setAccessible(true);
final Method getHostMethod = socket.getClass()
.getDeclaredMethod("getHost");
getHostMethod.setAccessible(true);
Object host = getHostMethod.invoke(socket);
final String key = String.format("%s:%s", host,
String.valueOf(socket.getPort())).toLowerCase(
Locale.ROOT);
putMethod.invoke(cache, key, session);
} catch (Exception e) {
// throw TransferException e
}
}
}}
{code}

> problem connecting to ProFTPD with FTPES
> 
>
> Key: NET-408
> URL: https://issues.apache.org/jira/browse/NET-408
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 2.2, 3.0
> Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1 
> 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
> ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
> Java 1.5
>Reporter: Michael Voigt
>Priority: Major
> Attachments: BCFTPSClient.java, FTPSClientWithTLSResumption.zip, 
> PTFTPSClient.java, ftpes.jpg, proftpd.conf
>
>
> I have a problem with the FTPClient connecting to a ProFTPD server.
> If the server uses the configuration option "TLSProtocol TLSv1", I
> cannot connect to it at all. I recieve the following error message:
> - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
> On the server side I see in the log:
> unable to accept TLS connection: protocol error:
> -  (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate unknown
> - TLS/TLS-C negotiation failed on control channel
> If the server uses the configuration option "TLSProtocol SSLv23", I
> can connect to it but I cant transfer any files. In the server log I
> see:
> - starting TLS negotiation on data connection
> - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
> - client did not reuse SSL session, rejecting data connection (see
> TLSOption NoSessionReuseRequired)
> - unable to open data connection: TLS negotiation failed
> If I add the NoSessionReuseRequired parameter to the ProFTPD config
> everything works fine.
> Here is my code:
>FTPClient ftpClient = new FTPClient();
>ftpClient = new FTPSClient("TLS");
>// this throws an exception with TLSProtocol TLSv1
>ftpClient.connect(host, port);
>int reply = ftpClient.getReplyCode();
>if (!FTPReply.isPositiveCompletion(reply)) {
>ftpClient.disconnect();
>log.error("The FTP Server did not return a positive 
> completion reply!");
>throw new 
> FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
>}
>boolean loginSuccessful = ftpClient.login(userName, password);
>if 

[jira] [Deleted] (COMMONSSITE-136) منصةشليله

[Michael Osipov (Jira)]

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

Michael Osipov deleted COMMONSSITE-136:
---


> منصةشليله 
> --
>
> Key: COMMONSSITE-136
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-136
> Project: Apache Commons All
>  Issue Type: New Feature
> Environment: [https://github.com/Shliilh2/license-list-XML.git]
> https://shliilhplatform.com.sa 
>Reporter: منصة شليله
>Priority: Major
>  Labels: GCP, patch
>
> (منصةشليله)
> Android web All Al Ai TV Automatic robot shliilhplatform gmrshliilh 
> ihdadi.com Apache APK app etc. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (COMPRESS-539) TarArchiveInputStream allocates a lot of memory when iterating through an archive

[Robin Schimpf (Jira)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152491#comment-17152491
 ] 

Robin Schimpf commented on COMPRESS-539:


{{I guess the entries are pretty small (a few kilobytes)}}

Your assumption is correct. I used the linux source tarball and there were no 
differences between {{read}} and {{skip}}.

> TarArchiveInputStream allocates a lot of memory when iterating through an 
> archive
> -
>
> Key: COMPRESS-539
> URL: https://issues.apache.org/jira/browse/COMPRESS-539
> Project: Commons Compress
>  Issue Type: Bug
>Affects Versions: 1.20
>Reporter: Robin Schimpf
>Assignee: Peter Lee
>Priority: Major
> Attachments: Don't_call_InputStream#skip.patch, 
> Reuse_recordBuffer.patch, image-2020-06-21-10-58-07-917.png, 
> image-2020-06-21-10-58-43-255.png, image-2020-06-21-10-59-10-825.png, 
> image-2020-07-05-22-10-07-402.png, image-2020-07-05-22-11-25-526.png, 
> image-2020-07-05-22-32-15-131.png, image-2020-07-05-22-32-31-511.png
>
>
>  I iterated through the linux source tar and noticed some unneeded 
> allocations happen without extracting any data.
> Reproducing code
> {code:java}
> File tarFile = new File("linux-5.7.1.tar");
> try (TarArchiveInputStream in = new 
> TarArchiveInputStream(Files.newInputStream(tarFile.toPath( {
> TarArchiveEntry entry;
> while ((entry = in.getNextTarEntry()) != null) {
> }
> }
> {code}
> The measurement was done on Java 11.0.7 with the Java Flight Recorder. 
> Options used: 
> -XX:StartFlightRecording=settings=profile,filename=allocations.jfr
> Baseline with the current master implementation:
>  Estimated TLAB allocation: 293MiB
> !image-2020-06-21-10-58-07-917.png!
> 1. IOUtils.skip -> input.skip(numToSkip)
>  This delegates in my test scenario to the InputStream.skip implementation 
> which allocates a new byte[] for every invocation. By simply commenting out 
> the while loop which calls the skip method the estimated TLAB allocation 
> drops to 164MiB (-129MiB).
>  !image-2020-06-21-10-58-43-255.png! 
>  Commenting out the skip call does not seem to be the best solution but it 
> was quick for me to see how much memory can be saved. Also no unit tests 
> where failing for me.
> 2. TarArchiveInputStream.readRecord
>  For every read of the record a new byte[] is created. Since the record size 
> does not change the byte[] can be reused and created when instantiating the 
> TarStream. This optimization is already present in the 
> TarArchiveOutputStream. Reusing the buffer reduces the estimated TLAB 
> allocations further to 128MiB (-36MiB).
>  !image-2020-06-21-10-59-10-825.png!
> I attached the patches I used so the results can be verified.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (GEOMETRY-100) Invalid result for small spherical polygons

[Matt Juntunen (Jira)]

[ 
https://issues.apache.org/jira/browse/GEOMETRY-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152440#comment-17152440
 ] 

Matt Juntunen commented on GEOMETRY-100:


Also, you marked this as a blocker. Does this mean that you consider this as a 
blocker for beta1?

> Invalid result for small spherical polygons
> ---
>
> Key: GEOMETRY-100
> URL: https://issues.apache.org/jira/browse/GEOMETRY-100
> Project: Apache Commons Geometry
>  Issue Type: Bug
>Reporter: Baljit Singh
>Priority: Blocker
> Fix For: 1.0
>
>
> h2. First test case: small spherical rectangle
> * Precision/Tolerance: {{EpsilonDoublePrecisionContext[epsilon= 
> 1.5696101377226165E-12]}}
> * Spherical polygon/rectangle vertices: {{[(5.050647792392463, 
> 0.8263048984534946), (5.050644504477406, 0.8263064367456399), 
> (5.050649564478115, 0.8263123289902004), (5.050652852378331, 
> 0.8263107907013917)]}}
> h4. Centroid:
> * Expected (approximately the average of vertices): {{(5.050648678475973, 
> 0.8263086112510253)}}
> * Actual: {{(5.0506454742491504, 0.8263177505886343)}}
> The difference looks small, however, the actual result is outside the polygon.
> h4. Area (size):
> * Expected: 2.0005645375711432E-11
> * Actual: 1.9971579945377016E-11
> h4. Perimeter (boundary size):
> * Expected: 1.9679779440894825E-5
> * Actual: 1.96697104639384E-5
> h2. Second test case: small circular (sphere) polygon
> * Precision/Tolerance: {{EpsilonDoublePrecisionContext[epsilon= 
> 1.5696101377226165E-12]}}
> * Circle discretized with 100 vertices: center: {{(0.5410520681182421, 
> 1.3962634015954636)}}, radius: {{4.784171699778536E-8}}
> h4. Centroid:
> * Expected (approximately circle center): {{(0.5410520681182421, 
> 1.3962634015954636)}}
> * Actual: {{null}}
> h4. Area (size):
> * Expected: 7.181590857887451E-15
> * Actual: 0.0
> h4. Perimeter (boundary size):
> * Expected: 3.0054894917112657E-7
> * Actual: 3.005489492811408E-7



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (GEOMETRY-100) Invalid result for small spherical polygons

[Matt Juntunen (Jira)]

[ 
https://issues.apache.org/jira/browse/GEOMETRY-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152398#comment-17152398
 ] 

Matt Juntunen commented on GEOMETRY-100:


Sounds reasonable. Where would this change need to take place?

> Invalid result for small spherical polygons
> ---
>
> Key: GEOMETRY-100
> URL: https://issues.apache.org/jira/browse/GEOMETRY-100
> Project: Apache Commons Geometry
>  Issue Type: Bug
>Reporter: Baljit Singh
>Priority: Blocker
> Fix For: 1.0
>
>
> h2. First test case: small spherical rectangle
> * Precision/Tolerance: {{EpsilonDoublePrecisionContext[epsilon= 
> 1.5696101377226165E-12]}}
> * Spherical polygon/rectangle vertices: {{[(5.050647792392463, 
> 0.8263048984534946), (5.050644504477406, 0.8263064367456399), 
> (5.050649564478115, 0.8263123289902004), (5.050652852378331, 
> 0.8263107907013917)]}}
> h4. Centroid:
> * Expected (approximately the average of vertices): {{(5.050648678475973, 
> 0.8263086112510253)}}
> * Actual: {{(5.0506454742491504, 0.8263177505886343)}}
> The difference looks small, however, the actual result is outside the polygon.
> h4. Area (size):
> * Expected: 2.0005645375711432E-11
> * Actual: 1.9971579945377016E-11
> h4. Perimeter (boundary size):
> * Expected: 1.9679779440894825E-5
> * Actual: 1.96697104639384E-5
> h2. Second test case: small circular (sphere) polygon
> * Precision/Tolerance: {{EpsilonDoublePrecisionContext[epsilon= 
> 1.5696101377226165E-12]}}
> * Circle discretized with 100 vertices: center: {{(0.5410520681182421, 
> 1.3962634015954636)}}, radius: {{4.784171699778536E-8}}
> h4. Centroid:
> * Expected (approximately circle center): {{(0.5410520681182421, 
> 1.3962634015954636)}}
> * Actual: {{null}}
> h4. Area (size):
> * Expected: 7.181590857887451E-15
> * Actual: 0.0
> h4. Perimeter (boundary size):
> * Expected: 3.0054894917112657E-7
> * Actual: 3.005489492811408E-7



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (VALIDATOR-429) UrlValidator - path is invalid due to using java.net.URI for validation (regression)

[Ivan Larionov (Jira)]

[ 
https://issues.apache.org/jira/browse/VALIDATOR-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152362#comment-17152362
 ] 

Ivan Larionov commented on VALIDATOR-429:
-

Should be fixed in VALIDATOR-467.

> UrlValidator - path is invalid due to using java.net.URI for validation 
> (regression)
> 
>
> Key: VALIDATOR-429
> URL: https://issues.apache.org/jira/browse/VALIDATOR-429
> Project: Commons Validator
>  Issue Type: Bug
>  Components: Routines
>Affects Versions: 1.6
>Reporter: limpygnome
>Priority: Major
>  Labels: easyfix
>
> h1. Summary
> We've been hit by a bug in a real world application after upgrading 1.4.1 to 
> 1.6, where previously valid URLs are no longer valid, which looks to be due 
> to using java.net.URI for validating the path of a URL.
> h1. Steps to Reproduce
> Our application went to validate URLs similar to the following:
> * http://example.com//_test
> This is no longer valid in 1.6.1, but the following cases are:
> * http://example.com//test
> * http://example.com/_test
> h1. Impact
> It seems paths in UrlValidator are being parsed/validated as host-names, per 
> java.net.URI's validation.
> h1. Technical
> It looks like this may have been introduced by the following change:
> https://github.com/apache/commons-validator/commit/03bf0d33143ebd13e4f389cd4ecac8aec17c2057
> Specifically due to now using java.net.URI to validate a path. The usage is 
> as follows in org.apache.commons.validator.routines.UrlValidator:
> {code}
> URI uri = new URI(null,null,path,null);
> {code}
> It looks like URI is trying to parse the path as a hostname when the schema 
> and hostname are not specified.
> Example to reproduce:
> {code}
> new URI(null, null, "//_test", null);   // throws URISyntaxException
> {code}
> Same example with other parts, no longer throwing exception:
> {code}
> new URI(null, "test", "//_test", null);
> {code}
> Even though java.net.URI states string components can be null, it seems the 
> URL built internally, which is validated, is slightly different. So when 
> specifying a hostname with URI, internally it constructs:
> * //test//_test
> Using no hostname, in the same way as UrlValidator, the following is 
> constructed and validated internally:
> * //_test
> Therefore it looks like there's either a bug in java.net.URI, or its usage is 
> not correctly documented.
> h1. Fix
> A potential fix is to change 
> org.apache.commons.validator.routines.UrlValidator to pass an empty string in 
> the hostname. Internally, in java.net.URI, this produces:
> * _test
> Thus the hostname is empty, which is considered empty, and the correct path 
> is validated.
> Would this fix be appropriate, or considered too fragile?
> Alternatively the fix could be to extract similar logic to java.net.URI, to 
> validate the path, which appears to be just checking the characters are valid 
> and between a certain range. This logic can be seen in 
> java.net.URI.parseHierarchical, which calls upon checkChars.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (GEOMETRY-100) Invalid result for small spherical polygons

[Baljit Singh (Jira)]

[ 
https://issues.apache.org/jira/browse/GEOMETRY-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152357#comment-17152357
 ] 

Baljit Singh commented on GEOMETRY-100:
---

Digging into the code, I think there is a flaw in the usage of 
{{EuclideanVector.eq(V v, DoublePrecisionContext precision)}}. {{eq}} is a 
component-wise comparison with tolerance. However, the tolerance should be 
applied based on the metric of the space. In Euclidean space, it should be 
applied to the Cartesian distance between two vectors. In Spherical space, it 
should be applied to the angle between the vectors.

> Invalid result for small spherical polygons
> ---
>
> Key: GEOMETRY-100
> URL: https://issues.apache.org/jira/browse/GEOMETRY-100
> Project: Apache Commons Geometry
>  Issue Type: Bug
>Reporter: Baljit Singh
>Priority: Blocker
> Fix For: 1.0
>
>
> h2. First test case: small spherical rectangle
> * Precision/Tolerance: {{EpsilonDoublePrecisionContext[epsilon= 
> 1.5696101377226165E-12]}}
> * Spherical polygon/rectangle vertices: {{[(5.050647792392463, 
> 0.8263048984534946), (5.050644504477406, 0.8263064367456399), 
> (5.050649564478115, 0.8263123289902004), (5.050652852378331, 
> 0.8263107907013917)]}}
> h4. Centroid:
> * Expected (approximately the average of vertices): {{(5.050648678475973, 
> 0.8263086112510253)}}
> * Actual: {{(5.0506454742491504, 0.8263177505886343)}}
> The difference looks small, however, the actual result is outside the polygon.
> h4. Area (size):
> * Expected: 2.0005645375711432E-11
> * Actual: 1.9971579945377016E-11
> h4. Perimeter (boundary size):
> * Expected: 1.9679779440894825E-5
> * Actual: 1.96697104639384E-5
> h2. Second test case: small circular (sphere) polygon
> * Precision/Tolerance: {{EpsilonDoublePrecisionContext[epsilon= 
> 1.5696101377226165E-12]}}
> * Circle discretized with 100 vertices: center: {{(0.5410520681182421, 
> 1.3962634015954636)}}, radius: {{4.784171699778536E-8}}
> h4. Centroid:
> * Expected (approximately circle center): {{(0.5410520681182421, 
> 1.3962634015954636)}}
> * Actual: {{null}}
> h4. Area (size):
> * Expected: 7.181590857887451E-15
> * Actual: 0.0
> h4. Perimeter (boundary size):
> * Expected: 3.0054894917112657E-7
> * Actual: 3.005489492811408E-7



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (GEOMETRY-100) Invalid result for small spherical polygons

[Baljit Singh (Jira)]

[ 
https://issues.apache.org/jira/browse/GEOMETRY-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152343#comment-17152343
 ] 

Baljit Singh edited comment on GEOMETRY-100 at 7/6/20, 9:56 PM:


[~mattjuntunen] This issue is also present in Math3. The boundary size looks 
reasonable for both examples. However, the area and centroid are incorrect.


was (Author: balsingh):
[~mattjuntunen] This issue is also present in Math3.

> Invalid result for small spherical polygons
> ---
>
> Key: GEOMETRY-100
> URL: https://issues.apache.org/jira/browse/GEOMETRY-100
> Project: Apache Commons Geometry
>  Issue Type: Bug
>Reporter: Baljit Singh
>Priority: Blocker
> Fix For: 1.0
>
>
> h2. First test case: small spherical rectangle
> * Precision/Tolerance: {{EpsilonDoublePrecisionContext[epsilon= 
> 1.5696101377226165E-12]}}
> * Spherical polygon/rectangle vertices: {{[(5.050647792392463, 
> 0.8263048984534946), (5.050644504477406, 0.8263064367456399), 
> (5.050649564478115, 0.8263123289902004), (5.050652852378331, 
> 0.8263107907013917)]}}
> h4. Centroid:
> * Expected (approximately the average of vertices): {{(5.050648678475973, 
> 0.8263086112510253)}}
> * Actual: {{(5.0506454742491504, 0.8263177505886343)}}
> The difference looks small, however, the actual result is outside the polygon.
> h4. Area (size):
> * Expected: 2.0005645375711432E-11
> * Actual: 1.9971579945377016E-11
> h4. Perimeter (boundary size):
> * Expected: 1.9679779440894825E-5
> * Actual: 1.96697104639384E-5
> h2. Second test case: small circular (sphere) polygon
> * Precision/Tolerance: {{EpsilonDoublePrecisionContext[epsilon= 
> 1.5696101377226165E-12]}}
> * Circle discretized with 100 vertices: center: {{(0.5410520681182421, 
> 1.3962634015954636)}}, radius: {{4.784171699778536E-8}}
> h4. Centroid:
> * Expected (approximately circle center): {{(0.5410520681182421, 
> 1.3962634015954636)}}
> * Actual: {{null}}
> h4. Area (size):
> * Expected: 7.181590857887451E-15
> * Actual: 0.0
> h4. Perimeter (boundary size):
> * Expected: 3.0054894917112657E-7
> * Actual: 3.005489492811408E-7



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (GEOMETRY-100) Invalid result for small spherical polygons

[Baljit Singh (Jira)]

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

Baljit Singh updated GEOMETRY-100:
--
Description: 
h2. First test case: small spherical rectangle
* Precision/Tolerance: {{EpsilonDoublePrecisionContext[epsilon= 
1.5696101377226165E-12]}}
* Spherical polygon/rectangle vertices: {{[(5.050647792392463, 
0.8263048984534946), (5.050644504477406, 0.8263064367456399), 
(5.050649564478115, 0.8263123289902004), (5.050652852378331, 
0.8263107907013917)]}}

h4. Centroid:
* Expected (approximately the average of vertices): {{(5.050648678475973, 
0.8263086112510253)}}
* Actual: {{(5.0506454742491504, 0.8263177505886343)}}
The difference looks small, however, the actual result is outside the polygon.

h4. Area (size):
* Expected: 2.0005645375711432E-11
* Actual: 1.9971579945377016E-11

h4. Perimeter (boundary size):
* Expected: 1.9679779440894825E-5
* Actual: 1.96697104639384E-5

h2. Second test case: small circular (sphere) polygon
* Precision/Tolerance: {{EpsilonDoublePrecisionContext[epsilon= 
1.5696101377226165E-12]}}
* Circle discretized with 100 vertices: center: {{(0.5410520681182421, 
1.3962634015954636)}}, radius: {{4.784171699778536E-8}}

h4. Centroid:
* Expected (approximately circle center): {{(0.5410520681182421, 
1.3962634015954636)}}
* Actual: {{null}}

h4. Area (size):
* Expected: 7.181590857887451E-15
* Actual: 0.0

h4. Perimeter (boundary size):
* Expected: 3.0054894917112657E-7
* Actual: 3.005489492811408E-7

  was:
h2. First test case: small spherical rectangle
* Precision/Tolerance: {{EpsilonDoublePrecisionContext[epsilon= 
1.5696101377226165E-12]}}
* Spherical polygon/rectangle vertices: {{[(5.050647792392463, 
0.8263048984534946), (5.050644504477406, 0.8263064367456399), 
(5.050649564478115, 0.8263123289902004), (5.050652852378331, 
0.8263107907013917)]}}

h4. Centroid:
* Expected (approximately the average of vertices): {{(5.050648678475973, 
0.8263086112510253)}}
* Actual: {{(5.0506454742491504, 0.8263177505886343)}}
The difference looks small, however, the actual result is outside the polygon.

h4. Area (size):
* Expected: 2.0005645375711432E-11
* Actual: 1.9971579945377016E-11

h4. Perimeter (boundary size):
* Expected: 1.9679779440894825E-5
* Actual: 1.96697104639384E-5

h2. Second test case: small spherical circular polygon
* Precision/Tolerance: {{EpsilonDoublePrecisionContext[epsilon= 
1.5696101377226165E-12]}}
* Circle discretized with 100 vertices: center: {{(0.5410520681182421, 
1.3962634015954636)}}, radius: {{4.784171699778536E-8}}

h4. Centroid:
* Expected (approximately circle center): {{(0.5410520681182421, 
1.3962634015954636)}}
* Actual: {{null}}

h4. Area (size):
* Expected: 7.181590857887451E-15
* Actual: 0.0

h4. Perimeter (boundary size):
* Expected: 3.0054894917112657E-7
* Actual: 3.005489492811408E-7


> Invalid result for small spherical polygons
> ---
>
> Key: GEOMETRY-100
> URL: https://issues.apache.org/jira/browse/GEOMETRY-100
> Project: Apache Commons Geometry
>  Issue Type: Bug
>Reporter: Baljit Singh
>Priority: Blocker
> Fix For: 1.0
>
>
> h2. First test case: small spherical rectangle
> * Precision/Tolerance: {{EpsilonDoublePrecisionContext[epsilon= 
> 1.5696101377226165E-12]}}
> * Spherical polygon/rectangle vertices: {{[(5.050647792392463, 
> 0.8263048984534946), (5.050644504477406, 0.8263064367456399), 
> (5.050649564478115, 0.8263123289902004), (5.050652852378331, 
> 0.8263107907013917)]}}
> h4. Centroid:
> * Expected (approximately the average of vertices): {{(5.050648678475973, 
> 0.8263086112510253)}}
> * Actual: {{(5.0506454742491504, 0.8263177505886343)}}
> The difference looks small, however, the actual result is outside the polygon.
> h4. Area (size):
> * Expected: 2.0005645375711432E-11
> * Actual: 1.9971579945377016E-11
> h4. Perimeter (boundary size):
> * Expected: 1.9679779440894825E-5
> * Actual: 1.96697104639384E-5
> h2. Second test case: small circular (sphere) polygon
> * Precision/Tolerance: {{EpsilonDoublePrecisionContext[epsilon= 
> 1.5696101377226165E-12]}}
> * Circle discretized with 100 vertices: center: {{(0.5410520681182421, 
> 1.3962634015954636)}}, radius: {{4.784171699778536E-8}}
> h4. Centroid:
> * Expected (approximately circle center): {{(0.5410520681182421, 
> 1.3962634015954636)}}
> * Actual: {{null}}
> h4. Area (size):
> * Expected: 7.181590857887451E-15
> * Actual: 0.0
> h4. Perimeter (boundary size):
> * Expected: 3.0054894917112657E-7
> * Actual: 3.005489492811408E-7



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (GEOMETRY-100) Invalid result for small spherical polygons

[Baljit Singh (Jira)]

[ 
https://issues.apache.org/jira/browse/GEOMETRY-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152343#comment-17152343
 ] 

Baljit Singh commented on GEOMETRY-100:
---

[~mattjuntunen] This issue is also present in Math3.

> Invalid result for small spherical polygons
> ---
>
> Key: GEOMETRY-100
> URL: https://issues.apache.org/jira/browse/GEOMETRY-100
> Project: Apache Commons Geometry
>  Issue Type: Bug
>Reporter: Baljit Singh
>Priority: Blocker
> Fix For: 1.0
>
>
> h2. First test case: small spherical rectangle
> * Precision/Tolerance: {{EpsilonDoublePrecisionContext[epsilon= 
> 1.5696101377226165E-12]}}
> * Spherical polygon/rectangle vertices: {{[(5.050647792392463, 
> 0.8263048984534946), (5.050644504477406, 0.8263064367456399), 
> (5.050649564478115, 0.8263123289902004), (5.050652852378331, 
> 0.8263107907013917)]}}
> h4. Centroid:
> * Expected (approximately the average of vertices): {{(5.050648678475973, 
> 0.8263086112510253)}}
> * Actual: {{(5.0506454742491504, 0.8263177505886343)}}
> The difference looks small, however, the actual result is outside the polygon.
> h4. Area (size):
> * Expected: 2.0005645375711432E-11
> * Actual: 1.9971579945377016E-11
> h4. Perimeter (boundary size):
> * Expected: 1.9679779440894825E-5
> * Actual: 1.96697104639384E-5
> h2. Second test case: small spherical circular polygon
> * Precision/Tolerance: {{EpsilonDoublePrecisionContext[epsilon= 
> 1.5696101377226165E-12]}}
> * Circle discretized with 100 vertices: center: {{(0.5410520681182421, 
> 1.3962634015954636)}}, radius: {{4.784171699778536E-8}}
> h4. Centroid:
> * Expected (approximately circle center): {{(0.5410520681182421, 
> 1.3962634015954636)}}
> * Actual: {{null}}
> h4. Area (size):
> * Expected: 7.181590857887451E-15
> * Actual: 0.0
> h4. Perimeter (boundary size):
> * Expected: 3.0054894917112657E-7
> * Actual: 3.005489492811408E-7



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (GEOMETRY-100) Invalid result for small spherical polygons

[Baljit Singh (Jira)]

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

Baljit Singh updated GEOMETRY-100:
--
Description: 
h2. First test case: small spherical rectangle
* Precision/Tolerance: {{EpsilonDoublePrecisionContext[epsilon= 
1.5696101377226165E-12]}}
* Spherical polygon/rectangle vertices: {{[(5.050647792392463, 
0.8263048984534946), (5.050644504477406, 0.8263064367456399), 
(5.050649564478115, 0.8263123289902004), (5.050652852378331, 
0.8263107907013917)]}}

h4. Centroid:
* Expected (approximately the average of vertices): {{(5.050648678475973, 
0.8263086112510253)}}
* Actual: {{(5.0506454742491504, 0.8263177505886343)}}
The difference looks small, however, the actual result is outside the polygon.

h4. Area (size):
* Expected: 2.0005645375711432E-11
* Actual: 1.9971579945377016E-11

h4. Perimeter (boundary size):
* Expected: 1.9679779440894825E-5
* Actual: 1.96697104639384E-5

h2. Second test case: small spherical circular polygon
* Precision/Tolerance: {{EpsilonDoublePrecisionContext[epsilon= 
1.5696101377226165E-12]}}
* Circle discretized with 100 vertices: center: {{(0.5410520681182421, 
1.3962634015954636)}}, radius: {{4.784171699778536E-8}}

h4. Centroid:
* Expected (approximately circle center): {{(0.5410520681182421, 
1.3962634015954636)}}
* Actual: {{null}}

h4. Area (size):
* Expected: 7.181590857887451E-15
* Actual: 0.0

h4. Perimeter (boundary size):
* Expected: 3.0054894917112657E-7
* Actual: 3.005489492811408E-7

  was:
h2. First test case: small spherical rectangle
* Precision/Tolerance: {{EpsilonDoublePrecisionContext[epsilon= 
1.5696101377226165E-12]}}
* Spherical polygon/rectangle vertices: {{[(5.050647792392463, 
0.8263048984534946), (5.050644504477406, 0.8263064367456399), 
(5.050649564478115, 0.8263123289902004), (5.050652852378331, 
0.8263107907013917)]}}

h4. Centroid:
* Expected (approximately the average of vertices): {{(5.050648678475973, 
0.8263086112510253)}}
* Actual: {{(5.0506454742491504, 0.8263177505886343)}}
The difference looks small, however, the actual result is outside the polygon.

h4. Area (size):
* Expected: 2.0005645375711432E-11
* Actual: 1.9971579945377016E-11

h4. Perimeter (boundary size):
* Expected: 1.9679779440894825E-5
* Actual: 1.96697104639384E-5

h2. Second test case: small spherical circular polygon
* Precision/Tolerance: {{EpsilonDoublePrecisionContext[epsilon= 
1.5696101377226165E-12]}}
* Circle discretized with 100 vertices. center: {{(0.5410520681182421, 
1.3962634015954636)}}, radius: {{4.784171699778536E-8}}

h4. Centroid:
* Expected (approximately circle center): {{(0.5410520681182421, 
1.3962634015954636)}}
* Actual: {{null}}

h4. Area (size):
* Expected: 7.181590857887451E-15
* Actual: 0.0

h4. Perimeter (boundary size):
* Expected: 3.0054894917112657E-7
* Actual: 3.005489492811408E-7


> Invalid result for small spherical polygons
> ---
>
> Key: GEOMETRY-100
> URL: https://issues.apache.org/jira/browse/GEOMETRY-100
> Project: Apache Commons Geometry
>  Issue Type: Bug
>Reporter: Baljit Singh
>Priority: Blocker
> Fix For: 1.0
>
>
> h2. First test case: small spherical rectangle
> * Precision/Tolerance: {{EpsilonDoublePrecisionContext[epsilon= 
> 1.5696101377226165E-12]}}
> * Spherical polygon/rectangle vertices: {{[(5.050647792392463, 
> 0.8263048984534946), (5.050644504477406, 0.8263064367456399), 
> (5.050649564478115, 0.8263123289902004), (5.050652852378331, 
> 0.8263107907013917)]}}
> h4. Centroid:
> * Expected (approximately the average of vertices): {{(5.050648678475973, 
> 0.8263086112510253)}}
> * Actual: {{(5.0506454742491504, 0.8263177505886343)}}
> The difference looks small, however, the actual result is outside the polygon.
> h4. Area (size):
> * Expected: 2.0005645375711432E-11
> * Actual: 1.9971579945377016E-11
> h4. Perimeter (boundary size):
> * Expected: 1.9679779440894825E-5
> * Actual: 1.96697104639384E-5
> h2. Second test case: small spherical circular polygon
> * Precision/Tolerance: {{EpsilonDoublePrecisionContext[epsilon= 
> 1.5696101377226165E-12]}}
> * Circle discretized with 100 vertices: center: {{(0.5410520681182421, 
> 1.3962634015954636)}}, radius: {{4.784171699778536E-8}}
> h4. Centroid:
> * Expected (approximately circle center): {{(0.5410520681182421, 
> 1.3962634015954636)}}
> * Actual: {{null}}
> h4. Area (size):
> * Expected: 7.181590857887451E-15
> * Actual: 0.0
> h4. Perimeter (boundary size):
> * Expected: 3.0054894917112657E-7
> * Actual: 3.005489492811408E-7



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (GEOMETRY-100) Invalid result for small spherical polygons

[Baljit Singh (Jira)]

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

Baljit Singh updated GEOMETRY-100:
--
Description: 
h2. First test case: small spherical rectangle
* Precision/Tolerance: {{EpsilonDoublePrecisionContext[epsilon= 
1.5696101377226165E-12]}}
* Spherical polygon/rectangle vertices: {{[(5.050647792392463, 
0.8263048984534946), (5.050644504477406, 0.8263064367456399), 
(5.050649564478115, 0.8263123289902004), (5.050652852378331, 
0.8263107907013917)]}}

h4. Centroid:
* Expected (approximately the average of vertices): {{(5.050648678475973, 
0.8263086112510253)}}
* Actual: {{(5.0506454742491504, 0.8263177505886343)}}
The difference looks small, however, the actual result is outside the polygon.

h4. Area (size):
* Expected: 2.0005645375711432E-11
* Actual: 1.9971579945377016E-11

h4. Perimeter (boundary size):
* Expected: 1.9679779440894825E-5
* Actual: 1.96697104639384E-5

h2. Second test case: small spherical circular polygon
* Precision/Tolerance: {{EpsilonDoublePrecisionContext[epsilon= 
1.5696101377226165E-12]}}
* Circle discretized with 100 vertices. center: {{(0.5410520681182421, 
1.3962634015954636)}}, radius: {{4.784171699778536E-8}}

h4. Centroid:
* Expected (approximately circle center): {{(0.5410520681182421, 
1.3962634015954636)}}
* Actual: {{null}}

h4. Area (size):
* Expected: 7.181590857887451E-15
* Actual: 0.0

h4. Perimeter (boundary size):
* Expected: 3.0054894917112657E-7
* Actual: 3.005489492811408E-7

  was:
h3. First test case
* Precision/Tolerance: {{EpsilonDoublePrecisionContext[epsilon= 
1.5696101377226165E-12]}}
* Spherical polygon/rectangle vertices: {{[(5.050647792392463, 
0.8263048984534946), (5.050644504477406, 0.8263064367456399), 
(5.050649564478115, 0.8263123289902004), (5.050652852378331, 
0.8263107907013917)]}}

Centroid:
* Expected (approximately the average of vertices): (5.050648678475973, 
0.8263086112510253)
* Actual: (5.0506454742491504, 0.8263177505886343)
The difference looks small, however, the actual result is outside the polygon.

Area:
* Expected: 2.0005645375711432E-11
* Actual: 1.9971579945377016E-11




> Invalid result for small spherical polygons
> ---
>
> Key: GEOMETRY-100
> URL: https://issues.apache.org/jira/browse/GEOMETRY-100
> Project: Apache Commons Geometry
>  Issue Type: Bug
>Reporter: Baljit Singh
>Priority: Blocker
> Fix For: 1.0
>
>
> h2. First test case: small spherical rectangle
> * Precision/Tolerance: {{EpsilonDoublePrecisionContext[epsilon= 
> 1.5696101377226165E-12]}}
> * Spherical polygon/rectangle vertices: {{[(5.050647792392463, 
> 0.8263048984534946), (5.050644504477406, 0.8263064367456399), 
> (5.050649564478115, 0.8263123289902004), (5.050652852378331, 
> 0.8263107907013917)]}}
> h4. Centroid:
> * Expected (approximately the average of vertices): {{(5.050648678475973, 
> 0.8263086112510253)}}
> * Actual: {{(5.0506454742491504, 0.8263177505886343)}}
> The difference looks small, however, the actual result is outside the polygon.
> h4. Area (size):
> * Expected: 2.0005645375711432E-11
> * Actual: 1.9971579945377016E-11
> h4. Perimeter (boundary size):
> * Expected: 1.9679779440894825E-5
> * Actual: 1.96697104639384E-5
> h2. Second test case: small spherical circular polygon
> * Precision/Tolerance: {{EpsilonDoublePrecisionContext[epsilon= 
> 1.5696101377226165E-12]}}
> * Circle discretized with 100 vertices. center: {{(0.5410520681182421, 
> 1.3962634015954636)}}, radius: {{4.784171699778536E-8}}
> h4. Centroid:
> * Expected (approximately circle center): {{(0.5410520681182421, 
> 1.3962634015954636)}}
> * Actual: {{null}}
> h4. Area (size):
> * Expected: 7.181590857887451E-15
> * Actual: 0.0
> h4. Perimeter (boundary size):
> * Expected: 3.0054894917112657E-7
> * Actual: 3.005489492811408E-7



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (GEOMETRY-100) Invalid result for small spherical polygons

[Baljit Singh (Jira)]

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

Baljit Singh updated GEOMETRY-100:
--
Description: 
h3. First test case
* Precision/Tolerance: {{EpsilonDoublePrecisionContext[epsilon= 
1.5696101377226165E-12]}}
* Spherical polygon/rectangle vertices: {{[(5.050647792392463, 
0.8263048984534946), (5.050644504477406, 0.8263064367456399), 
(5.050649564478115, 0.8263123289902004), (5.050652852378331, 
0.8263107907013917)]}}

Centroid:
* Expected (approximately the average of vertices): (5.050648678475973, 
0.8263086112510253)
* Actual: (5.0506454742491504, 0.8263177505886343)
The difference looks small, however, the actual result is outside the polygon.

Area:
* Expected: 2.0005645375711432E-11
* Actual: 1.9971579945377016E-11



  was:
Test case:
* {{EpsilonDoublePrecisionContext[epsilon= 1.5696101377226165E-12]}}
* Spherical polygon vertices: {{[(5.050647792392463, 0.8263048984534946), 
(5.050644504477406, 0.8263064367456399), (5.050649564478115, 
0.8263123289902004), (5.050652852378331, 0.8263107907013917)]}}


> Invalid result for small spherical polygons
> ---
>
> Key: GEOMETRY-100
> URL: https://issues.apache.org/jira/browse/GEOMETRY-100
> Project: Apache Commons Geometry
>  Issue Type: Bug
>Reporter: Baljit Singh
>Priority: Blocker
> Fix For: 1.0
>
>
> h3. First test case
> * Precision/Tolerance: {{EpsilonDoublePrecisionContext[epsilon= 
> 1.5696101377226165E-12]}}
> * Spherical polygon/rectangle vertices: {{[(5.050647792392463, 
> 0.8263048984534946), (5.050644504477406, 0.8263064367456399), 
> (5.050649564478115, 0.8263123289902004), (5.050652852378331, 
> 0.8263107907013917)]}}
> Centroid:
> * Expected (approximately the average of vertices): (5.050648678475973, 
> 0.8263086112510253)
> * Actual: (5.0506454742491504, 0.8263177505886343)
> The difference looks small, however, the actual result is outside the polygon.
> Area:
> * Expected: 2.0005645375711432E-11
> * Actual: 1.9971579945377016E-11



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (COMMONSSITE-136) منصةشليله

[Jira]

منصة شليله created COMMONSSITE-136:
--

 Summary: منصةشليله 
 Key: COMMONSSITE-136
 URL: https://issues.apache.org/jira/browse/COMMONSSITE-136
 Project: Apache Commons All
  Issue Type: New Feature
  Components: Commons Build, Commons Build Plugin, Commons Parent Pom, 
Commons Release Plugin, Commons Skin, Nightly, Site
Affects Versions: 1.8, 1.6
 Environment: [https://github.com/Shliilh2/license-list-XML.git]

https://shliilhplatform.com.sa 
Reporter: منصة شليله
 Fix For: 1.5-SNAPSHOT, 40
 Attachments: ٢٠٢٠٠٦٢٢_٢٣٠٧٢٥~2.png

(منصةشليله)

Android web All Al Ai TV Automatic robot shliilhplatform gmrshliilh ihdadi.com 
Apache APK app etc. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (GEOMETRY-100) Invalid result for small spherical polygons

[Baljit Singh (Jira)]

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

Baljit Singh updated GEOMETRY-100:
--
Description: 
Test case:
* {{EpsilonDoublePrecisionContext[epsilon= 1.5696101377226165E-12]}}
* Spherical polygon vertices: {{[(5.050647792392463, 0.8263048984534946), 
(5.050644504477406, 0.8263064367456399), (5.050649564478115, 
0.8263123289902004), (5.050652852378331, 0.8263107907013917)]}}

> Invalid result for small spherical polygons
> ---
>
> Key: GEOMETRY-100
> URL: https://issues.apache.org/jira/browse/GEOMETRY-100
> Project: Apache Commons Geometry
>  Issue Type: Bug
>Reporter: Baljit Singh
>Priority: Blocker
> Fix For: 1.0
>
>
> Test case:
> * {{EpsilonDoublePrecisionContext[epsilon= 1.5696101377226165E-12]}}
> * Spherical polygon vertices: {{[(5.050647792392463, 0.8263048984534946), 
> (5.050644504477406, 0.8263064367456399), (5.050649564478115, 
> 0.8263123289902004), (5.050652852378331, 0.8263107907013917)]}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (GEOMETRY-100) Invalid result for small spherical polygons

[Baljit Singh (Jira)]

Baljit Singh created GEOMETRY-100:
-

 Summary: Invalid result for small spherical polygons
 Key: GEOMETRY-100
 URL: https://issues.apache.org/jira/browse/GEOMETRY-100
 Project: Apache Commons Geometry
  Issue Type: Bug
Reporter: Baljit Singh
 Fix For: 1.0






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (COMPRESS-539) TarArchiveInputStream allocates a lot of memory when iterating through an archive

[Stefan Bodewig (Jira)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152153#comment-17152153
 ] 

Stefan Bodewig commented on COMPRESS-539:
-

I'm afraid we've never run any measurements but relied on gut feeling.

The assumption here is that {{skip}} on a seekable stream should be faster if 
skipping more than just a few bytes. I'm not sure how you have constructed the 
example [~rschimpf] but I guess the entries are pretty small (a few kilobytes). 
Our (well, my) expectation is that {{read}} in such a case might return cached 
data as we've just read a tar header from the stream, but if the entry in 
question was bigger - a few megabytes, maybe - then reading it should be 
measurably slower than seeking ahead for the same amount of bytes.

> TarArchiveInputStream allocates a lot of memory when iterating through an 
> archive
> -
>
> Key: COMPRESS-539
> URL: https://issues.apache.org/jira/browse/COMPRESS-539
> Project: Commons Compress
>  Issue Type: Bug
>Affects Versions: 1.20
>Reporter: Robin Schimpf
>Assignee: Peter Lee
>Priority: Major
> Attachments: Don't_call_InputStream#skip.patch, 
> Reuse_recordBuffer.patch, image-2020-06-21-10-58-07-917.png, 
> image-2020-06-21-10-58-43-255.png, image-2020-06-21-10-59-10-825.png, 
> image-2020-07-05-22-10-07-402.png, image-2020-07-05-22-11-25-526.png, 
> image-2020-07-05-22-32-15-131.png, image-2020-07-05-22-32-31-511.png
>
>
>  I iterated through the linux source tar and noticed some unneeded 
> allocations happen without extracting any data.
> Reproducing code
> {code:java}
> File tarFile = new File("linux-5.7.1.tar");
> try (TarArchiveInputStream in = new 
> TarArchiveInputStream(Files.newInputStream(tarFile.toPath( {
> TarArchiveEntry entry;
> while ((entry = in.getNextTarEntry()) != null) {
> }
> }
> {code}
> The measurement was done on Java 11.0.7 with the Java Flight Recorder. 
> Options used: 
> -XX:StartFlightRecording=settings=profile,filename=allocations.jfr
> Baseline with the current master implementation:
>  Estimated TLAB allocation: 293MiB
> !image-2020-06-21-10-58-07-917.png!
> 1. IOUtils.skip -> input.skip(numToSkip)
>  This delegates in my test scenario to the InputStream.skip implementation 
> which allocates a new byte[] for every invocation. By simply commenting out 
> the while loop which calls the skip method the estimated TLAB allocation 
> drops to 164MiB (-129MiB).
>  !image-2020-06-21-10-58-43-255.png! 
>  Commenting out the skip call does not seem to be the best solution but it 
> was quick for me to see how much memory can be saved. Also no unit tests 
> where failing for me.
> 2. TarArchiveInputStream.readRecord
>  For every read of the record a new byte[] is created. Since the record size 
> does not change the byte[] can be reused and created when instantiating the 
> TarStream. This optimization is already present in the 
> TarArchiveOutputStream. Reusing the buffer reduces the estimated TLAB 
> allocations further to 128MiB (-36MiB).
>  !image-2020-06-21-10-59-10-825.png!
> I attached the patches I used so the results can be verified.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-geometry] XenoAmess opened a new pull request #95: add Commit Message Guideline.

[GitBox]

XenoAmess opened a new pull request #95:
URL: https://github.com/apache/commons-geometry/pull/95


   a demo one, as discussed on mailing list.
   fell free to use/change 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

[jira] [Commented] (NET-408) problem connecting to ProFTPD with FTPES

[Enrico Olivelli (Jira)]

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

Enrico Olivelli commented on NET-408:
-

[~elichtas]

If I force "clientMode = true" in ChannelSslAdapter.java

the thread is stuck in 
{code:java}
 at 
java.base@14/sun.security.ssl.SSLEngineImpl.writeRecord(SSLEngineImpl.java:180)
at java.base@14/sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:146)
at java.base@14/sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:123)
at java.base@14/javax.net.ssl.SSLEngine.wrap(SSLEngine.java:479)
at 
org.apache.commons.net.io.ext.ChannelSslWritableByteChannel.write(ChannelSslWritableByteChannel.java:66)
at java.base@14/java.nio.channels.Channels.writeFullyImpl(Channels.java:74)
at java.base@14/java.nio.channels.Channels.writeFully(Channels.java:97)
at java.base@14/java.nio.channels.Channels$1.write(Channels.java:172)
- locked <6772e0dc> (a java.nio.channels.Channels$1)
at 
java.base@14/sun.security.ssl.SSLSocketOutputRecord.flush(SSLSocketOutputRecord.java:268)
at 
java.base@14/sun.security.ssl.HandshakeOutStream.flush(HandshakeOutStream.java:89)
at 
java.base@14/sun.security.ssl.ClientHello$ClientHelloKickstartProducer.produce(ClientHello.java:657)
at 
java.base@14/sun.security.ssl.SSLHandshake.kickstart(SSLHandshake.java:529)
at 
java.base@14/sun.security.ssl.ClientHandshakeContext.kickstart(ClientHandshakeContext.java:107)
at 
java.base@14/sun.security.ssl.TransportContext.kickstart(TransportContext.java:231)
at 
java.base@14/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:430)
at 
org.apache.commons.net.ftp.FTPSClient._openDataConnection_(FTPSClient.java:682)
at 
org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:790)
at 
org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:3456)
at 
org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:3386)
at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:3063)
 {code}
 

Unfortunately I do not have experience about how SSLEngine works.

 

> problem connecting to ProFTPD with FTPES
> 
>
> Key: NET-408
> URL: https://issues.apache.org/jira/browse/NET-408
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 2.2, 3.0
> Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1 
> 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
> ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
> Java 1.5
>Reporter: Michael Voigt
>Priority: Major
> Attachments: BCFTPSClient.java, FTPSClientWithTLSResumption.zip, 
> PTFTPSClient.java, ftpes.jpg, proftpd.conf
>
>
> I have a problem with the FTPClient connecting to a ProFTPD server.
> If the server uses the configuration option "TLSProtocol TLSv1", I
> cannot connect to it at all. I recieve the following error message:
> - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
> On the server side I see in the log:
> unable to accept TLS connection: protocol error:
> -  (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate unknown
> - TLS/TLS-C negotiation failed on control channel
> If the server uses the configuration option "TLSProtocol SSLv23", I
> can connect to it but I cant transfer any files. In the server log I
> see:
> - starting TLS negotiation on data connection
> - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
> - client did not reuse SSL session, rejecting data connection (see
> TLSOption NoSessionReuseRequired)
> - unable to open data connection: TLS negotiation failed
> If I add the NoSessionReuseRequired parameter to the ProFTPD config
> everything works fine.
> Here is my code:
>FTPClient ftpClient = new FTPClient();
>ftpClient = new FTPSClient("TLS");
>// this throws an exception with TLSProtocol TLSv1
>ftpClient.connect(host, port);
>int reply = ftpClient.getReplyCode();
>if (!FTPReply.isPositiveCompletion(reply)) {
>ftpClient.disconnect();
>log.error("The FTP Server did not return a positive 
> completion reply!");
>throw new 
> FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
>}
>boolean loginSuccessful = ftpClient.login(userName, password);
>if (!loginSuccessful) {
>log.error("Login to the FTP Server failed! The 
> credentials are not valid.");
>throw new 
> FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
>}
>ftpClient.execPBSZ(0);
>

[jira] [Comment Edited] (NET-408) problem connecting to ProFTPD with FTPES

[Enrico Olivelli (Jira)]

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

Enrico Olivelli edited comment on NET-408 at 7/6/20, 3:08 PM:
--

[~elichtas]

Thank you very much.

I have now this error:
{code:java}
java.lang.IllegalStateException: Client/Server mode has not yet been 
set.java.lang.IllegalStateException: Client/Server mode has not yet been set. 
at java.base/sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:134) at 
java.base/sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:123) at 
java.base/javax.net.ssl.SSLEngine.wrap(SSLEngine.java:479) at 
org.apache.commons.net.io.ext.ChannelSslWritableByteChannel.write(ChannelSslWritableByteChannel.java:66)
 at java.base/java.nio.channels.Channels.writeFullyImpl(Channels.java:74) at 
java.base/java.nio.channels.Channels.writeFully(Channels.java:97) at 
java.base/java.nio.channels.Channels$1.write(Channels.java:172) at 
java.base/sun.security.ssl.SSLSocketOutputRecord.encodeAlert(SSLSocketOutputRecord.java:82)
 at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:355) at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:267) at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:262) at 
java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1654)
 at 
java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:443) 
at 
org.apache.commons.net.ftp.FTPSClient._openDataConnection_(FTPSClient.java:682) 
at 
org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:790) 
at 
org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:3456) 
at 
org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:3386) 
at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:3063) {code}
 

I am now trying to force "clientMode" in ChannelSslAdapter.java

 

Once I get this to work, could you please send an official patch or commit to 
master branch this patch ?


was (Author: eolivelli):
[~7265626F6F74]

Thank you very much.

I have now this error:
{code:java}
java.lang.IllegalStateException: Client/Server mode has not yet been 
set.java.lang.IllegalStateException: Client/Server mode has not yet been set. 
at java.base/sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:134) at 
java.base/sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:123) at 
java.base/javax.net.ssl.SSLEngine.wrap(SSLEngine.java:479) at 
org.apache.commons.net.io.ext.ChannelSslWritableByteChannel.write(ChannelSslWritableByteChannel.java:66)
 at java.base/java.nio.channels.Channels.writeFullyImpl(Channels.java:74) at 
java.base/java.nio.channels.Channels.writeFully(Channels.java:97) at 
java.base/java.nio.channels.Channels$1.write(Channels.java:172) at 
java.base/sun.security.ssl.SSLSocketOutputRecord.encodeAlert(SSLSocketOutputRecord.java:82)
 at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:355) at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:267) at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:262) at 
java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1654)
 at 
java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:443) 
at 
org.apache.commons.net.ftp.FTPSClient._openDataConnection_(FTPSClient.java:682) 
at 
org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:790) 
at 
org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:3456) 
at 
org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:3386) 
at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:3063) {code}
 

I am now trying to force "clientMode" in ChannelSslAdapter.java

 

Once I get this to work, could you please send an official patch or commit to 
master branch this patch ?

> problem connecting to ProFTPD with FTPES
> 
>
> Key: NET-408
> URL: https://issues.apache.org/jira/browse/NET-408
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 2.2, 3.0
> Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1 
> 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
> ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
> Java 1.5
>Reporter: Michael Voigt
>Priority: Major
> Attachments: BCFTPSClient.java, FTPSClientWithTLSResumption.zip, 
> PTFTPSClient.java, ftpes.jpg, proftpd.conf
>
>
> I have a problem with the FTPClient connecting to a ProFTPD server.
> If the server uses the configuration option "TLSProtocol TLSv1", I
> cannot connect to it at all. I recieve the following error message:
> - javax.net.ssl.SSLException: Unrecognized SSL message, 

[jira] [Commented] (NET-408) problem connecting to ProFTPD with FTPES

[Enrico Olivelli (Jira)]

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

Enrico Olivelli commented on NET-408:
-

[~7265626F6F74]

Thank you very much.

I have now this error:
{code:java}
java.lang.IllegalStateException: Client/Server mode has not yet been 
set.java.lang.IllegalStateException: Client/Server mode has not yet been set. 
at java.base/sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:134) at 
java.base/sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:123) at 
java.base/javax.net.ssl.SSLEngine.wrap(SSLEngine.java:479) at 
org.apache.commons.net.io.ext.ChannelSslWritableByteChannel.write(ChannelSslWritableByteChannel.java:66)
 at java.base/java.nio.channels.Channels.writeFullyImpl(Channels.java:74) at 
java.base/java.nio.channels.Channels.writeFully(Channels.java:97) at 
java.base/java.nio.channels.Channels$1.write(Channels.java:172) at 
java.base/sun.security.ssl.SSLSocketOutputRecord.encodeAlert(SSLSocketOutputRecord.java:82)
 at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:355) at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:267) at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:262) at 
java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1654)
 at 
java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:443) 
at 
org.apache.commons.net.ftp.FTPSClient._openDataConnection_(FTPSClient.java:682) 
at 
org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:790) 
at 
org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:3456) 
at 
org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:3386) 
at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:3063) {code}
 

I am now trying to force "clientMode" in ChannelSslAdapter.java

 

Once I get this to work, could you please send an official patch or commit to 
master branch this patch ?

> problem connecting to ProFTPD with FTPES
> 
>
> Key: NET-408
> URL: https://issues.apache.org/jira/browse/NET-408
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 2.2, 3.0
> Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1 
> 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
> ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
> Java 1.5
>Reporter: Michael Voigt
>Priority: Major
> Attachments: BCFTPSClient.java, FTPSClientWithTLSResumption.zip, 
> PTFTPSClient.java, ftpes.jpg, proftpd.conf
>
>
> I have a problem with the FTPClient connecting to a ProFTPD server.
> If the server uses the configuration option "TLSProtocol TLSv1", I
> cannot connect to it at all. I recieve the following error message:
> - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
> On the server side I see in the log:
> unable to accept TLS connection: protocol error:
> -  (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate unknown
> - TLS/TLS-C negotiation failed on control channel
> If the server uses the configuration option "TLSProtocol SSLv23", I
> can connect to it but I cant transfer any files. In the server log I
> see:
> - starting TLS negotiation on data connection
> - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
> - client did not reuse SSL session, rejecting data connection (see
> TLSOption NoSessionReuseRequired)
> - unable to open data connection: TLS negotiation failed
> If I add the NoSessionReuseRequired parameter to the ProFTPD config
> everything works fine.
> Here is my code:
>FTPClient ftpClient = new FTPClient();
>ftpClient = new FTPSClient("TLS");
>// this throws an exception with TLSProtocol TLSv1
>ftpClient.connect(host, port);
>int reply = ftpClient.getReplyCode();
>if (!FTPReply.isPositiveCompletion(reply)) {
>ftpClient.disconnect();
>log.error("The FTP Server did not return a positive 
> completion reply!");
>throw new 
> FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
>}
>boolean loginSuccessful = ftpClient.login(userName, password);
>if (!loginSuccessful) {
>log.error("Login to the FTP Server failed! The 
> credentials are not valid.");
>throw new 
> FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
>}
>ftpClient.execPBSZ(0);
>ftpClient.execPROT("P");
>boolean success = ftpClient.storeFile(fileName, fis);
>if (!success) {
> 

[jira] [Commented] (NET-408) problem connecting to ProFTPD with FTPES

[Erick Lichtas (Jira)]

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

Erick Lichtas commented on NET-408:
---

I cache it the _connectAction_() method. Something like this:
{noformat}
@Override    
protected void _connectAction_() throws IOException {
      if (useTlsResumption){
            // cache the address if resuming tls         
            tlsResumptionAddress = new 
InetSocketAddress(_socket_.getInetAddress(), _socket_.getPort());
      }

      // Implicit mode.
      if (isImplicit) {
            sslNegotiation();
      }
      super._connectAction_();
      // Explicit mode.
      if (!isImplicit) {
            execAUTH();
            sslNegotiation();
      }
}{noformat}
 

 

> problem connecting to ProFTPD with FTPES
> 
>
> Key: NET-408
> URL: https://issues.apache.org/jira/browse/NET-408
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 2.2, 3.0
> Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1 
> 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
> ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
> Java 1.5
>Reporter: Michael Voigt
>Priority: Major
> Attachments: BCFTPSClient.java, FTPSClientWithTLSResumption.zip, 
> PTFTPSClient.java, ftpes.jpg, proftpd.conf
>
>
> I have a problem with the FTPClient connecting to a ProFTPD server.
> If the server uses the configuration option "TLSProtocol TLSv1", I
> cannot connect to it at all. I recieve the following error message:
> - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
> On the server side I see in the log:
> unable to accept TLS connection: protocol error:
> -  (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate unknown
> - TLS/TLS-C negotiation failed on control channel
> If the server uses the configuration option "TLSProtocol SSLv23", I
> can connect to it but I cant transfer any files. In the server log I
> see:
> - starting TLS negotiation on data connection
> - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
> - client did not reuse SSL session, rejecting data connection (see
> TLSOption NoSessionReuseRequired)
> - unable to open data connection: TLS negotiation failed
> If I add the NoSessionReuseRequired parameter to the ProFTPD config
> everything works fine.
> Here is my code:
>FTPClient ftpClient = new FTPClient();
>ftpClient = new FTPSClient("TLS");
>// this throws an exception with TLSProtocol TLSv1
>ftpClient.connect(host, port);
>int reply = ftpClient.getReplyCode();
>if (!FTPReply.isPositiveCompletion(reply)) {
>ftpClient.disconnect();
>log.error("The FTP Server did not return a positive 
> completion reply!");
>throw new 
> FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
>}
>boolean loginSuccessful = ftpClient.login(userName, password);
>if (!loginSuccessful) {
>log.error("Login to the FTP Server failed! The 
> credentials are not valid.");
>throw new 
> FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
>}
>ftpClient.execPBSZ(0);
>ftpClient.execPROT("P");
>boolean success = ftpClient.storeFile(fileName, fis);
>if (!success) {
>// this is false if "NoSessionReuseRequired" is not set
>}
> Now my question is if it is generally possible to connect to a server
> with "TLSProtocol TLSv1" or "TLSProtocol SSLv23" without the
> "NoSessionReuseRequired" parameter? Could someone provide a piece of
> example code for this?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (NET-408) problem connecting to ProFTPD with FTPES

[Enrico Olivelli (Jira)]

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

Enrico Olivelli commented on NET-408:
-

[~elichtas] how can I compute "tlsResumptionAddress" ?

Probably useTlsResumption is to be set to "true"

 

but I know about the new address  only in _prepareDataSocket_

> problem connecting to ProFTPD with FTPES
> 
>
> Key: NET-408
> URL: https://issues.apache.org/jira/browse/NET-408
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 2.2, 3.0
> Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1 
> 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
> ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
> Java 1.5
>Reporter: Michael Voigt
>Priority: Major
> Attachments: BCFTPSClient.java, FTPSClientWithTLSResumption.zip, 
> PTFTPSClient.java, ftpes.jpg, proftpd.conf
>
>
> I have a problem with the FTPClient connecting to a ProFTPD server.
> If the server uses the configuration option "TLSProtocol TLSv1", I
> cannot connect to it at all. I recieve the following error message:
> - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
> On the server side I see in the log:
> unable to accept TLS connection: protocol error:
> -  (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate unknown
> - TLS/TLS-C negotiation failed on control channel
> If the server uses the configuration option "TLSProtocol SSLv23", I
> can connect to it but I cant transfer any files. In the server log I
> see:
> - starting TLS negotiation on data connection
> - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
> - client did not reuse SSL session, rejecting data connection (see
> TLSOption NoSessionReuseRequired)
> - unable to open data connection: TLS negotiation failed
> If I add the NoSessionReuseRequired parameter to the ProFTPD config
> everything works fine.
> Here is my code:
>FTPClient ftpClient = new FTPClient();
>ftpClient = new FTPSClient("TLS");
>// this throws an exception with TLSProtocol TLSv1
>ftpClient.connect(host, port);
>int reply = ftpClient.getReplyCode();
>if (!FTPReply.isPositiveCompletion(reply)) {
>ftpClient.disconnect();
>log.error("The FTP Server did not return a positive 
> completion reply!");
>throw new 
> FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
>}
>boolean loginSuccessful = ftpClient.login(userName, password);
>if (!loginSuccessful) {
>log.error("Login to the FTP Server failed! The 
> credentials are not valid.");
>throw new 
> FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
>}
>ftpClient.execPBSZ(0);
>ftpClient.execPROT("P");
>boolean success = ftpClient.storeFile(fileName, fis);
>if (!success) {
>// this is false if "NoSessionReuseRequired" is not set
>}
> Now my question is if it is generally possible to connect to a server
> with "TLSProtocol TLSv1" or "TLSProtocol SSLv23" without the
> "NoSessionReuseRequired" parameter? Could someone provide a piece of
> example code for this?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (NET-408) problem connecting to ProFTPD with FTPES

[Erick Lichtas (Jira)]

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

Erick Lichtas commented on NET-408:
---

[~eolivelli] - you will need to make sure you pass in the appropriate host 
address and port of the control channel when constructing the factories in the 
FTPSClient. That is what the tlsResumptionAddress object does for me in the 
code above.  

Good luck!

> problem connecting to ProFTPD with FTPES
> 
>
> Key: NET-408
> URL: https://issues.apache.org/jira/browse/NET-408
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 2.2, 3.0
> Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1 
> 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
> ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
> Java 1.5
>Reporter: Michael Voigt
>Priority: Major
> Attachments: BCFTPSClient.java, FTPSClientWithTLSResumption.zip, 
> PTFTPSClient.java, ftpes.jpg, proftpd.conf
>
>
> I have a problem with the FTPClient connecting to a ProFTPD server.
> If the server uses the configuration option "TLSProtocol TLSv1", I
> cannot connect to it at all. I recieve the following error message:
> - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
> On the server side I see in the log:
> unable to accept TLS connection: protocol error:
> -  (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate unknown
> - TLS/TLS-C negotiation failed on control channel
> If the server uses the configuration option "TLSProtocol SSLv23", I
> can connect to it but I cant transfer any files. In the server log I
> see:
> - starting TLS negotiation on data connection
> - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
> - client did not reuse SSL session, rejecting data connection (see
> TLSOption NoSessionReuseRequired)
> - unable to open data connection: TLS negotiation failed
> If I add the NoSessionReuseRequired parameter to the ProFTPD config
> everything works fine.
> Here is my code:
>FTPClient ftpClient = new FTPClient();
>ftpClient = new FTPSClient("TLS");
>// this throws an exception with TLSProtocol TLSv1
>ftpClient.connect(host, port);
>int reply = ftpClient.getReplyCode();
>if (!FTPReply.isPositiveCompletion(reply)) {
>ftpClient.disconnect();
>log.error("The FTP Server did not return a positive 
> completion reply!");
>throw new 
> FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
>}
>boolean loginSuccessful = ftpClient.login(userName, password);
>if (!loginSuccessful) {
>log.error("Login to the FTP Server failed! The 
> credentials are not valid.");
>throw new 
> FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
>}
>ftpClient.execPBSZ(0);
>ftpClient.execPROT("P");
>boolean success = ftpClient.storeFile(fileName, fis);
>if (!success) {
>// this is false if "NoSessionReuseRequired" is not set
>}
> Now my question is if it is generally possible to connect to a server
> with "TLSProtocol TLSv1" or "TLSProtocol SSLv23" without the
> "NoSessionReuseRequired" parameter? Could someone provide a piece of
> example code for this?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (NET-408) problem connecting to ProFTPD with FTPES

[Enrico Olivelli (Jira)]

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

Enrico Olivelli commented on NET-408:
-

Thank you [~elichtas] I am testing it right now !

> problem connecting to ProFTPD with FTPES
> 
>
> Key: NET-408
> URL: https://issues.apache.org/jira/browse/NET-408
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 2.2, 3.0
> Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1 
> 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
> ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
> Java 1.5
>Reporter: Michael Voigt
>Priority: Major
> Attachments: BCFTPSClient.java, FTPSClientWithTLSResumption.zip, 
> PTFTPSClient.java, ftpes.jpg, proftpd.conf
>
>
> I have a problem with the FTPClient connecting to a ProFTPD server.
> If the server uses the configuration option "TLSProtocol TLSv1", I
> cannot connect to it at all. I recieve the following error message:
> - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
> On the server side I see in the log:
> unable to accept TLS connection: protocol error:
> -  (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate unknown
> - TLS/TLS-C negotiation failed on control channel
> If the server uses the configuration option "TLSProtocol SSLv23", I
> can connect to it but I cant transfer any files. In the server log I
> see:
> - starting TLS negotiation on data connection
> - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
> - client did not reuse SSL session, rejecting data connection (see
> TLSOption NoSessionReuseRequired)
> - unable to open data connection: TLS negotiation failed
> If I add the NoSessionReuseRequired parameter to the ProFTPD config
> everything works fine.
> Here is my code:
>FTPClient ftpClient = new FTPClient();
>ftpClient = new FTPSClient("TLS");
>// this throws an exception with TLSProtocol TLSv1
>ftpClient.connect(host, port);
>int reply = ftpClient.getReplyCode();
>if (!FTPReply.isPositiveCompletion(reply)) {
>ftpClient.disconnect();
>log.error("The FTP Server did not return a positive 
> completion reply!");
>throw new 
> FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
>}
>boolean loginSuccessful = ftpClient.login(userName, password);
>if (!loginSuccessful) {
>log.error("Login to the FTP Server failed! The 
> credentials are not valid.");
>throw new 
> FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
>}
>ftpClient.execPBSZ(0);
>ftpClient.execPROT("P");
>boolean success = ftpClient.storeFile(fileName, fis);
>if (!success) {
>// this is false if "NoSessionReuseRequired" is not set
>}
> Now my question is if it is generally possible to connect to a server
> with "TLSProtocol TLSv1" or "TLSProtocol SSLv23" without the
> "NoSessionReuseRequired" parameter? Could someone provide a piece of
> example code for this?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (NET-408) problem connecting to ProFTPD with FTPES

[Erick Lichtas (Jira)]

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

Erick Lichtas commented on NET-408:
---

[~jtoivonoja] - This case went quiet for a long time and my patch, which was 
still in the works at the time, has since been finalized and has been in use 
for a few years now. I've updated the attached set of libs.  

The biggest problem is that the data connection is on a separate port than the 
control connection. So when java looks up the TLS session for the ftp data 
connection on port 3 (as an example), it doesn't find one - the control 
connection where the session was originally create for port 21.  The patch I've 
attached will instruct the SSLEngine being created to use the original control 
channel host and port. This doesn't impact the socket connection itself, but 
will instruct the JVM to use an existing SSL session if it exists.  

I've added a newer zip file 'FTPSClientWithTLSResumption' with an 
org.apache.commons.net.io.ext package.  Copy that package into your project and 
add the following code block to the appropriate location in the execPROT method 
of the FTPSClient.java class


{code:java}
// Added to execProt command of the FTPSClient.java

if (useTlsResumption) { 
ChannelSslSocketFactory sslSocketFactory = new ChannelSslSocketFactory( 
context); 

sslSocketFactory.setControlHost(tlsResumptionAddress.getAddress().getHostAddress());
sslSocketFactory.setControlPort(tlsResumptionAddress.getPort()); 
setSocketFactory(sslSocketFactory);

ChannelSslServerSocketFactory sslServerSocketFactory = new 
ChannelSslServerSocketFactory( 
context); 

sslServerSocketFactory.setControlHost(tlsResumptionAddress.getAddress().getHostAddress());
   
sslServerSocketFactory.setControlPort(tlsResumptionAddress.getPort()); 
setServerSocketFactory(sslServerSocketFactory);
}
else { 
setSocketFactory(new FTPSSocketFactory(context, _socketFactory_)); 
setServerSocketFactory(new FTPSServerSocketFactory(context));
}
{code}

> problem connecting to ProFTPD with FTPES
> 
>
> Key: NET-408
> URL: https://issues.apache.org/jira/browse/NET-408
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 2.2, 3.0
> Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1 
> 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
> ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
> Java 1.5
>Reporter: Michael Voigt
>Priority: Major
> Attachments: BCFTPSClient.java, FTPSClientWithTLSResumption.zip, 
> PTFTPSClient.java, ftpes.jpg, proftpd.conf
>
>
> I have a problem with the FTPClient connecting to a ProFTPD server.
> If the server uses the configuration option "TLSProtocol TLSv1", I
> cannot connect to it at all. I recieve the following error message:
> - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
> On the server side I see in the log:
> unable to accept TLS connection: protocol error:
> -  (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate unknown
> - TLS/TLS-C negotiation failed on control channel
> If the server uses the configuration option "TLSProtocol SSLv23", I
> can connect to it but I cant transfer any files. In the server log I
> see:
> - starting TLS negotiation on data connection
> - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
> - client did not reuse SSL session, rejecting data connection (see
> TLSOption NoSessionReuseRequired)
> - unable to open data connection: TLS negotiation failed
> If I add the NoSessionReuseRequired parameter to the ProFTPD config
> everything works fine.
> Here is my code:
>FTPClient ftpClient = new FTPClient();
>ftpClient = new FTPSClient("TLS");
>// this throws an exception with TLSProtocol TLSv1
>ftpClient.connect(host, port);
>int reply = ftpClient.getReplyCode();
>if (!FTPReply.isPositiveCompletion(reply)) {
>ftpClient.disconnect();
>log.error("The FTP Server did not return a positive 
> completion reply!");
>throw new 
> FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
>}
>boolean loginSuccessful = ftpClient.login(userName, password);
>if (!loginSuccessful) {
>log.error("Login to the FTP Server failed! The 
> credentials are not valid.");
>throw new 
> FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
>}
>ftpClient.execPBSZ(0);
>ftpClient.execPROT("P");
>boolean success = ftpClient.storeFile(fileName, fis);
> 

[jira] [Commented] (NET-408) problem connecting to ProFTPD with FTPES

[Enrico Olivelli (Jira)]

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

Enrico Olivelli commented on NET-408:
-

[~elichtas]

I see you uploaded a zip file

is it some kind of patch ?

> problem connecting to ProFTPD with FTPES
> 
>
> Key: NET-408
> URL: https://issues.apache.org/jira/browse/NET-408
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 2.2, 3.0
> Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1 
> 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
> ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
> Java 1.5
>Reporter: Michael Voigt
>Priority: Major
> Attachments: BCFTPSClient.java, FTPSClientWithTLSResumption.zip, 
> PTFTPSClient.java, ftpes.jpg, proftpd.conf
>
>
> I have a problem with the FTPClient connecting to a ProFTPD server.
> If the server uses the configuration option "TLSProtocol TLSv1", I
> cannot connect to it at all. I recieve the following error message:
> - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
> On the server side I see in the log:
> unable to accept TLS connection: protocol error:
> -  (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate unknown
> - TLS/TLS-C negotiation failed on control channel
> If the server uses the configuration option "TLSProtocol SSLv23", I
> can connect to it but I cant transfer any files. In the server log I
> see:
> - starting TLS negotiation on data connection
> - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
> - client did not reuse SSL session, rejecting data connection (see
> TLSOption NoSessionReuseRequired)
> - unable to open data connection: TLS negotiation failed
> If I add the NoSessionReuseRequired parameter to the ProFTPD config
> everything works fine.
> Here is my code:
>FTPClient ftpClient = new FTPClient();
>ftpClient = new FTPSClient("TLS");
>// this throws an exception with TLSProtocol TLSv1
>ftpClient.connect(host, port);
>int reply = ftpClient.getReplyCode();
>if (!FTPReply.isPositiveCompletion(reply)) {
>ftpClient.disconnect();
>log.error("The FTP Server did not return a positive 
> completion reply!");
>throw new 
> FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
>}
>boolean loginSuccessful = ftpClient.login(userName, password);
>if (!loginSuccessful) {
>log.error("Login to the FTP Server failed! The 
> credentials are not valid.");
>throw new 
> FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
>}
>ftpClient.execPBSZ(0);
>ftpClient.execPROT("P");
>boolean success = ftpClient.storeFile(fileName, fis);
>if (!success) {
>// this is false if "NoSessionReuseRequired" is not set
>}
> Now my question is if it is generally possible to connect to a server
> with "TLSProtocol TLSv1" or "TLSProtocol SSLv23" without the
> "NoSessionReuseRequired" parameter? Could someone provide a piece of
> example code for this?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (NET-408) problem connecting to ProFTPD with FTPES

[Erick Lichtas (Jira)]

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

Erick Lichtas updated NET-408:
--
Attachment: FTPSClientWithTLSResumption.zip

> problem connecting to ProFTPD with FTPES
> 
>
> Key: NET-408
> URL: https://issues.apache.org/jira/browse/NET-408
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 2.2, 3.0
> Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1 
> 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
> ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
> Java 1.5
>Reporter: Michael Voigt
>Priority: Major
> Attachments: BCFTPSClient.java, FTPSClientWithTLSResumption.zip, 
> PTFTPSClient.java, ftpes.jpg, proftpd.conf
>
>
> I have a problem with the FTPClient connecting to a ProFTPD server.
> If the server uses the configuration option "TLSProtocol TLSv1", I
> cannot connect to it at all. I recieve the following error message:
> - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
> On the server side I see in the log:
> unable to accept TLS connection: protocol error:
> -  (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate unknown
> - TLS/TLS-C negotiation failed on control channel
> If the server uses the configuration option "TLSProtocol SSLv23", I
> can connect to it but I cant transfer any files. In the server log I
> see:
> - starting TLS negotiation on data connection
> - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
> - client did not reuse SSL session, rejecting data connection (see
> TLSOption NoSessionReuseRequired)
> - unable to open data connection: TLS negotiation failed
> If I add the NoSessionReuseRequired parameter to the ProFTPD config
> everything works fine.
> Here is my code:
>FTPClient ftpClient = new FTPClient();
>ftpClient = new FTPSClient("TLS");
>// this throws an exception with TLSProtocol TLSv1
>ftpClient.connect(host, port);
>int reply = ftpClient.getReplyCode();
>if (!FTPReply.isPositiveCompletion(reply)) {
>ftpClient.disconnect();
>log.error("The FTP Server did not return a positive 
> completion reply!");
>throw new 
> FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
>}
>boolean loginSuccessful = ftpClient.login(userName, password);
>if (!loginSuccessful) {
>log.error("Login to the FTP Server failed! The 
> credentials are not valid.");
>throw new 
> FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
>}
>ftpClient.execPBSZ(0);
>ftpClient.execPROT("P");
>boolean success = ftpClient.storeFile(fileName, fis);
>if (!success) {
>// this is false if "NoSessionReuseRequired" is not set
>}
> Now my question is if it is generally possible to connect to a server
> with "TLSProtocol TLSv1" or "TLSProtocol SSLv23" without the
> "NoSessionReuseRequired" parameter? Could someone provide a piece of
> example code for this?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (NET-408) problem connecting to ProFTPD with FTPES

[Erick Lichtas (Jira)]

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

Erick Lichtas updated NET-408:
--
Attachment: (was: FTPSClientWithTLSResumption.zip)

> problem connecting to ProFTPD with FTPES
> 
>
> Key: NET-408
> URL: https://issues.apache.org/jira/browse/NET-408
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 2.2, 3.0
> Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1 
> 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
> ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
> Java 1.5
>Reporter: Michael Voigt
>Priority: Major
> Attachments: BCFTPSClient.java, FTPSClientWithTLSResumption.zip, 
> PTFTPSClient.java, ftpes.jpg, proftpd.conf
>
>
> I have a problem with the FTPClient connecting to a ProFTPD server.
> If the server uses the configuration option "TLSProtocol TLSv1", I
> cannot connect to it at all. I recieve the following error message:
> - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
> On the server side I see in the log:
> unable to accept TLS connection: protocol error:
> -  (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate unknown
> - TLS/TLS-C negotiation failed on control channel
> If the server uses the configuration option "TLSProtocol SSLv23", I
> can connect to it but I cant transfer any files. In the server log I
> see:
> - starting TLS negotiation on data connection
> - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
> - client did not reuse SSL session, rejecting data connection (see
> TLSOption NoSessionReuseRequired)
> - unable to open data connection: TLS negotiation failed
> If I add the NoSessionReuseRequired parameter to the ProFTPD config
> everything works fine.
> Here is my code:
>FTPClient ftpClient = new FTPClient();
>ftpClient = new FTPSClient("TLS");
>// this throws an exception with TLSProtocol TLSv1
>ftpClient.connect(host, port);
>int reply = ftpClient.getReplyCode();
>if (!FTPReply.isPositiveCompletion(reply)) {
>ftpClient.disconnect();
>log.error("The FTP Server did not return a positive 
> completion reply!");
>throw new 
> FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
>}
>boolean loginSuccessful = ftpClient.login(userName, password);
>if (!loginSuccessful) {
>log.error("Login to the FTP Server failed! The 
> credentials are not valid.");
>throw new 
> FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
>}
>ftpClient.execPBSZ(0);
>ftpClient.execPROT("P");
>boolean success = ftpClient.storeFile(fileName, fis);
>if (!success) {
>// this is false if "NoSessionReuseRequired" is not set
>}
> Now my question is if it is generally possible to connect to a server
> with "TLSProtocol TLSv1" or "TLSProtocol SSLv23" without the
> "NoSessionReuseRequired" parameter? Could someone provide a piece of
> example code for this?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Work logged] (DBCP-566) Clear PreparedStatement pool when connection is returned to the pool

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/DBCP-566?focusedWorklogId=454802=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-454802
 ]

ASF GitHub Bot logged work on DBCP-566:
---

Author: ASF GitHub Bot
Created on: 06/Jul/20 12:17
Start Date: 06/Jul/20 12:17
Worklog Time Spent: 10m 
  Work Description: garydgregory commented on a change in pull request #42:
URL: https://github.com/apache/commons-dbcp/pull/42#discussion_r450180528



##
File path: src/main/java/org/apache/commons/dbcp2/BasicDataSourceMXBean.java
##
@@ -131,6 +131,13 @@ default String getDefaultSchema() {
  */
 boolean isPoolPreparedStatements();
 
+/**
+ * See {@link BasicDataSource#isClearStatementPoolOnReturn()}
+ * 
+ * @return {@link BasicDataSource#isClearStatementPoolOnReturn()}
+ */
+boolean isClearStatementPoolOnReturn();

Review comment:
   Not quite, the POM shows `2.8.0-SNAPSHOT` so the next version will be 
`2.8.0`.
   





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: 454802)
Time Spent: 1h 40m  (was: 1.5h)

> Clear PreparedStatement pool when connection is returned to the pool
> 
>
> Key: DBCP-566
> URL: https://issues.apache.org/jira/browse/DBCP-566
> Project: Commons DBCP
>  Issue Type: New Feature
>Reporter: Robert Paschek
>Priority: Major
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> With the current configuration option poolPreparedStatements true the 
> statements are held open for the lifetime of the connection. This results in 
> cursors being open and locks in the database for a long time, which could 
> cause problems with administrative tasks in the database.
> There should be an additional configuration clearStatementPoolOnReturn. When 
> set to true, the pool will be cleared and the statements closed when the 
> connection is returned to the pool. Default can be false to retain the 
> current behaviour.
> With this the application can still benefit from the Statement-cache in mass 
> operations.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-dbcp] garydgregory commented on a change in pull request #42: DBCP-566: clearStatementPoolOnReturn

[GitBox]

garydgregory commented on a change in pull request #42:
URL: https://github.com/apache/commons-dbcp/pull/42#discussion_r450180528



##
File path: src/main/java/org/apache/commons/dbcp2/BasicDataSourceMXBean.java
##
@@ -131,6 +131,13 @@ default String getDefaultSchema() {
  */
 boolean isPoolPreparedStatements();
 
+/**
+ * See {@link BasicDataSource#isClearStatementPoolOnReturn()}
+ * 
+ * @return {@link BasicDataSource#isClearStatementPoolOnReturn()}
+ */
+boolean isClearStatementPoolOnReturn();

Review comment:
   Not quite, the POM shows `2.8.0-SNAPSHOT` so the next version will be 
`2.8.0`.
   





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

[jira] [Work logged] (DBCP-566) Clear PreparedStatement pool when connection is returned to the pool

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/DBCP-566?focusedWorklogId=454739=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-454739
 ]

ASF GitHub Bot logged work on DBCP-566:
---

Author: ASF GitHub Bot
Created on: 06/Jul/20 08:23
Start Date: 06/Jul/20 08:23
Worklog Time Spent: 10m 
  Work Description: robertPas commented on a change in pull request #42:
URL: https://github.com/apache/commons-dbcp/pull/42#discussion_r450060557



##
File path: src/main/java/org/apache/commons/dbcp2/BasicDataSourceMXBean.java
##
@@ -131,6 +131,13 @@ default String getDefaultSchema() {
  */
 boolean isPoolPreparedStatements();
 
+/**
+ * See {@link BasicDataSource#isClearStatementPoolOnReturn()}
+ * 
+ * @return {@link BasicDataSource#isClearStatementPoolOnReturn()}
+ */
+boolean isClearStatementPoolOnReturn();

Review comment:
   The next version (for `since`) will be 2.8?





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: 454739)
Time Spent: 1.5h  (was: 1h 20m)

> Clear PreparedStatement pool when connection is returned to the pool
> 
>
> Key: DBCP-566
> URL: https://issues.apache.org/jira/browse/DBCP-566
> Project: Commons DBCP
>  Issue Type: New Feature
>Reporter: Robert Paschek
>Priority: Major
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> With the current configuration option poolPreparedStatements true the 
> statements are held open for the lifetime of the connection. This results in 
> cursors being open and locks in the database for a long time, which could 
> cause problems with administrative tasks in the database.
> There should be an additional configuration clearStatementPoolOnReturn. When 
> set to true, the pool will be cleared and the statements closed when the 
> connection is returned to the pool. Default can be false to retain the 
> current behaviour.
> With this the application can still benefit from the Statement-cache in mass 
> operations.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-dbcp] robertPas commented on a change in pull request #42: DBCP-566: clearStatementPoolOnReturn

[GitBox]

robertPas commented on a change in pull request #42:
URL: https://github.com/apache/commons-dbcp/pull/42#discussion_r450060557



##
File path: src/main/java/org/apache/commons/dbcp2/BasicDataSourceMXBean.java
##
@@ -131,6 +131,13 @@ default String getDefaultSchema() {
  */
 boolean isPoolPreparedStatements();
 
+/**
+ * See {@link BasicDataSource#isClearStatementPoolOnReturn()}
+ * 
+ * @return {@link BasicDataSource#isClearStatementPoolOnReturn()}
+ */
+boolean isClearStatementPoolOnReturn();

Review comment:
   The next version (for `since`) will be 2.8?





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

[jira] [Comment Edited] (COMPRESS-539) TarArchiveInputStream allocates a lot of memory when iterating through an archive

[Peter Lee (Jira)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151815#comment-17151815
 ] 

Peter Lee edited comment on COMPRESS-539 at 7/6/20, 7:43 AM:
-

Just have read COMPRESS-449. So this is about the performance. Will revert the 
IOUtils.skip soon.

I'm interested about in which scenario the InputStream.skip would achieve a 
much better performance than the InputStream.Read? From my view this is mostly 
happened in InputStream that supports InputStream.seek - the skip could seek 
instead of reading to skip bytes.

 

_Maybe the only solution for streams that do not override the skip method would 
be to change the implementation in the InputStream class to use a fix buffer 
instead always allocate a new one. But there could be a chance that this is 
expected by the Java library developers._

[~rschimpf] -seems this's a better solution - unfortunately this could only 
conducted by JDK developers.-

Update : I made a twice think about this and believe this may not be a good 
enouth solution - there're so many input streams that are inherited from the 
default InputStream. Making the skip buffer a static one may help in your case 
but may also lead to some unnecessary memory usage. I would be pretty cautious 
about the static memory malloc if I was the JDK maintainer - it's pretty hard 
to gc them.

Maybe wrapping the InputStream with SkipShieldingInputStream in Commons 
Compress is a better choice here.


was (Author: peterlee):
Just have read COMPRESS-449. So this is about the performance. Will revert the 
IOUtils.skip soon.

I'm interested about in which scenario the InputStream.skip would achieve a 
much better performance than the InputStream.Read? From my view this is mostly 
happened in InputStream that supports InputStream.seek - the skip could seek 
instead of reading to skip bytes.

 

_Maybe the only solution for streams that do not override the skip method would 
be to change the implementation in the InputStream class to use a fix buffer 
instead always allocate a new one. But there could be a chance that this is 
expected by the Java library developers._

[~rschimpf] seems this's a better solution - unfortunately this could only 
conducted by JDK developers.

> TarArchiveInputStream allocates a lot of memory when iterating through an 
> archive
> -
>
> Key: COMPRESS-539
> URL: https://issues.apache.org/jira/browse/COMPRESS-539
> Project: Commons Compress
>  Issue Type: Bug
>Affects Versions: 1.20
>Reporter: Robin Schimpf
>Assignee: Peter Lee
>Priority: Major
> Attachments: Don't_call_InputStream#skip.patch, 
> Reuse_recordBuffer.patch, image-2020-06-21-10-58-07-917.png, 
> image-2020-06-21-10-58-43-255.png, image-2020-06-21-10-59-10-825.png, 
> image-2020-07-05-22-10-07-402.png, image-2020-07-05-22-11-25-526.png, 
> image-2020-07-05-22-32-15-131.png, image-2020-07-05-22-32-31-511.png
>
>
>  I iterated through the linux source tar and noticed some unneeded 
> allocations happen without extracting any data.
> Reproducing code
> {code:java}
> File tarFile = new File("linux-5.7.1.tar");
> try (TarArchiveInputStream in = new 
> TarArchiveInputStream(Files.newInputStream(tarFile.toPath( {
> TarArchiveEntry entry;
> while ((entry = in.getNextTarEntry()) != null) {
> }
> }
> {code}
> The measurement was done on Java 11.0.7 with the Java Flight Recorder. 
> Options used: 
> -XX:StartFlightRecording=settings=profile,filename=allocations.jfr
> Baseline with the current master implementation:
>  Estimated TLAB allocation: 293MiB
> !image-2020-06-21-10-58-07-917.png!
> 1. IOUtils.skip -> input.skip(numToSkip)
>  This delegates in my test scenario to the InputStream.skip implementation 
> which allocates a new byte[] for every invocation. By simply commenting out 
> the while loop which calls the skip method the estimated TLAB allocation 
> drops to 164MiB (-129MiB).
>  !image-2020-06-21-10-58-43-255.png! 
>  Commenting out the skip call does not seem to be the best solution but it 
> was quick for me to see how much memory can be saved. Also no unit tests 
> where failing for me.
> 2. TarArchiveInputStream.readRecord
>  For every read of the record a new byte[] is created. Since the record size 
> does not change the byte[] can be reused and created when instantiating the 
> TarStream. This optimization is already present in the 
> TarArchiveOutputStream. Reusing the buffer reduces the estimated TLAB 
> allocations further to 128MiB (-36MiB).
>  !image-2020-06-21-10-59-10-825.png!
> I attached the patches I used so the results can be verified.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (COMPRESS-539) TarArchiveInputStream allocates a lot of memory when iterating through an archive

[Peter Lee (Jira)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151815#comment-17151815
 ] 

Peter Lee edited comment on COMPRESS-539 at 7/6/20, 7:10 AM:
-

Just have read COMPRESS-449. So this is about the performance. Will revert the 
IOUtils.skip soon.

I'm interested about in which scenario the InputStream.skip would achieve a 
much better performance than the InputStream.Read? From my view this is mostly 
happened in InputStream that supports InputStream.seek - the skip could seek 
instead of reading to skip bytes.

 

_Maybe the only solution for streams that do not override the skip method would 
be to change the implementation in the InputStream class to use a fix buffer 
instead always allocate a new one. But there could be a chance that this is 
expected by the Java library developers._

[~rschimpf] seems this's a better solution - unfortunately this could only 
conducted by JDK developers.


was (Author: peterlee):
Just have read COMPRESS-449. So this is about the performance. Will revert the 
IOUtils.skip soon.

I'm interested about in which scenario the InputStream.skip would achieve a 
much better performance than the InputStream.Read? From my view this is mostly 
happened in InputStream that supports InputStream.seek - the skip could seek 
instead of reading to skip bytes.

> TarArchiveInputStream allocates a lot of memory when iterating through an 
> archive
> -
>
> Key: COMPRESS-539
> URL: https://issues.apache.org/jira/browse/COMPRESS-539
> Project: Commons Compress
>  Issue Type: Bug
>Affects Versions: 1.20
>Reporter: Robin Schimpf
>Assignee: Peter Lee
>Priority: Major
> Attachments: Don't_call_InputStream#skip.patch, 
> Reuse_recordBuffer.patch, image-2020-06-21-10-58-07-917.png, 
> image-2020-06-21-10-58-43-255.png, image-2020-06-21-10-59-10-825.png, 
> image-2020-07-05-22-10-07-402.png, image-2020-07-05-22-11-25-526.png, 
> image-2020-07-05-22-32-15-131.png, image-2020-07-05-22-32-31-511.png
>
>
>  I iterated through the linux source tar and noticed some unneeded 
> allocations happen without extracting any data.
> Reproducing code
> {code:java}
> File tarFile = new File("linux-5.7.1.tar");
> try (TarArchiveInputStream in = new 
> TarArchiveInputStream(Files.newInputStream(tarFile.toPath( {
> TarArchiveEntry entry;
> while ((entry = in.getNextTarEntry()) != null) {
> }
> }
> {code}
> The measurement was done on Java 11.0.7 with the Java Flight Recorder. 
> Options used: 
> -XX:StartFlightRecording=settings=profile,filename=allocations.jfr
> Baseline with the current master implementation:
>  Estimated TLAB allocation: 293MiB
> !image-2020-06-21-10-58-07-917.png!
> 1. IOUtils.skip -> input.skip(numToSkip)
>  This delegates in my test scenario to the InputStream.skip implementation 
> which allocates a new byte[] for every invocation. By simply commenting out 
> the while loop which calls the skip method the estimated TLAB allocation 
> drops to 164MiB (-129MiB).
>  !image-2020-06-21-10-58-43-255.png! 
>  Commenting out the skip call does not seem to be the best solution but it 
> was quick for me to see how much memory can be saved. Also no unit tests 
> where failing for me.
> 2. TarArchiveInputStream.readRecord
>  For every read of the record a new byte[] is created. Since the record size 
> does not change the byte[] can be reused and created when instantiating the 
> TarStream. This optimization is already present in the 
> TarArchiveOutputStream. Reusing the buffer reduces the estimated TLAB 
> allocations further to 128MiB (-36MiB).
>  !image-2020-06-21-10-59-10-825.png!
> I attached the patches I used so the results can be verified.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (COMPRESS-539) TarArchiveInputStream allocates a lot of memory when iterating through an archive

[Peter Lee (Jira)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151815#comment-17151815
 ] 

Peter Lee commented on COMPRESS-539:


Just have read COMPRESS-449. So this is about the performance. Will revert the 
IOUtils.skip soon.

I'm interested about in which scenario the InputStream.skip would achieve a 
much better performance than the InputStream.Read? From my view this is mostly 
happened in InputStream that supports InputStream.seek - the skip could seek 
instead of reading to skip bytes.

> TarArchiveInputStream allocates a lot of memory when iterating through an 
> archive
> -
>
> Key: COMPRESS-539
> URL: https://issues.apache.org/jira/browse/COMPRESS-539
> Project: Commons Compress
>  Issue Type: Bug
>Affects Versions: 1.20
>Reporter: Robin Schimpf
>Assignee: Peter Lee
>Priority: Major
> Attachments: Don't_call_InputStream#skip.patch, 
> Reuse_recordBuffer.patch, image-2020-06-21-10-58-07-917.png, 
> image-2020-06-21-10-58-43-255.png, image-2020-06-21-10-59-10-825.png, 
> image-2020-07-05-22-10-07-402.png, image-2020-07-05-22-11-25-526.png, 
> image-2020-07-05-22-32-15-131.png, image-2020-07-05-22-32-31-511.png
>
>
>  I iterated through the linux source tar and noticed some unneeded 
> allocations happen without extracting any data.
> Reproducing code
> {code:java}
> File tarFile = new File("linux-5.7.1.tar");
> try (TarArchiveInputStream in = new 
> TarArchiveInputStream(Files.newInputStream(tarFile.toPath( {
> TarArchiveEntry entry;
> while ((entry = in.getNextTarEntry()) != null) {
> }
> }
> {code}
> The measurement was done on Java 11.0.7 with the Java Flight Recorder. 
> Options used: 
> -XX:StartFlightRecording=settings=profile,filename=allocations.jfr
> Baseline with the current master implementation:
>  Estimated TLAB allocation: 293MiB
> !image-2020-06-21-10-58-07-917.png!
> 1. IOUtils.skip -> input.skip(numToSkip)
>  This delegates in my test scenario to the InputStream.skip implementation 
> which allocates a new byte[] for every invocation. By simply commenting out 
> the while loop which calls the skip method the estimated TLAB allocation 
> drops to 164MiB (-129MiB).
>  !image-2020-06-21-10-58-43-255.png! 
>  Commenting out the skip call does not seem to be the best solution but it 
> was quick for me to see how much memory can be saved. Also no unit tests 
> where failing for me.
> 2. TarArchiveInputStream.readRecord
>  For every read of the record a new byte[] is created. Since the record size 
> does not change the byte[] can be reused and created when instantiating the 
> TarStream. This optimization is already present in the 
> TarArchiveOutputStream. Reusing the buffer reduces the estimated TLAB 
> allocations further to 128MiB (-36MiB).
>  !image-2020-06-21-10-59-10-825.png!
> I attached the patches I used so the results can be verified.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Work logged] (COLLECTIONS-607) Adding a hash table based BidiMap

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-607?focusedWorklogId=454708=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-454708
 ]

ASF GitHub Bot logged work on COLLECTIONS-607:
--

Author: ASF GitHub Bot
Created on: 06/Jul/20 06:38
Start Date: 06/Jul/20 06:38
Worklog Time Spent: 10m 
  Work Description: dota17 closed pull request #145:
URL: https://github.com/apache/commons-collections/pull/145


   



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: 454708)
Remaining Estimate: 334h 40m  (was: 334h 50m)
Time Spent: 1h 20m  (was: 1h 10m)

> Adding a hash table based BidiMap
> -
>
> Key: COLLECTIONS-607
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-607
> Project: Commons Collections
>  Issue Type: New Feature
>  Components: BidiMap
>Reporter: Rodion Efremov
>Priority: Minor
>  Labels: features, newbie
>   Original Estimate: 336h
>  Time Spent: 1h 20m
>  Remaining Estimate: 334h 40m
>
> In the class Javadoc of 
> http://svn.apache.org/viewvc/commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/bidimap/DualHashBidiMap.java?view=markup
>  
> there is a mention that Collections would welcome a direct hash-based 
> implementation of BidiMap interface.
> I am working on such; my source is available at 
> https://github.com/coderodde/BidirectionalHashMap
> At this point it does not adhere to style/interfaces of Commons Collections 
> (such as implementing the BidiMap interface), yet I believe that is a matter 
> of simple rewrite.
> Currently, it represents the "collision chains" as AVL-trees, thus 
> guaranteeing O(log n) access/modification even on poor hash functions. If 
> that is not required, rewriting would be trivial as well.
> I have several questions, but I have to start from the most important: is 
> there any acute need for such a data structure?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-collections] dota17 closed pull request #145: [COLLECTIONS-607] BidirectionalHashMap

[GitBox]

dota17 closed pull request #145:
URL: https://github.com/apache/commons-collections/pull/145


   



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