[GitHub] [commons-io] kinow commented on pull request #351: chore: Set permissions for GitHub actions
kinow commented on PR #351: URL: https://github.com/apache/commons-io/pull/351#issuecomment-1110194505 > @kinow are you doing this for all Commons components? Sounds like a good idea I think. I'll start with Commons Imaging/Text/IO/etc, the ones I normally change. Then slowly go over others (feel free to modify any of the other components if you'd like :+1: ) -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (IO-279) Tailer erroneously considers file as new
[
https://issues.apache.org/jira/browse/IO-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528366#comment-17528366
]
Gary D. Gregory commented on IO-279:
Hello [~Apoorva Maheshwari]
2.7 is old, please check the current version. If you bnb want anything done,
feel free to provide a PR on GitHub ;-)
> Tailer erroneously considers file as new
>
>
> Key: IO-279
> URL: https://issues.apache.org/jira/browse/IO-279
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.0.1, 2.4
>Reporter: Sergio Bossa
>Priority: Major
> Attachments: IO-279.patch, disable_resetting.patch, fix-tailer.patch,
> modify-test-fixed.patch, modify-test.patch
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Tailer sometimes erroneously considers the tailed file as new, forcing a
> repositioning at the start of the file: I'm still unable to reproduce this in
> a test case, because it only happens to me with huge log files during Apache
> Tomcat startup.
> This is the piece of code causing the problem:
> {code}
> // See if the file needs to be read again
> if (length > position) {
> // The file has more content than it did last time
> last = System.currentTimeMillis();
> position = readLines(reader);
> } else if (FileUtils.isFileNewer(file, last)) {
> /* This can happen if the file is truncated or overwritten
> * with the exact same length of information. In cases like
> * this, the file position needs to be reset
> */
> position = 0;
> reader.seek(position); // cannot be null here
> // Now we can read new lines
> last = System.currentTimeMillis();
> position = readLines(reader);
> }
> {code}
> What probably happens is that the new file content is about to be written on
> disk, the date is already updated but content is still not flushed, so actual
> length is untouched and there you go.
> In other words, I think there should be some better method to verify the
> condition above, rather than relying only on dates: keeping and comparing the
> hash code of the latest line may be a solution, but may hurt performances ...
> other ideas?
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [commons-io] garydgregory commented on pull request #351: chore: Set permissions for GitHub actions
garydgregory commented on PR #351: URL: https://github.com/apache/commons-io/pull/351#issuecomment-1110156877 @kinow are you doing this for all Commons components? -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (JEXL-367) Deprecate -> and support =>
[ https://issues.apache.org/jira/browse/JEXL-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hussachai Puripunpinyo updated JEXL-367: Description: The JEXL code surprisingly looks a lot like Javascript. I think this change is a good transition for folks to update the code, and it's pretty fine if they can tolerate using the deprecate syntax and don't mind seeing a warning log pop up every time. I'd like to propose supporting => and deprecate ->. The reasons are - JavaScript becomes very popular and many people are familiar with it. - JEXL is more like for a quick short script. In many scenarios, the target audiences are not a programer. They often mistake a language as a JavaScript (from my experience). - JEXL syntax already looks a lot like JavaScript -- var for variable declaration (Java added in Java 10, but JavaScript supports this from the beginning) -- The function keyword -- Implicit type coercion -- Ternary operator The proposed change. * Support => in addition to -> * Deprecate -> and show a warning log when it's used. was: The JEXL code surprisingly looks a lot like Javascript. I think this change is a good transition for folks to update the code, and it's pretty fine if they can tolerate using the deprecate syntax and don't mind seeing a warning log pop up every time. I'd like to propose supporting => and deprecate ->. The reasons are - JavaScript becomes very popular and many people are familiar with it. - JEXL is more like for a quick short script. In many scenarios, the target audiences are not a programer. They often mistake a language as a JavaScript (from my experience). - JEXL syntax already looks a lot like JavaScript - var for variable declaration (Java added in Java 10, but JavaScript supports this from the beginning) - The function keyword - Implicit type coercion - Ternary operator The proposed change. * Support => in addition to -> * Deprecate -> and show a warning log when it's used. > Deprecate -> and support => > --- > > Key: JEXL-367 > URL: https://issues.apache.org/jira/browse/JEXL-367 > Project: Commons JEXL > Issue Type: Wish >Reporter: Hussachai Puripunpinyo >Priority: Major > > The JEXL code surprisingly looks a lot like Javascript. I think this change > is a good transition for folks to update the code, and it's pretty fine if > they can tolerate using the deprecate syntax and don't mind seeing a warning > log pop up every time. > I'd like to propose supporting => and deprecate ->. > The reasons are > - JavaScript becomes very popular and many people are familiar with it. > - JEXL is more like for a quick short script. In many scenarios, the target > audiences are not a programer. They often mistake a language as a JavaScript > (from my experience). > - JEXL syntax already looks a lot like JavaScript > -- var for variable declaration (Java added in Java 10, but JavaScript > supports this from the beginning) > -- The function keyword > -- Implicit type coercion > -- Ternary operator > The proposed change. > * Support => in addition to -> > * Deprecate -> and show a warning log when it's used. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (JEXL-366) Fail to evaluate string and number comparison
[
https://issues.apache.org/jira/browse/JEXL-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528354#comment-17528354
]
Hussachai Puripunpinyo commented on JEXL-366:
-
Thank you Henri. Yes, I do have a workaround, and I don't need this change. I
created this Jira and PR because I think it doesn't look right that '1' == 1
works fine while '1.0' == 1 will blow up. So I assume it's a bug, but let me
know if that's intended.
> Fail to evaluate string and number comparison
> -
>
> Key: JEXL-366
> URL: https://issues.apache.org/jira/browse/JEXL-366
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Hussachai Puripunpinyo
>Priority: Major
>
> The comparison logic doesn't cover the case when one operand is a string and
> another operand is a numerable type (int, short, long,..).
> The expected result for '1.0' == 1 should be true but it fails because the
> string comparison check is after the numerable type check. JEXL tries to
> parse '1.0' using toLong function and it fails with this error message `For
> input string: "1.0"`
> Moving a string comparison up before other number type checks will not cover
> some corner cases such as
> '1.00' == 1.0 // String comparison will yield false but it obviously doesn't
> make sense.
> The proposed change is to add the following code to handle the corner case
> when one operand is string and another operand is numerable. To cover this
> corner case, we can apply toBigDecimal to both *lhs* and *rhs* since it
> should cover any arbitrary number in a string form, and it handles other
> number types well.
> {code:java}
> if (isNumberable(left) || isNumberable(right)) {
> if (left instanceof String || right instanceof String) {
> final BigDecimal l = toBigDecimal(left);
> final BigDecimal r = toBigDecimal(right);
> return l.compareTo(r);
> } else {
> // this code block remains the same
> }
> return 0;
> } {code}
> JEXL syntax is very similar to ECMA script except a few small set that are
> not the same. So, I think following the ECMA spec for this comparison check
> makes sense.
> The following code is JavaScript and it can be used in the JEXL test to make
> sure that the behavior of comparison are the same.
> Note that '1.0' == 1 yields true
> {code:java}
> function assert(condition, source) {
> if (!condition) {
> throw `Assertion failed for ${source}`;
> }
> }
> // Basic compare
> let exprs = [
> "1 == 1", true,
> "1 != 1", false,
> "1 != 2", true,
> "1 > 2", false,
> "1 >= 2", false,
> "1 < 2", true,
> "1 <= 2", true,
> // Int <-> Float Coercion
> "1.0 == 1", true,
> "1 == 1.0", true,
> "1.1 != 1", true,
> "1.1 < 2", true,
> // numbers and strings
> "'1' == 1", true,
> "'' == 0", true, // empty string is coerced to zero (ECMA compliance)
> "1.0 >= '1'", true,
> "1.0 > '1'", false
> ];for (e = 0; e < exprs.length; e += 2) {
> let stext = exprs[e];
> let expected = exprs[e + 1];
> assert(eval(stext) == expected, stext);
>
> } {code}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (JEXL-367) Deprecate -> and support =>
Hussachai Puripunpinyo created JEXL-367: --- Summary: Deprecate -> and support => Key: JEXL-367 URL: https://issues.apache.org/jira/browse/JEXL-367 Project: Commons JEXL Issue Type: Wish Reporter: Hussachai Puripunpinyo The JEXL code surprisingly looks a lot like Javascript. I think this change is a good transition for folks to update the code, and it's pretty fine if they can tolerate using the deprecate syntax and don't mind seeing a warning log pop up every time. I'd like to propose supporting => and deprecate ->. The reasons are - JavaScript becomes very popular and many people are familiar with it. - JEXL is more like for a quick short script. In many scenarios, the target audiences are not a programer. They often mistake a language as a JavaScript (from my experience). - JEXL syntax already looks a lot like JavaScript - var for variable declaration (Java added in Java 10, but JavaScript supports this from the beginning) - The function keyword - Implicit type coercion - Ternary operator The proposed change. * Support => in addition to -> * Deprecate -> and show a warning log when it's used. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (JEXL-366) Fail to evaluate string and number comparison
[
https://issues.apache.org/jira/browse/JEXL-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528349#comment-17528349
]
Henri Biestro commented on JEXL-366:
Thank you for the detailed issue and PR.
I guess you already know you can derive your own JexlArithmetic and how to use
it as a workaround; otherwise, let me know, I'll help.
> Fail to evaluate string and number comparison
> -
>
> Key: JEXL-366
> URL: https://issues.apache.org/jira/browse/JEXL-366
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Hussachai Puripunpinyo
>Priority: Major
>
> The comparison logic doesn't cover the case when one operand is a string and
> another operand is a numerable type (int, short, long,..).
> The expected result for '1.0' == 1 should be true but it fails because the
> string comparison check is after the numerable type check. JEXL tries to
> parse '1.0' using toLong function and it fails with this error message `For
> input string: "1.0"`
> Moving a string comparison up before other number type checks will not cover
> some corner cases such as
> '1.00' == 1.0 // String comparison will yield false but it obviously doesn't
> make sense.
> The proposed change is to add the following code to handle the corner case
> when one operand is string and another operand is numerable. To cover this
> corner case, we can apply toBigDecimal to both *lhs* and *rhs* since it
> should cover any arbitrary number in a string form, and it handles other
> number types well.
> {code:java}
> if (isNumberable(left) || isNumberable(right)) {
> if (left instanceof String || right instanceof String) {
> final BigDecimal l = toBigDecimal(left);
> final BigDecimal r = toBigDecimal(right);
> return l.compareTo(r);
> } else {
> // this code block remains the same
> }
> return 0;
> } {code}
> JEXL syntax is very similar to ECMA script except a few small set that are
> not the same. So, I think following the ECMA spec for this comparison check
> makes sense.
> The following code is JavaScript and it can be used in the JEXL test to make
> sure that the behavior of comparison are the same.
> Note that '1.0' == 1 yields true
> {code:java}
> function assert(condition, source) {
> if (!condition) {
> throw `Assertion failed for ${source}`;
> }
> }
> // Basic compare
> let exprs = [
> "1 == 1", true,
> "1 != 1", false,
> "1 != 2", true,
> "1 > 2", false,
> "1 >= 2", false,
> "1 < 2", true,
> "1 <= 2", true,
> // Int <-> Float Coercion
> "1.0 == 1", true,
> "1 == 1.0", true,
> "1.1 != 1", true,
> "1.1 < 2", true,
> // numbers and strings
> "'1' == 1", true,
> "'' == 0", true, // empty string is coerced to zero (ECMA compliance)
> "1.0 >= '1'", true,
> "1.0 > '1'", false
> ];for (e = 0; e < exprs.length; e += 2) {
> let stext = exprs[e];
> let expected = exprs[e + 1];
> assert(eval(stext) == expected, stext);
>
> } {code}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (JEXL-366) Fail to evaluate string and number comparison
[
https://issues.apache.org/jira/browse/JEXL-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-366:
---
Affects Version/s: 3.2.1
> Fail to evaluate string and number comparison
> -
>
> Key: JEXL-366
> URL: https://issues.apache.org/jira/browse/JEXL-366
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Hussachai Puripunpinyo
>Priority: Major
>
> The comparison logic doesn't cover the case when one operand is a string and
> another operand is a numerable type (int, short, long,..).
> The expected result for '1.0' == 1 should be true but it fails because the
> string comparison check is after the numerable type check. JEXL tries to
> parse '1.0' using toLong function and it fails with this error message `For
> input string: "1.0"`
> Moving a string comparison up before other number type checks will not cover
> some corner cases such as
> '1.00' == 1.0 // String comparison will yield false but it obviously doesn't
> make sense.
> The proposed change is to add the following code to handle the corner case
> when one operand is string and another operand is numerable. To cover this
> corner case, we can apply toBigDecimal to both *lhs* and *rhs* since it
> should cover any arbitrary number in a string form, and it handles other
> number types well.
> {code:java}
> if (isNumberable(left) || isNumberable(right)) {
> if (left instanceof String || right instanceof String) {
> final BigDecimal l = toBigDecimal(left);
> final BigDecimal r = toBigDecimal(right);
> return l.compareTo(r);
> } else {
> // this code block remains the same
> }
> return 0;
> } {code}
> JEXL syntax is very similar to ECMA script except a few small set that are
> not the same. So, I think following the ECMA spec for this comparison check
> makes sense.
> The following code is JavaScript and it can be used in the JEXL test to make
> sure that the behavior of comparison are the same.
> Note that '1.0' == 1 yields true
> {code:java}
> function assert(condition, source) {
> if (!condition) {
> throw `Assertion failed for ${source}`;
> }
> }
> // Basic compare
> let exprs = [
> "1 == 1", true,
> "1 != 1", false,
> "1 != 2", true,
> "1 > 2", false,
> "1 >= 2", false,
> "1 < 2", true,
> "1 <= 2", true,
> // Int <-> Float Coercion
> "1.0 == 1", true,
> "1 == 1.0", true,
> "1.1 != 1", true,
> "1.1 < 2", true,
> // numbers and strings
> "'1' == 1", true,
> "'' == 0", true, // empty string is coerced to zero (ECMA compliance)
> "1.0 >= '1'", true,
> "1.0 > '1'", false
> ];for (e = 0; e < exprs.length; e += 2) {
> let stext = exprs[e];
> let expected = exprs[e + 1];
> assert(eval(stext) == expected, stext);
>
> } {code}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (JEXL-366) Fail to evaluate string and number comparison
[
https://issues.apache.org/jira/browse/JEXL-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-366:
---
Issue Type: Improvement (was: Bug)
> Fail to evaluate string and number comparison
> -
>
> Key: JEXL-366
> URL: https://issues.apache.org/jira/browse/JEXL-366
> Project: Commons JEXL
> Issue Type: Improvement
>Reporter: Hussachai Puripunpinyo
>Priority: Major
>
> The comparison logic doesn't cover the case when one operand is a string and
> another operand is a numerable type (int, short, long,..).
> The expected result for '1.0' == 1 should be true but it fails because the
> string comparison check is after the numerable type check. JEXL tries to
> parse '1.0' using toLong function and it fails with this error message `For
> input string: "1.0"`
> Moving a string comparison up before other number type checks will not cover
> some corner cases such as
> '1.00' == 1.0 // String comparison will yield false but it obviously doesn't
> make sense.
> The proposed change is to add the following code to handle the corner case
> when one operand is string and another operand is numerable. To cover this
> corner case, we can apply toBigDecimal to both *lhs* and *rhs* since it
> should cover any arbitrary number in a string form, and it handles other
> number types well.
> {code:java}
> if (isNumberable(left) || isNumberable(right)) {
> if (left instanceof String || right instanceof String) {
> final BigDecimal l = toBigDecimal(left);
> final BigDecimal r = toBigDecimal(right);
> return l.compareTo(r);
> } else {
> // this code block remains the same
> }
> return 0;
> } {code}
> JEXL syntax is very similar to ECMA script except a few small set that are
> not the same. So, I think following the ECMA spec for this comparison check
> makes sense.
> The following code is JavaScript and it can be used in the JEXL test to make
> sure that the behavior of comparison are the same.
> Note that '1.0' == 1 yields true
> {code:java}
> function assert(condition, source) {
> if (!condition) {
> throw `Assertion failed for ${source}`;
> }
> }
> // Basic compare
> let exprs = [
> "1 == 1", true,
> "1 != 1", false,
> "1 != 2", true,
> "1 > 2", false,
> "1 >= 2", false,
> "1 < 2", true,
> "1 <= 2", true,
> // Int <-> Float Coercion
> "1.0 == 1", true,
> "1 == 1.0", true,
> "1.1 != 1", true,
> "1.1 < 2", true,
> // numbers and strings
> "'1' == 1", true,
> "'' == 0", true, // empty string is coerced to zero (ECMA compliance)
> "1.0 >= '1'", true,
> "1.0 > '1'", false
> ];for (e = 0; e < exprs.length; e += 2) {
> let stext = exprs[e];
> let expected = exprs[e + 1];
> assert(eval(stext) == expected, stext);
>
> } {code}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (JEXL-342) Support for Java Optional.
[
https://issues.apache.org/jira/browse/JEXL-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528307#comment-17528307
]
Hussachai Puripunpinyo commented on JEXL-342:
-
We forked JEXL at my company and I'd say JEXL code is very extensible. We
support Java Optional and other native bindings for Scala and Kotlin including
JSON types in the respective languages. We rarely touch the JEXL code to make
sure that we can sync the upstream when we need to. (The only thing that is
unavoidable like changing the visibility of the functions and classes so that
we can override). We change the language so much until it doesn't look like
JEXL :)
Anyway, I still think this is a useful feature. What about having extra package
and it can be in a separate jar?
> Support for Java Optional.
> --
>
> Key: JEXL-342
> URL: https://issues.apache.org/jira/browse/JEXL-342
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Garret Wilson
>Priority: Major
> Fix For: Later
>
>
> Does JEXL provide any native support for Java 8+ {{Optional<>}}? If not can
> this this easily be added as some sort of plugin, or better yet can it be
> added to the library?
> h3. {{Optional}} Traversal
> I need to create an API that works well for application developers as for
> those using templates with JEXL expressions. Let's say that the {{Bar}} class
> has a {{Bar.getName()}}. And the {{Foo}} class has this method:
> {code:java}
> Optional getBar(String barId);
> {code}
> In code getting the "test" foo-bar name would be like this:
> {code:java}
> String fooBarName=foo.getBar("test").map(Bar::getName).orElse(null);
> {code}
> I want the navigation across {{Optional<>}} to work just as if it were a
> nullable variable. That is, I want the following JEXL expression to give the
> same result as {{fooBarName}} above:
> {code}
> foo.bar("test").name
> {code}
> If {{Foo.getBar(String)}} returned a nullable rather than an {{Optional<>}},
> I think JEXL would work for this already. but the whole point of
> {{Optional<>}} is that I keep nullables out of my code, so I don't want to
> create inferior APIs inconsistent with the rest of my project just to work
> with JEXL.
> h3. {{Optional}} Getter Name
> As icing on the cake, I would like to have {{Optional<>}} returning getter
> discovery to recognize the {{findXXX}} pattern, as [Stephen Colebourne
> suggested|https://blog.joda.org/2015/09/naming-optional-query-methods.html].
> I've been using this pattern for several years, and I really like it. Thus to
> indicate that the {{Foo.getBar(String)}} "getter" doesn't return a nullable
> but an {{Optional<>}}, I would name it {{Foo.findBar(String)}}, like this:
> {code:java}
> Optional findBar(String barId);
> {code}
> I would thus want the exact same JEXL expression above to still work:
> {code}
> foo.bar("test").name
> {code}
> Otherwise I'll have to forego use of modern Java constructs and make an
> outdated style and less safe API just to get JEXL to work.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (DAEMON-441) When installing a Windows service using Commons Daemon 1.3.0 the errorlevel is -1073741819
[
https://issues.apache.org/jira/browse/DAEMON-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528280#comment-17528280
]
Brian Andle commented on DAEMON-441:
I don't have an environment setup to build this code so if we have binaries I
can/will try them out.
> When installing a Windows service using Commons Daemon 1.3.0 the errorlevel
> is -1073741819
> --
>
> Key: DAEMON-441
> URL: https://issues.apache.org/jira/browse/DAEMON-441
> Project: Commons Daemon
> Issue Type: Bug
>Affects Versions: 1.3.0
> Environment: Windows 2016 Datacenter
>Reporter: Brian Andle
>Priority: Major
> Attachments: Command_Prompt.png
>
>
> When attempting to use prunsrv.exe on Windows 2016 to create a service a
> Windows Event error is logged and the errorlevel is returned as -1073741819
> Running the following command:
> {code:java}
> prunsrv.exe //IS/MyService --Startup=auto --Description=My Service
> --DisplayName=My Service {code}
> Results in the following Windows Event Log entry
>
> {code:java}
> Faulting application name: prunsrv.exe, version: 1.3.0.0, time stamp:
> 0x622b3ac0
> Faulting module name: prunsrv.exe, version: 1.3.0.0, time stamp: 0x622b3ac0
> Exception code: 0xc005
> Fault offset: 0x6e70
> Faulting process id: 0x1d88
> Faulting application start time: 0x01d845f90eb4351a
> Faulting application path: C:\myfolder\prunsrv.exe
> Faulting module path: C:\myfolder\prunsrv.exe
> Report Id: 409b7098-42bd-4036-aa61-b19eecdb1bd7
> Faulting package full name:
> Faulting package-relative application ID: {code}
> Doing an echo %errorlevel% shows -1073741819 instead of the expected 0
> Version 1.2.4.0 works correctly on both Windows 10 and 2016
> *NOTE:* The service does appear to actually install on 2016, however most
> deploy scripts will expect an error level of 0 and will fail if a non 0 value
> it returned.
> h3. Workaround
> Define a *--LogPath* value and do not use the default
> %SystemRoot%\System32\LogFiles\Apache path
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (COLLECTIONS-770) ToString method is unresponsive after multiple SetUtils union calls
[
https://issues.apache.org/jira/browse/COLLECTIONS-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528252#comment-17528252
]
Ng Tsz Sum edited comment on COLLECTIONS-770 at 4/26/22 3:55 PM:
-
COLLECTIONS-722 This issue seems closely related
was (Author: samabcde):
This issue seems closely related
> ToString method is unresponsive after multiple SetUtils union calls
> ---
>
> Key: COLLECTIONS-770
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-770
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 4.4
>Reporter: Thomas Bürli
>Priority: Minor
> Attachments: SetUtilsTest.java, countHasNextCall.patch, stackdump.txt
>
>
> I had the following code and my application stopped responsing as soon the
> number of names for a userId got too big.
> {code:java}
>Map> stringMap = new TreeMap<>();
> for (String name : names) {
> for (String userId : userIds) {
> stringMap.merge(userId, Collections.singleton(name),
> SetUtils::union);
> }
> }
> {code}
> I did some debugging and it occurs when the toString method of one the set is
> called. It looks like the issues is with the iterator of "SetUtils.SetView".
> Here just the method I used to create test sets and in the attachment you
> find the full tests class and a stack dump. The execution time is growing
> exponentially with the numbers of times the SetUtils.union is called. So for
> 29 elements it took 16 seconds to execute toString, and with 30 it took 32
> seconds.
> {code:java}
> @Test
> void setWith20Elements() {
> assertTimeout(ofSeconds(2), () -> createSet(30).toString());
> }
> Set createSet(int number) {
> List inputs = new ArrayList<>();
> for (int i = 0; i < number; i++) {
>inputs.add("Test"+ i);
> }
> Set testSet = Collections.singleton("String1");
> for (String element : inputs) {
> Set part = Collections.singleton(element);
> testSet = SetUtils.union(testSet,part);
> }
> return testSet;
> }
> {code}
> Thanks for your support
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (COLLECTIONS-770) ToString method is unresponsive after multiple SetUtils union calls
[
https://issues.apache.org/jira/browse/COLLECTIONS-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528252#comment-17528252
]
Ng Tsz Sum commented on COLLECTIONS-770:
This issue seems closely related
> ToString method is unresponsive after multiple SetUtils union calls
> ---
>
> Key: COLLECTIONS-770
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-770
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 4.4
>Reporter: Thomas Bürli
>Priority: Minor
> Attachments: SetUtilsTest.java, countHasNextCall.patch, stackdump.txt
>
>
> I had the following code and my application stopped responsing as soon the
> number of names for a userId got too big.
> {code:java}
>Map> stringMap = new TreeMap<>();
> for (String name : names) {
> for (String userId : userIds) {
> stringMap.merge(userId, Collections.singleton(name),
> SetUtils::union);
> }
> }
> {code}
> I did some debugging and it occurs when the toString method of one the set is
> called. It looks like the issues is with the iterator of "SetUtils.SetView".
> Here just the method I used to create test sets and in the attachment you
> find the full tests class and a stack dump. The execution time is growing
> exponentially with the numbers of times the SetUtils.union is called. So for
> 29 elements it took 16 seconds to execute toString, and with 30 it took 32
> seconds.
> {code:java}
> @Test
> void setWith20Elements() {
> assertTimeout(ofSeconds(2), () -> createSet(30).toString());
> }
> Set createSet(int number) {
> List inputs = new ArrayList<>();
> for (int i = 0; i < number; i++) {
>inputs.add("Test"+ i);
> }
> Set testSet = Collections.singleton("String1");
> for (String element : inputs) {
> Set part = Collections.singleton(element);
> testSet = SetUtils.union(testSet,part);
> }
> return testSet;
> }
> {code}
> Thanks for your support
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (COLLECTIONS-770) ToString method is unresponsive after multiple SetUtils union calls
[
https://issues.apache.org/jira/browse/COLLECTIONS-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528243#comment-17528243
]
Ng Tsz Sum edited comment on COLLECTIONS-770 at 4/26/22 3:29 PM:
-
After some test, the problem is the huge number of IteratorChain#hasNext call,
but why the count growth so fast need further investigation.
Below result can be verified with attached patch [^countHasNextCall.patch]
||number||hasNext_count||
|1|3|
|2|11|
|3|30|
|4|72|
|5|161|
|6|345|
|7|720|
|8|1478|
|9|3003|
|10|6063|
|11|12194|
|12|24468|
|13|49029|
|14|98165|
|15|196452|
|16|393042|
|17|786239|
|18|1572651|
|19|3145494|
|20|6291200|
|21|12582633|
|22|25165521|
|23|50331320|
|24|100662942|
|25|201326211|
|26|402652775|
|27|805305930|
|28|1610612268|
|29|3221224973|
|30|6442450413|
was (Author: samabcde):
After some test, the problem is the huge number of IteratorChain#hasNext call,
but why the count growth so fast need to further investigate.
Below result can be verified with attached patch [^countHasNextCall.patch]
||number||hasNext_count||
|1|3|
|2|11|
|3|30|
|4|72|
|5|161|
|6|345|
|7|720|
|8|1478|
|9|3003|
|10|6063|
|11|12194|
|12|24468|
|13|49029|
|14|98165|
|15|196452|
|16|393042|
|17|786239|
|18|1572651|
|19|3145494|
|20|6291200|
|21|12582633|
|22|25165521|
|23|50331320|
|24|100662942|
|25|201326211|
|26|402652775|
|27|805305930|
|28|1610612268|
|29|3221224973|
|30|6442450413|
> ToString method is unresponsive after multiple SetUtils union calls
> ---
>
> Key: COLLECTIONS-770
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-770
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 4.4
>Reporter: Thomas Bürli
>Priority: Minor
> Attachments: SetUtilsTest.java, countHasNextCall.patch, stackdump.txt
>
>
> I had the following code and my application stopped responsing as soon the
> number of names for a userId got too big.
> {code:java}
>Map> stringMap = new TreeMap<>();
> for (String name : names) {
> for (String userId : userIds) {
> stringMap.merge(userId, Collections.singleton(name),
> SetUtils::union);
> }
> }
> {code}
> I did some debugging and it occurs when the toString method of one the set is
> called. It looks like the issues is with the iterator of "SetUtils.SetView".
> Here just the method I used to create test sets and in the attachment you
> find the full tests class and a stack dump. The execution time is growing
> exponentially with the numbers of times the SetUtils.union is called. So for
> 29 elements it took 16 seconds to execute toString, and with 30 it took 32
> seconds.
> {code:java}
> @Test
> void setWith20Elements() {
> assertTimeout(ofSeconds(2), () -> createSet(30).toString());
> }
> Set createSet(int number) {
> List inputs = new ArrayList<>();
> for (int i = 0; i < number; i++) {
>inputs.add("Test"+ i);
> }
> Set testSet = Collections.singleton("String1");
> for (String element : inputs) {
> Set part = Collections.singleton(element);
> testSet = SetUtils.union(testSet,part);
> }
> return testSet;
> }
> {code}
> Thanks for your support
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (COLLECTIONS-770) ToString method is unresponsive after multiple SetUtils union calls
[
https://issues.apache.org/jira/browse/COLLECTIONS-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528243#comment-17528243
]
Ng Tsz Sum edited comment on COLLECTIONS-770 at 4/26/22 3:29 PM:
-
After some test, the problem is the huge number of IteratorChain#hasNext call,
but why the count growth so fast need to further investigate.
Below result can be verified with attached patch [^countHasNextCall.patch]
||number||hasNext_count||
|1|3|
|2|11|
|3|30|
|4|72|
|5|161|
|6|345|
|7|720|
|8|1478|
|9|3003|
|10|6063|
|11|12194|
|12|24468|
|13|49029|
|14|98165|
|15|196452|
|16|393042|
|17|786239|
|18|1572651|
|19|3145494|
|20|6291200|
|21|12582633|
|22|25165521|
|23|50331320|
|24|100662942|
|25|201326211|
|26|402652775|
|27|805305930|
|28|1610612268|
|29|3221224973|
|30|6442450413|
was (Author: samabcde):
After some test, the problem is the huge number of IteratorChain#hasNext call,
but why the count growth so fast need to further investigate.
||number||hasNext_count||
|1|3|
|2|11|
|3|30|
|4|72|
|5|161|
|6|345|
|7|720|
|8|1478|
|9|3003|
|10|6063|
|11|12194|
|12|24468|
|13|49029|
|14|98165|
|15|196452|
|16|393042|
|17|786239|
|18|1572651|
|19|3145494|
|20|6291200|
|21|12582633|
|22|25165521|
|23|50331320|
|24|100662942|
|25|201326211|
|26|402652775|
|27|805305930|
|28|1610612268|
|29|3221224973|
|30|6442450413|
> ToString method is unresponsive after multiple SetUtils union calls
> ---
>
> Key: COLLECTIONS-770
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-770
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 4.4
>Reporter: Thomas Bürli
>Priority: Minor
> Attachments: SetUtilsTest.java, countHasNextCall.patch, stackdump.txt
>
>
> I had the following code and my application stopped responsing as soon the
> number of names for a userId got too big.
> {code:java}
>Map> stringMap = new TreeMap<>();
> for (String name : names) {
> for (String userId : userIds) {
> stringMap.merge(userId, Collections.singleton(name),
> SetUtils::union);
> }
> }
> {code}
> I did some debugging and it occurs when the toString method of one the set is
> called. It looks like the issues is with the iterator of "SetUtils.SetView".
> Here just the method I used to create test sets and in the attachment you
> find the full tests class and a stack dump. The execution time is growing
> exponentially with the numbers of times the SetUtils.union is called. So for
> 29 elements it took 16 seconds to execute toString, and with 30 it took 32
> seconds.
> {code:java}
> @Test
> void setWith20Elements() {
> assertTimeout(ofSeconds(2), () -> createSet(30).toString());
> }
> Set createSet(int number) {
> List inputs = new ArrayList<>();
> for (int i = 0; i < number; i++) {
>inputs.add("Test"+ i);
> }
> Set testSet = Collections.singleton("String1");
> for (String element : inputs) {
> Set part = Collections.singleton(element);
> testSet = SetUtils.union(testSet,part);
> }
> return testSet;
> }
> {code}
> Thanks for your support
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (COLLECTIONS-770) ToString method is unresponsive after multiple SetUtils union calls
[
https://issues.apache.org/jira/browse/COLLECTIONS-770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ng Tsz Sum updated COLLECTIONS-770:
---
Attachment: countHasNextCall.patch
> ToString method is unresponsive after multiple SetUtils union calls
> ---
>
> Key: COLLECTIONS-770
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-770
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 4.4
>Reporter: Thomas Bürli
>Priority: Minor
> Attachments: SetUtilsTest.java, countHasNextCall.patch, stackdump.txt
>
>
> I had the following code and my application stopped responsing as soon the
> number of names for a userId got too big.
> {code:java}
>Map> stringMap = new TreeMap<>();
> for (String name : names) {
> for (String userId : userIds) {
> stringMap.merge(userId, Collections.singleton(name),
> SetUtils::union);
> }
> }
> {code}
> I did some debugging and it occurs when the toString method of one the set is
> called. It looks like the issues is with the iterator of "SetUtils.SetView".
> Here just the method I used to create test sets and in the attachment you
> find the full tests class and a stack dump. The execution time is growing
> exponentially with the numbers of times the SetUtils.union is called. So for
> 29 elements it took 16 seconds to execute toString, and with 30 it took 32
> seconds.
> {code:java}
> @Test
> void setWith20Elements() {
> assertTimeout(ofSeconds(2), () -> createSet(30).toString());
> }
> Set createSet(int number) {
> List inputs = new ArrayList<>();
> for (int i = 0; i < number; i++) {
>inputs.add("Test"+ i);
> }
> Set testSet = Collections.singleton("String1");
> for (String element : inputs) {
> Set part = Collections.singleton(element);
> testSet = SetUtils.union(testSet,part);
> }
> return testSet;
> }
> {code}
> Thanks for your support
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (COLLECTIONS-770) ToString method is unresponsive after multiple SetUtils union calls
[
https://issues.apache.org/jira/browse/COLLECTIONS-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528243#comment-17528243
]
Ng Tsz Sum edited comment on COLLECTIONS-770 at 4/26/22 3:27 PM:
-
After some test, the problem is the huge number of IteratorChain#hasNext call,
but why the count growth so fast need to further investigate.
||number||hasNext_count||
|1|3|
|2|11|
|3|30|
|4|72|
|5|161|
|6|345|
|7|720|
|8|1478|
|9|3003|
|10|6063|
|11|12194|
|12|24468|
|13|49029|
|14|98165|
|15|196452|
|16|393042|
|17|786239|
|18|1572651|
|19|3145494|
|20|6291200|
|21|12582633|
|22|25165521|
|23|50331320|
|24|100662942|
|25|201326211|
|26|402652775|
|27|805305930|
|28|1610612268|
|29|3221224973|
|30|6442450413|
was (Author: samabcde):
After some test, the problem is the huge number of IteratorChain#hasNext call,
but why the count growth so fast need to further investigate.
[^countHasNextCall.patch]
||number||hasNext_count||
|1|3|
|2|11|
|3|30|
|4|72|
|5|161|
|6|345|
|7|720|
|8|1478|
|9|3003|
|10|6063|
|11|12194|
|12|24468|
|13|49029|
|14|98165|
|15|196452|
|16|393042|
|17|786239|
|18|1572651|
|19|3145494|
|20|6291200|
|21|12582633|
|22|25165521|
|23|50331320|
|24|100662942|
|25|201326211|
|26|402652775|
|27|805305930|
|28|1610612268|
|29|3221224973|
|30|6442450413|
> ToString method is unresponsive after multiple SetUtils union calls
> ---
>
> Key: COLLECTIONS-770
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-770
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 4.4
>Reporter: Thomas Bürli
>Priority: Minor
> Attachments: SetUtilsTest.java, countHasNextCall.patch, stackdump.txt
>
>
> I had the following code and my application stopped responsing as soon the
> number of names for a userId got too big.
> {code:java}
>Map> stringMap = new TreeMap<>();
> for (String name : names) {
> for (String userId : userIds) {
> stringMap.merge(userId, Collections.singleton(name),
> SetUtils::union);
> }
> }
> {code}
> I did some debugging and it occurs when the toString method of one the set is
> called. It looks like the issues is with the iterator of "SetUtils.SetView".
> Here just the method I used to create test sets and in the attachment you
> find the full tests class and a stack dump. The execution time is growing
> exponentially with the numbers of times the SetUtils.union is called. So for
> 29 elements it took 16 seconds to execute toString, and with 30 it took 32
> seconds.
> {code:java}
> @Test
> void setWith20Elements() {
> assertTimeout(ofSeconds(2), () -> createSet(30).toString());
> }
> Set createSet(int number) {
> List inputs = new ArrayList<>();
> for (int i = 0; i < number; i++) {
>inputs.add("Test"+ i);
> }
> Set testSet = Collections.singleton("String1");
> for (String element : inputs) {
> Set part = Collections.singleton(element);
> testSet = SetUtils.union(testSet,part);
> }
> return testSet;
> }
> {code}
> Thanks for your support
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (DAEMON-441) When installing a Windows service using Commons Daemon 1.3.0 the errorlevel is -1073741819
[
https://issues.apache.org/jira/browse/DAEMON-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528244#comment-17528244
]
Mark Thomas commented on DAEMON-441:
I found a handful of errors looking in to this. The root cause of the specific
issue was attempting to set permissions on a null path when there wasn't a
specific LogPath defined.
It would be helpful if you can confirm the fix before I do the release. Are you
able to build procrun from source or do you want me to provide you with some
binaries to test?
> When installing a Windows service using Commons Daemon 1.3.0 the errorlevel
> is -1073741819
> --
>
> Key: DAEMON-441
> URL: https://issues.apache.org/jira/browse/DAEMON-441
> Project: Commons Daemon
> Issue Type: Bug
>Affects Versions: 1.3.0
> Environment: Windows 2016 Datacenter
>Reporter: Brian Andle
>Priority: Major
> Attachments: Command_Prompt.png
>
>
> When attempting to use prunsrv.exe on Windows 2016 to create a service a
> Windows Event error is logged and the errorlevel is returned as -1073741819
> Running the following command:
> {code:java}
> prunsrv.exe //IS/MyService --Startup=auto --Description=My Service
> --DisplayName=My Service {code}
> Results in the following Windows Event Log entry
>
> {code:java}
> Faulting application name: prunsrv.exe, version: 1.3.0.0, time stamp:
> 0x622b3ac0
> Faulting module name: prunsrv.exe, version: 1.3.0.0, time stamp: 0x622b3ac0
> Exception code: 0xc005
> Fault offset: 0x6e70
> Faulting process id: 0x1d88
> Faulting application start time: 0x01d845f90eb4351a
> Faulting application path: C:\myfolder\prunsrv.exe
> Faulting module path: C:\myfolder\prunsrv.exe
> Report Id: 409b7098-42bd-4036-aa61-b19eecdb1bd7
> Faulting package full name:
> Faulting package-relative application ID: {code}
> Doing an echo %errorlevel% shows -1073741819 instead of the expected 0
> Version 1.2.4.0 works correctly on both Windows 10 and 2016
> *NOTE:* The service does appear to actually install on 2016, however most
> deploy scripts will expect an error level of 0 and will fail if a non 0 value
> it returned.
> h3. Workaround
> Define a *--LogPath* value and do not use the default
> %SystemRoot%\System32\LogFiles\Apache path
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (COLLECTIONS-770) ToString method is unresponsive after multiple SetUtils union calls
[
https://issues.apache.org/jira/browse/COLLECTIONS-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528243#comment-17528243
]
Ng Tsz Sum commented on COLLECTIONS-770:
After some test, the problem is the huge number of IteratorChain#hasNext call,
but why the count growth so fast need to further investigate.
[^countHasNextCall.patch]
||number||hasNext_count||
|1|3|
|2|11|
|3|30|
|4|72|
|5|161|
|6|345|
|7|720|
|8|1478|
|9|3003|
|10|6063|
|11|12194|
|12|24468|
|13|49029|
|14|98165|
|15|196452|
|16|393042|
|17|786239|
|18|1572651|
|19|3145494|
|20|6291200|
|21|12582633|
|22|25165521|
|23|50331320|
|24|100662942|
|25|201326211|
|26|402652775|
|27|805305930|
|28|1610612268|
|29|3221224973|
|30|6442450413|
> ToString method is unresponsive after multiple SetUtils union calls
> ---
>
> Key: COLLECTIONS-770
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-770
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 4.4
>Reporter: Thomas Bürli
>Priority: Minor
> Attachments: SetUtilsTest.java, stackdump.txt
>
>
> I had the following code and my application stopped responsing as soon the
> number of names for a userId got too big.
> {code:java}
>Map> stringMap = new TreeMap<>();
> for (String name : names) {
> for (String userId : userIds) {
> stringMap.merge(userId, Collections.singleton(name),
> SetUtils::union);
> }
> }
> {code}
> I did some debugging and it occurs when the toString method of one the set is
> called. It looks like the issues is with the iterator of "SetUtils.SetView".
> Here just the method I used to create test sets and in the attachment you
> find the full tests class and a stack dump. The execution time is growing
> exponentially with the numbers of times the SetUtils.union is called. So for
> 29 elements it took 16 seconds to execute toString, and with 30 it took 32
> seconds.
> {code:java}
> @Test
> void setWith20Elements() {
> assertTimeout(ofSeconds(2), () -> createSet(30).toString());
> }
> Set createSet(int number) {
> List inputs = new ArrayList<>();
> for (int i = 0; i < number; i++) {
>inputs.add("Test"+ i);
> }
> Set testSet = Collections.singleton("String1");
> for (String element : inputs) {
> Set part = Collections.singleton(element);
> testSet = SetUtils.union(testSet,part);
> }
> return testSet;
> }
> {code}
> Thanks for your support
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (COMPRESS-619) Large SevenZFile fails When Next Header Size is Greater than Max Int
[
https://issues.apache.org/jira/browse/COMPRESS-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528149#comment-17528149
]
Brian Miller edited comment on COMPRESS-619 at 4/26/22 12:50 PM:
-
It seems like doing something that the PR for COMPRESS-514 is doing would allow
the header to be read.
was (Author: JIRAUSER288490):
It seems like doing something that COMPRESS-514 is doing would allow the header
to be read.
> Large SevenZFile fails When Next Header Size is Greater than Max Int
>
>
> Key: COMPRESS-619
> URL: https://issues.apache.org/jira/browse/COMPRESS-619
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.21
>Reporter: Brian Miller
>Priority: Minor
>
> When reading a large file (42GB) the following stack trace is produced:
>
> {code:java}
> java.io.IOException: Cannot handle nextHeaderSize 4102590414
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.assertFitsIntoNonNegativeInt(SevenZFile.java:2076)
> ~[classes/:?]
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.initializeArchive(SevenZFile.java:528)
> ~[classes/:?]
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.readHeaders(SevenZFile.java:474)
> ~[classes/:?]
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.(SevenZFile.java:343)
> ~[classes/:?]
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.(SevenZFile.java:136)
> ~[classes/:?]
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.(SevenZFile.java:376)
> ~[classes/:?]
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.(SevenZFile.java:364)
> ~[classes/:?] {code}
>
> The file was produced using the SevenZOutputFile class and contains a large
> number of very small files all inserted using copy compression. It passes the
> 7z tests and has the following statistics:
>
> {code:java}
> Files: 40872560
> Size: 43708874326
> Compressed: 47811464772
> {code}
> It is failing because a ByteBuffer can't be created that is large enough with
> something over max integer in size to do the CRC check.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (COMPRESS-619) Large SevenZFile fails When Next Header Size is Greater than Max Int
[
https://issues.apache.org/jira/browse/COMPRESS-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528149#comment-17528149
]
Brian Miller commented on COMPRESS-619:
---
It seems like doing something that COMPRESS-514 is doing would allow the header
to be read.
> Large SevenZFile fails When Next Header Size is Greater than Max Int
>
>
> Key: COMPRESS-619
> URL: https://issues.apache.org/jira/browse/COMPRESS-619
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.21
>Reporter: Brian Miller
>Priority: Minor
>
> When reading a large file (42GB) the following stack trace is produced:
>
> {code:java}
> java.io.IOException: Cannot handle nextHeaderSize 4102590414
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.assertFitsIntoNonNegativeInt(SevenZFile.java:2076)
> ~[classes/:?]
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.initializeArchive(SevenZFile.java:528)
> ~[classes/:?]
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.readHeaders(SevenZFile.java:474)
> ~[classes/:?]
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.(SevenZFile.java:343)
> ~[classes/:?]
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.(SevenZFile.java:136)
> ~[classes/:?]
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.(SevenZFile.java:376)
> ~[classes/:?]
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.(SevenZFile.java:364)
> ~[classes/:?] {code}
>
> The file was produced using the SevenZOutputFile class and contains a large
> number of very small files all inserted using copy compression. It passes the
> 7z tests and has the following statistics:
>
> {code:java}
> Files: 40872560
> Size: 43708874326
> Compressed: 47811464772
> {code}
> It is failing because a ByteBuffer can't be created that is large enough with
> something over max integer in size to do the CRC check.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Work logged] (COLLECTIONS-811) Consider integration Guava testlib tests
[ https://issues.apache.org/jira/browse/COLLECTIONS-811?focusedWorklogId=76=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-76 ] ASF GitHub Bot logged work on COLLECTIONS-811: -- Author: ASF GitHub Bot Created on: 26/Apr/22 10:40 Start Date: 26/Apr/22 10:40 Worklog Time Spent: 10m Work Description: kinow opened a new pull request, #301: URL: https://github.com/apache/commons-collections/pull/301 Adding the test class from @ben-manes, pending merge of #300 Issue Time Tracking --- Worklog Id: (was: 76) Remaining Estimate: 0h Time Spent: 10m > Consider integration Guava testlib tests > > > Key: COLLECTIONS-811 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-811 > Project: Commons Collections > Issue Type: Test >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > In COLLECTIONS-802 an issue reported was found with the help of Google Guava > testlib tests. > Maybe we could either have something similar (i.e. build ourselves?), use > Google Guava's testlib, or find another similar solution. From what I > understood, it uses a factory function to create an implementation of a > collection interface (e.g. Map) and then runs a series of functional tests > over the created object, failing tests if a contract is broken (e.g. > iterating a map doesn't leave the next-object as null, as it was the case of > the 802 issue). -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [commons-collections] kinow opened a new pull request, #301: [COLLECTIONS-811] Integrate Guava Testlib tests for Apache Commons Collections
kinow opened a new pull request, #301: URL: https://github.com/apache/commons-collections/pull/301 Adding the test class from @ben-manes, pending merge of #300 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (COLLECTIONS-811) Consider integration Guava testlib tests
[ https://issues.apache.org/jira/browse/COLLECTIONS-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated COLLECTIONS-811: --- Assignee: Bruno P. Kinoshita > Consider integration Guava testlib tests > > > Key: COLLECTIONS-811 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-811 > Project: Commons Collections > Issue Type: Test >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > > In COLLECTIONS-802 an issue reported was found with the help of Google Guava > testlib tests. > Maybe we could either have something similar (i.e. build ourselves?), use > Google Guava's testlib, or find another similar solution. From what I > understood, it uses a factory function to create an implementation of a > collection interface (e.g. Map) and then runs a series of functional tests > over the created object, failing tests if a contract is broken (e.g. > iterating a map doesn't leave the next-object as null, as it was the case of > the 802 issue). -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IO-279) Tailer erroneously considers file as new
[
https://issues.apache.org/jira/browse/IO-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17527959#comment-17527959
]
Apoorva Maheshwari commented on IO-279:
---
Issue is still present in version 2.7. As it is in reopen state, Kindly confirm
if it is being planned to fix in upcoming release.
> Tailer erroneously considers file as new
>
>
> Key: IO-279
> URL: https://issues.apache.org/jira/browse/IO-279
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.0.1, 2.4
>Reporter: Sergio Bossa
>Priority: Major
> Attachments: IO-279.patch, disable_resetting.patch, fix-tailer.patch,
> modify-test-fixed.patch, modify-test.patch
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Tailer sometimes erroneously considers the tailed file as new, forcing a
> repositioning at the start of the file: I'm still unable to reproduce this in
> a test case, because it only happens to me with huge log files during Apache
> Tomcat startup.
> This is the piece of code causing the problem:
> {code}
> // See if the file needs to be read again
> if (length > position) {
> // The file has more content than it did last time
> last = System.currentTimeMillis();
> position = readLines(reader);
> } else if (FileUtils.isFileNewer(file, last)) {
> /* This can happen if the file is truncated or overwritten
> * with the exact same length of information. In cases like
> * this, the file position needs to be reset
> */
> position = 0;
> reader.seek(position); // cannot be null here
> // Now we can read new lines
> last = System.currentTimeMillis();
> position = readLines(reader);
> }
> {code}
> What probably happens is that the new file content is about to be written on
> disk, the date is already updated but content is still not flushed, so actual
> length is untouched and there you go.
> In other words, I think there should be some better method to verify the
> condition above, rather than relying only on dates: keeping and comparing the
> hash code of the latest line may be a solution, but may hurt performances ...
> other ideas?
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (IO-278) Improve Tailer performance with buffered reads
[ https://issues.apache.org/jira/browse/IO-278 ] Apoorva Maheshwari deleted comment on IO-278: --- was (Author: JIRAUSER288635): Issue is still present in version 2.7. As it is in reopen state, Kindly confirm if it is being planned to fix in upcoming release. > Improve Tailer performance with buffered reads > -- > > Key: IO-278 > URL: https://issues.apache.org/jira/browse/IO-278 > Project: Commons IO > Issue Type: Improvement >Affects Versions: 2.0.1 >Reporter: Sergio Bossa >Priority: Major > Fix For: 2.4 > > Attachments: Tailer.diff, TailerTest.diff > > > I noticed Tailer read performances are pretty poor when dealing with large, > frequently written, log files, and this is due to the use of RandomAccessFile > which does unbuffered reads, hence causing lots of disk I/O. > So I improved the Tailer implementation by introducing buffered reads: it > works by loading large (configurable) file chunks in memory, and reading > lines from there; this enhances performances in my tests from 10x to 30x > depending on the file size. > I also added two test cases: one to simulate reading of a large file (you can > use it to compare performances), the other to verify correct handling on > buffer breaks; obviously, all tests pass. > I'm attaching the diff files, let me know if it's okay for you guys! -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IO-278) Improve Tailer performance with buffered reads
[ https://issues.apache.org/jira/browse/IO-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17527956#comment-17527956 ] Apoorva Maheshwari commented on IO-278: --- Issue is still present in version 2.7. As it is in reopen state, Kindly confirm if it is being planned to fix in upcoming release. > Improve Tailer performance with buffered reads > -- > > Key: IO-278 > URL: https://issues.apache.org/jira/browse/IO-278 > Project: Commons IO > Issue Type: Improvement >Affects Versions: 2.0.1 >Reporter: Sergio Bossa >Priority: Major > Fix For: 2.4 > > Attachments: Tailer.diff, TailerTest.diff > > > I noticed Tailer read performances are pretty poor when dealing with large, > frequently written, log files, and this is due to the use of RandomAccessFile > which does unbuffered reads, hence causing lots of disk I/O. > So I improved the Tailer implementation by introducing buffered reads: it > works by loading large (configurable) file chunks in memory, and reading > lines from there; this enhances performances in my tests from 10x to 30x > depending on the file size. > I also added two test cases: one to simulate reading of a large file (you can > use it to compare performances), the other to verify correct handling on > buffer breaks; obviously, all tests pass. > I'm attaching the diff files, let me know if it's okay for you guys! -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [commons-jexl] hussachai opened a new pull request, #92: JEXL-366 fix string and numerable comparison
hussachai opened a new pull request, #92: URL: https://github.com/apache/commons-jexl/pull/92 This PR is for fixing the corner case of the values comparison when one operand is a string and another operand is a numerable. I put more details on the JIRA JEXL-366 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
