[jira] [Resolved] (SANSELAN-72) Incorrect reading TIFF file
[
https://issues.apache.org/jira/browse/SANSELAN-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damjan Jovanovic resolved SANSELAN-72.
--
Resolution: Fixed
Fix Version/s: 1.0
The problem with the grey background was that Sanselan was using the worst
possible algorithm described in Section 9.1 of the PNG spec. I've changed it to
use the best one as of commit 1325915.
Both issues are now gone -> resolving fixed.
> Incorrect reading TIFF file
> ---
>
> Key: SANSELAN-72
> URL: https://issues.apache.org/jira/browse/SANSELAN-72
> Project: Commons Sanselan
> Issue Type: Bug
> Components: Format: PNG, Format: TIFF
>Affects Versions: 1.x
>Reporter: VVD
> Fix For: 1.0
>
> Attachments: in.png, in.tif, out-png-IM.png, out-tif.png
>
>
> I found 2 bugs.
> I have tif file in.tif.
> 1. After convert it to png (bmp, tga, etc) by Sanselan it getting horizontal
> lines.
> {code}
> Sanselan.writeImage(Sanselan.getBufferedImage(new File("in.tif")), new
> File("out-tif.png"), ImageFormat.IMAGE_FORMAT_PNG, null);
> {code}
> gwenview, eog, kolourpaint, gimp, etc show in.tif without lines and out.png
> with lines.
> For example 1st line at ~860 points from top and in full width of picture.
> 2. After convert it to png by convert utility from ImageMagic, and then
> convert it to png (bmp, tga, etc) by Sanselan it became "gray" - all white
> pixels become gray.
> {code}$ convert in.tif in.png{code}
> {code}
> Sanselan.writeImage(Sanselan.getBufferedImage(new File("in.png")), new
> File("out-png-IM.png"), ImageFormat.IMAGE_FORMAT_PNG, null);
> {code}
> gwenview, eog, kolourpaint, gimp, etc show in.png as black and white, but
> out-png-IM.png as black and gray.
> I'll attach all 4 files.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-627) superfluously null check of SparseIterator.next()
[
https://issues.apache.org/jira/browse/MATH-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253536#comment-13253536
]
Arne Plöse commented on MATH-627:
-
Sorry for beeing sloppy...
If you look at ArrayRealVector you will find this construct:
{code}
while (it.hasNext() && (e = it.next()) != null) {...}
{code}
the same can also be found in RealVector
> superfluously null check of SparseIterator.next()
> -
>
> Key: MATH-627
> URL: https://issues.apache.org/jira/browse/MATH-627
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Arne Plöse
>Priority: Minor
> Fix For: 3.1
>
>
> Looking at the implementation of SparseIterator in
> OpenMapRealVector.OpenMapSparseIterator there is no chance that the entry
> return by next() is ever null - so there is no need to chek this in nearly
> every loop?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANSELAN-72) Incorrect reading TIFF file
[
https://issues.apache.org/jira/browse/SANSELAN-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253524#comment-13253524
]
Damjan Jovanovic commented on SANSELAN-72:
--
It wasn't LZW compression, but calculation of the expected size for
decompressed data.
Fixed by commit 1325834 in the latest SVN.
The grey background is still a problem.
> Incorrect reading TIFF file
> ---
>
> Key: SANSELAN-72
> URL: https://issues.apache.org/jira/browse/SANSELAN-72
> Project: Commons Sanselan
> Issue Type: Bug
> Components: Format: PNG, Format: TIFF
>Affects Versions: 1.x
>Reporter: VVD
> Attachments: in.png, in.tif, out-png-IM.png, out-tif.png
>
>
> I found 2 bugs.
> I have tif file in.tif.
> 1. After convert it to png (bmp, tga, etc) by Sanselan it getting horizontal
> lines.
> {code}
> Sanselan.writeImage(Sanselan.getBufferedImage(new File("in.tif")), new
> File("out-tif.png"), ImageFormat.IMAGE_FORMAT_PNG, null);
> {code}
> gwenview, eog, kolourpaint, gimp, etc show in.tif without lines and out.png
> with lines.
> For example 1st line at ~860 points from top and in full width of picture.
> 2. After convert it to png by convert utility from ImageMagic, and then
> convert it to png (bmp, tga, etc) by Sanselan it became "gray" - all white
> pixels become gray.
> {code}$ convert in.tif in.png{code}
> {code}
> Sanselan.writeImage(Sanselan.getBufferedImage(new File("in.png")), new
> File("out-png-IM.png"), ImageFormat.IMAGE_FORMAT_PNG, null);
> {code}
> gwenview, eog, kolourpaint, gimp, etc show in.png as black and white, but
> out-png-IM.png as black and gray.
> I'll attach all 4 files.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-740) Some "FastMath" functions are slow
[ https://issues.apache.org/jira/browse/MATH-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253452#comment-13253452 ] Ismael Juma commented on MATH-740: -- That is true for HotSpot indeed. For other JVMs that use the OpenJDK standard library, they may or may not have similar mechanisms. > Some "FastMath" functions are slow > -- > > Key: MATH-740 > URL: https://issues.apache.org/jira/browse/MATH-740 > Project: Commons Math > Issue Type: Wish >Reporter: Gilles >Priority: Minor > Fix For: 3.1 > > > From the two benchmarks we currently have in "FastMathTestPerfomance", we > have that the following functions are much slower in "FastMath" than in > either "Math" or "StrictMath" (the performance *loss*, for each of the > benchmarks, is given in parentheses): > * log10 (46%, 36%) > * log1p (68%, 112%) > * tan (11%, 61%) > * atan (26%, 125%) > * atan2 (44%, 40%) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-740) Some "FastMath" functions are slow
[ https://issues.apache.org/jira/browse/MATH-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253448#comment-13253448 ] Thomas Neidhart commented on MATH-740: -- ah ok thanks. So the call in Math.log10 is just there to make the javac happy while the jvm will call the intrinsic methods instead. > Some "FastMath" functions are slow > -- > > Key: MATH-740 > URL: https://issues.apache.org/jira/browse/MATH-740 > Project: Commons Math > Issue Type: Wish >Reporter: Gilles >Priority: Minor > Fix For: 3.1 > > > From the two benchmarks we currently have in "FastMathTestPerfomance", we > have that the following functions are much slower in "FastMath" than in > either "Math" or "StrictMath" (the performance *loss*, for each of the > benchmarks, is given in parentheses): > * log10 (46%, 36%) > * log1p (68%, 112%) > * tan (11%, 61%) > * atan (26%, 125%) > * atan2 (44%, 40%) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-740) Some "FastMath" functions are slow
[ https://issues.apache.org/jira/browse/MATH-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253421#comment-13253421 ] Ismael Juma commented on MATH-740: -- Thomas, you cannot trust what you see in java.lang.Math. Many of those methods are HotSpot intrinsics and consist of optimised assembly code. Examples are sin, cos, tan, exp, log, sqrt, atan2 and so on. > Some "FastMath" functions are slow > -- > > Key: MATH-740 > URL: https://issues.apache.org/jira/browse/MATH-740 > Project: Commons Math > Issue Type: Wish >Reporter: Gilles >Priority: Minor > Fix For: 3.1 > > > From the two benchmarks we currently have in "FastMathTestPerfomance", we > have that the following functions are much slower in "FastMath" than in > either "Math" or "StrictMath" (the performance *loss*, for each of the > benchmarks, is given in parentheses): > * log10 (46%, 36%) > * log1p (68%, 112%) > * tan (11%, 61%) > * atan (26%, 125%) > * atan2 (44%, 40%) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-740) Some "FastMath" functions are slow
[
https://issues.apache.org/jira/browse/MATH-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253415#comment-13253415
]
Thomas Neidhart commented on MATH-740:
--
I am a bit puzzled, does anybody have an idea why Math is faster than
StrictMath, although internally, Math.log10 just calls StrictMath.log10?
{noformat}
Name StrictMath FastMath Math Runs=1000 Java 1.6.0_20
(1.6.0_20-b02) Java HotSpot(TM) Server VM (16.3-b01)
log10 981.0161 1.6377 23 0.2427
{noformat}
>From Math.java:
{noformat}
public static double log10(double a) {
return StrictMath.log10(a); // default impl. delegates to StrictMath
}
{noformat}
> Some "FastMath" functions are slow
> --
>
> Key: MATH-740
> URL: https://issues.apache.org/jira/browse/MATH-740
> Project: Commons Math
> Issue Type: Wish
>Reporter: Gilles
>Priority: Minor
> Fix For: 3.1
>
>
> From the two benchmarks we currently have in "FastMathTestPerfomance", we
> have that the following functions are much slower in "FastMath" than in
> either "Math" or "StrictMath" (the performance *loss*, for each of the
> benchmarks, is given in parentheses):
> * log10 (46%, 36%)
> * log1p (68%, 112%)
> * tan (11%, 61%)
> * atan (26%, 125%)
> * atan2 (44%, 40%)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-627) superfluously null check of SparseIterator.next()
[ https://issues.apache.org/jira/browse/MATH-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253398#comment-13253398 ] Thomas Neidhart commented on MATH-627: -- I failed to find any null check in the mentioned iterator, neither in the current trunk version nor in the version at the time the issue was created. Can you please specify more precisely where the problem lies? > superfluously null check of SparseIterator.next() > - > > Key: MATH-627 > URL: https://issues.apache.org/jira/browse/MATH-627 > Project: Commons Math > Issue Type: Improvement >Reporter: Arne Plöse >Priority: Minor > Fix For: 3.1 > > > Looking at the implementation of SparseIterator in > OpenMapRealVector.OpenMapSparseIterator there is no chance that the entry > return by next() is ever null - so there is no need to chek this in nearly > every loop? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-718) inverseCumulativeProbability of BinomialDistribution returns wrong value for large trials.
[
https://issues.apache.org/jira/browse/MATH-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253381#comment-13253381
]
Thomas Neidhart commented on MATH-718:
--
The problem is not only related to the Beta function, also the
ContinuedFraction.evaluate is numerically unstable.
The reason the cumulativeProbability returns infinity instead of NaN is because
the evaluate return 0.0 when called from Beta.regularizedBeta, which leads to a
division by zero. The used default epsilon of 10e-15 seems also quite
restrictive, when relaxing the epsilon I got much better results (e.g. with
10e-5 I got a result of 47).
> inverseCumulativeProbability of BinomialDistribution returns wrong value for
> large trials.
> --
>
> Key: MATH-718
> URL: https://issues.apache.org/jira/browse/MATH-718
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 2.2, 3.0
>Reporter: Yuji Uchiyama
>Assignee: Sébastien Brisard
> Fix For: 3.1, 4.0
>
>
> The inverseCumulativeProbability method of the BinomialDistributionImpl class
> returns wrong value for large trials. Following code will be reproduce the
> problem.
> {{System.out.println(new BinomialDistributionImpl(100,
> 0.5).inverseCumulativeProbability(0.5));}}
> This returns 499525, though it should be 49.
> I'm not sure how it should be fixed, but the cause is that the
> cumulativeProbability method returns Infinity, not NaN. As the result the
> checkedCumulativeProbability method doesn't work as expected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MATH-718) inverseCumulativeProbability of BinomialDistribution returns wrong value for large trials.
[
https://issues.apache.org/jira/browse/MATH-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253360#comment-13253360
]
Thomas Neidhart edited comment on MATH-718 at 4/13/12 1:25 PM:
---
The problem Christian described wrt the PascalDistribution is a simple integer
overflow in the class itself:
{noformat}
public double cumulativeProbability(int x) {
double ret;
if (x < 0) {
ret = 0.0;
} else {
ret = Beta.regularizedBeta(probabilityOfSuccess,
numberOfSuccesses, x + 1);
}
return ret;
}
{noformat}
when x = Integer.MAX_VALUE, adding 1 to it will result in an overflow. As the
parameter of regularizedBeta is anyway a double, so it should be changed to
something like "1L + x" to enforce a long addition.
Edit: Similar things happen btw also in other Distribution implementations, so
it should be fixed also there, e.g. BinomialDistribution
was (Author: tn):
The problem Christian described wrt the PascalDistribution is a simple
integer overflow in the class itself:
{noformat}
public double cumulativeProbability(int x) {
double ret;
if (x < 0) {
ret = 0.0;
} else {
ret = Beta.regularizedBeta(probabilityOfSuccess,
numberOfSuccesses, x + 1);
}
return ret;
}
{noformat}
when x = Integer.MAX_VALUE, adding 1 to it will result in an overflow. As the
parameter of regularizedBeta is anyway a double, it should be cast to
long/double before the addition.
Edit: Similar things happen btw also in other Distribution implementations, so
it should be fixed also there, e.g. BinomialDistribution
> inverseCumulativeProbability of BinomialDistribution returns wrong value for
> large trials.
> --
>
> Key: MATH-718
> URL: https://issues.apache.org/jira/browse/MATH-718
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 2.2, 3.0
>Reporter: Yuji Uchiyama
>Assignee: Sébastien Brisard
> Fix For: 3.1, 4.0
>
>
> The inverseCumulativeProbability method of the BinomialDistributionImpl class
> returns wrong value for large trials. Following code will be reproduce the
> problem.
> {{System.out.println(new BinomialDistributionImpl(100,
> 0.5).inverseCumulativeProbability(0.5));}}
> This returns 499525, though it should be 49.
> I'm not sure how it should be fixed, but the cause is that the
> cumulativeProbability method returns Infinity, not NaN. As the result the
> checkedCumulativeProbability method doesn't work as expected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MATH-718) inverseCumulativeProbability of BinomialDistribution returns wrong value for large trials.
[
https://issues.apache.org/jira/browse/MATH-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253360#comment-13253360
]
Thomas Neidhart edited comment on MATH-718 at 4/13/12 1:22 PM:
---
The problem Christian described wrt the PascalDistribution is a simple integer
overflow in the class itself:
{noformat}
public double cumulativeProbability(int x) {
double ret;
if (x < 0) {
ret = 0.0;
} else {
ret = Beta.regularizedBeta(probabilityOfSuccess,
numberOfSuccesses, x + 1);
}
return ret;
}
{noformat}
when x = Integer.MAX_VALUE, adding 1 to it will result in an overflow. As the
parameter of regularizedBeta is anyway a double, it should be cast to
long/double before the addition.
Edit: Similar things happen btw also in other Distribution implementations, so
it should be fixed also there, e.g. BinomialDistribution
was (Author: tn):
The problem Christian described wrt the PascalDistribution is a simple
integer overflow in the class itself:
{noformat}
public double cumulativeProbability(int x) {
double ret;
if (x < 0) {
ret = 0.0;
} else {
ret = Beta.regularizedBeta(probabilityOfSuccess,
numberOfSuccesses, x + 1);
}
return ret;
}
{noformat}
when x = Integer.MAX_VALUE, adding 1 to it will result in an overflow. As the
parameter of regularizedBeta is anyway a double, it should be cast to
long/double before the addition.
> inverseCumulativeProbability of BinomialDistribution returns wrong value for
> large trials.
> --
>
> Key: MATH-718
> URL: https://issues.apache.org/jira/browse/MATH-718
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 2.2, 3.0
>Reporter: Yuji Uchiyama
>Assignee: Sébastien Brisard
> Fix For: 3.1, 4.0
>
>
> The inverseCumulativeProbability method of the BinomialDistributionImpl class
> returns wrong value for large trials. Following code will be reproduce the
> problem.
> {{System.out.println(new BinomialDistributionImpl(100,
> 0.5).inverseCumulativeProbability(0.5));}}
> This returns 499525, though it should be 49.
> I'm not sure how it should be fixed, but the cause is that the
> cumulativeProbability method returns Infinity, not NaN. As the result the
> checkedCumulativeProbability method doesn't work as expected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-718) inverseCumulativeProbability of BinomialDistribution returns wrong value for large trials.
[
https://issues.apache.org/jira/browse/MATH-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253360#comment-13253360
]
Thomas Neidhart commented on MATH-718:
--
The problem Christian described wrt the PascalDistribution is a simple integer
overflow in the class itself:
{noformat}
public double cumulativeProbability(int x) {
double ret;
if (x < 0) {
ret = 0.0;
} else {
ret = Beta.regularizedBeta(probabilityOfSuccess,
numberOfSuccesses, x + 1);
}
return ret;
}
{noformat}
when x = Integer.MAX_VALUE, adding 1 to it will result in an overflow. As the
parameter of regularizedBeta is anyway a double, it should be cast to
long/double before the addition.
> inverseCumulativeProbability of BinomialDistribution returns wrong value for
> large trials.
> --
>
> Key: MATH-718
> URL: https://issues.apache.org/jira/browse/MATH-718
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 2.2, 3.0
>Reporter: Yuji Uchiyama
>Assignee: Sébastien Brisard
> Fix For: 3.1, 4.0
>
>
> The inverseCumulativeProbability method of the BinomialDistributionImpl class
> returns wrong value for large trials. Following code will be reproduce the
> problem.
> {{System.out.println(new BinomialDistributionImpl(100,
> 0.5).inverseCumulativeProbability(0.5));}}
> This returns 499525, though it should be 49.
> I'm not sure how it should be fixed, but the cause is that the
> cumulativeProbability method returns Infinity, not NaN. As the result the
> checkedCumulativeProbability method doesn't work as expected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-458) MVSFTPEntryParser.parseSimpleEntry - ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/NET-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253294#comment-13253294
]
Denis Molony commented on NET-458:
--
Thanks, that fixed it.
> MVSFTPEntryParser.parseSimpleEntry - ArrayIndexOutOfBoundsException
> ---
>
> Key: NET-458
> URL: https://issues.apache.org/jira/browse/NET-458
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.0.1, 3.1
> Environment: zOS
>Reporter: Denis Molony
>
> Line 360 in MVSFTPEntryParser.parseSimpleEntry :
> String name = entry.split(" ")[0];
> gives an ArrayIndexOutOfBoundsException: 0
> It appears to be caused by a partitioned dataset whose members only contain
> names. No other details (creation date, file type etc).
> This is the method, if it helps:
> {code}
> private boolean parseSimpleEntry(FTPFile file, String entry) {
> if (entry != null && entry.length() > 0) {
> file.setRawListing(entry);
> String name = entry.split(" ")[0]; // <--- error occurs here
> file.setName(name);
> file.setType(FTPFile.FILE_TYPE);
> return true;
> }
> return false;
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (NET-458) MVSFTPEntryParser.parseSimpleEntry - ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/NET-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved NET-458.
--
Resolution: Fixed
Thanks for the report. Fixed in SVN, and a new SNAPSHOT has been uploaded to
the ASF snapshots repo [1].
[1] http://repository.apache.org/snapshots/
> MVSFTPEntryParser.parseSimpleEntry - ArrayIndexOutOfBoundsException
> ---
>
> Key: NET-458
> URL: https://issues.apache.org/jira/browse/NET-458
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.0.1, 3.1
> Environment: zOS
>Reporter: Denis Molony
>
> Line 360 in MVSFTPEntryParser.parseSimpleEntry :
> String name = entry.split(" ")[0];
> gives an ArrayIndexOutOfBoundsException: 0
> It appears to be caused by a partitioned dataset whose members only contain
> names. No other details (creation date, file type etc).
> This is the method, if it helps:
> {code}
> private boolean parseSimpleEntry(FTPFile file, String entry) {
> if (entry != null && entry.length() > 0) {
> file.setRawListing(entry);
> String name = entry.split(" ")[0]; // <--- error occurs here
> file.setName(name);
> file.setType(FTPFile.FILE_TYPE);
> return true;
> }
> return false;
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-458) MVSFTPEntryParser.parseSimpleEntry - ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/NET-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253285#comment-13253285
]
Denis Molony commented on NET-458:
--
The PDS contains many members, but all of them appear to have unreadable names
(unprintable characters?). There is no other member information available, so
that part of the string is definitely blank.
> MVSFTPEntryParser.parseSimpleEntry - ArrayIndexOutOfBoundsException
> ---
>
> Key: NET-458
> URL: https://issues.apache.org/jira/browse/NET-458
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.0.1, 3.1
> Environment: zOS
>Reporter: Denis Molony
>
> Line 360 in MVSFTPEntryParser.parseSimpleEntry :
> String name = entry.split(" ")[0];
> gives an ArrayIndexOutOfBoundsException: 0
> It appears to be caused by a partitioned dataset whose members only contain
> names. No other details (creation date, file type etc).
> This is the method, if it helps:
> {code}
> private boolean parseSimpleEntry(FTPFile file, String entry) {
> if (entry != null && entry.length() > 0) {
> file.setRawListing(entry);
> String name = entry.split(" ")[0]; // <--- error occurs here
> file.setName(name);
> file.setType(FTPFile.FILE_TYPE);
> return true;
> }
> return false;
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-458) MVSFTPEntryParser.parseSimpleEntry - ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/NET-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253283#comment-13253283
]
Sebb commented on NET-458:
--
Looks like the problem is caused by trying to split a string containing only
space(s)
> MVSFTPEntryParser.parseSimpleEntry - ArrayIndexOutOfBoundsException
> ---
>
> Key: NET-458
> URL: https://issues.apache.org/jira/browse/NET-458
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.0.1, 3.1
> Environment: zOS
>Reporter: Denis Molony
>
> Line 360 in MVSFTPEntryParser.parseSimpleEntry :
> String name = entry.split(" ")[0];
> gives an ArrayIndexOutOfBoundsException: 0
> It appears to be caused by a partitioned dataset whose members only contain
> names. No other details (creation date, file type etc).
> This is the method, if it helps:
> {code}
> private boolean parseSimpleEntry(FTPFile file, String entry) {
> if (entry != null && entry.length() > 0) {
> file.setRawListing(entry);
> String name = entry.split(" ")[0]; // <--- error occurs here
> file.setName(name);
> file.setType(FTPFile.FILE_TYPE);
> return true;
> }
> return false;
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-458) MVSFTPEntryParser.parseSimpleEntry - ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/NET-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated NET-458:
-
Description:
Line 360 in MVSFTPEntryParser.parseSimpleEntry :
String name = entry.split(" ")[0];
gives an ArrayIndexOutOfBoundsException: 0
It appears to be caused by a partitioned dataset whose members only contain
names. No other details (creation date, file type etc).
This is the method, if it helps:
{code}
private boolean parseSimpleEntry(FTPFile file, String entry) {
if (entry != null && entry.length() > 0) {
file.setRawListing(entry);
String name = entry.split(" ")[0]; // <--- error occurs here
file.setName(name);
file.setType(FTPFile.FILE_TYPE);
return true;
}
return false;
}
{code}
was:
Line 360 in MVSFTPEntryParser.parseSimpleEntry :
String name = entry.split(" ")[0];
gives an ArrayIndexOutOfBoundsException: 0
It appears to be caused by a partitioned dataset whose members only contain
names. No other details (creation date, file type etc).
This is the method, if it helps:
private boolean parseSimpleEntry(FTPFile file, String entry) {
if (entry != null && entry.length() > 0) {
file.setRawListing(entry);
String name = entry.split(" ")[0]; // <--- error occurs
here
file.setName(name);
file.setType(FTPFile.FILE_TYPE);
return true;
}
return false;
}
Fix layout
> MVSFTPEntryParser.parseSimpleEntry - ArrayIndexOutOfBoundsException
> ---
>
> Key: NET-458
> URL: https://issues.apache.org/jira/browse/NET-458
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.0.1, 3.1
> Environment: zOS
>Reporter: Denis Molony
>
> Line 360 in MVSFTPEntryParser.parseSimpleEntry :
> String name = entry.split(" ")[0];
> gives an ArrayIndexOutOfBoundsException: 0
> It appears to be caused by a partitioned dataset whose members only contain
> names. No other details (creation date, file type etc).
> This is the method, if it helps:
> {code}
> private boolean parseSimpleEntry(FTPFile file, String entry) {
> if (entry != null && entry.length() > 0) {
> file.setRawListing(entry);
> String name = entry.split(" ")[0]; // <--- error occurs here
> file.setName(name);
> file.setType(FTPFile.FILE_TYPE);
> return true;
> }
> return false;
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-458) MVSFTPEntryParser.parseSimpleEntry - ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/NET-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Molony updated NET-458:
-
Description:
Line 360 in MVSFTPEntryParser.parseSimpleEntry :
String name = entry.split(" ")[0];
gives an ArrayIndexOutOfBoundsException: 0
It appears to be caused by a partitioned dataset whose members only contain
names. No other details (creation date, file type etc).
This is the method, if it helps:
private boolean parseSimpleEntry(FTPFile file, String entry) {
if (entry != null && entry.length() > 0) {
file.setRawListing(entry);
String name = entry.split(" ")[0]; // <--- error occurs
here
file.setName(name);
file.setType(FTPFile.FILE_TYPE);
return true;
}
return false;
}
was:
Line 360 in MVSFTPEntryParser.parseSimpleEntry :
String name = entry.split(" ")[0];
gives an ArrayIndexOutOfBoundsException: 0
It appears to be caused by a partitioned dataset whose members only contain
names. No other details (creation date, file type etc).
This is the method, if it helps:
private boolean parseSimpleEntry(FTPFile file, String entry) {
if (entry != null && entry.length() > 0) {
file.setRawListing(entry);
String name = entry.split(" ")[0]; // <--- error occurs
here
file.setName(name);
file.setType(FTPFile.FILE_TYPE);
return true;
}
return false;
}
> MVSFTPEntryParser.parseSimpleEntry - ArrayIndexOutOfBoundsException
> ---
>
> Key: NET-458
> URL: https://issues.apache.org/jira/browse/NET-458
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.0.1, 3.1
> Environment: zOS
>Reporter: Denis Molony
>
> Line 360 in MVSFTPEntryParser.parseSimpleEntry :
> String name = entry.split(" ")[0];
> gives an ArrayIndexOutOfBoundsException: 0
> It appears to be caused by a partitioned dataset whose members only contain
> names. No other details (creation date, file type etc).
> This is the method, if it helps:
> private boolean parseSimpleEntry(FTPFile file, String entry) {
> if (entry != null && entry.length() > 0) {
> file.setRawListing(entry);
> String name = entry.split(" ")[0]; // <--- error occurs
> here
> file.setName(name);
> file.setType(FTPFile.FILE_TYPE);
> return true;
> }
> return false;
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (NET-458) MVSFTPEntryParser.parseSimpleEntry - ArrayIndexOutOfBoundsException
MVSFTPEntryParser.parseSimpleEntry - ArrayIndexOutOfBoundsException
---
Key: NET-458
URL: https://issues.apache.org/jira/browse/NET-458
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.1, 3.0.1
Environment: zOS
Reporter: Denis Molony
Line 360 in MVSFTPEntryParser.parseSimpleEntry :
String name = entry.split(" ")[0];
gives an ArrayIndexOutOfBoundsException: 0
It appears to be caused by a partitioned dataset whose members only contain
names. No other details (creation date, file type etc).
This is the method, if it helps:
private boolean parseSimpleEntry(FTPFile file, String entry) {
if (entry != null && entry.length() > 0) {
file.setRawListing(entry);
String name = entry.split(" ")[0]; // <--- error occurs
here
file.setName(name);
file.setType(FTPFile.FILE_TYPE);
return true;
}
return false;
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DBCP-381) Threads BLOCKED on stress tests
Threads BLOCKED on stress tests --- Key: DBCP-381 URL: https://issues.apache.org/jira/browse/DBCP-381 Project: Commons Dbcp Issue Type: Bug Reporter: Carlos Martinez Hi, We are performing stress tests of OpenCMS. The database used is Oracle one. The pool of connections that OpenCMS is using is the DBCP pool. While performing performance tests we see that with minimal load already generated, almost all of the threads in java get "BLOCKED" trying to release back connections to the pool, and the performance of the application is really poor. We also see that the CPU consumption on the application server machine goes up to 100%. We are not generating enough load to cause this consumption. I believe that the CPU is all spent trying to handle those BLOCK threads. We did perform a thread dump of the Java on many occasions and the pattern is always similar. Plenty of connections blocked releasing the connection: --- "TP-Processor8" daemon prio=10 tid=0x7fa2848b4000 nid=0x4713 waiting for monitor entry [0x7fa2833f8000] java.lang.Thread.State: BLOCKED (on object monitor) at org.apache.commons.pool.impl.GenericObjectPool.returnObject(GenericObjectPool.java:916) - waiting to lock <0x000780ba7cc8> (a org.apache.commons.pool.impl.GenericObjectPool) at org.apache.commons.dbcp.PoolableConnection.close(PoolableConnection.java:87) - locked <0x0007811a6f78> (a org.apache.commons.dbcp.PoolableConnection) at org.apache.commons.dbcp.PoolingDriver$PoolGuardConnectionWrapper.close(PoolingDriver.java:269) at org.opencms.ocee.db.transaction.CmsTransactionConnection.close(CmsTransactionConnection.java:79) at org.opencms.ocee.db.transaction.CmsTransaction.close(CmsTransaction.java:121) at org.opencms.ocee.db.transaction.CmsTransactionDbContext.clear(CmsTransactionDbContext.java:99) at org.opencms.db.CmsSecurityManager.readFile(CmsSecurityManager.java:3351) at org.opencms.file.CmsObject.readFile(CmsObject.java:2725) at org.opencms.file.CmsObject.readFile(CmsObject.java:2777) at org.opencms.file.CmsObject.readFile(CmsObject.java:2747) at org.apache.jsp.WEB_002dINF.jsp.online.system.modules.org_opentrends_upf_template.templates.mainUPF_jsp._jspService(mainUPF_jsp.java:654) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98) - And one thread active releasing the connection: - "TP-Processor10" daemon prio=10 tid=0x7fa284b34800 nid=0x4715 runnable [0x7fa2831f4000] java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at oracle.net.ns.Packet.receive(Unknown Source) at oracle.net.ns.DataPacket.receive(Unknown Source) at oracle.net.ns.NetInputStream.getNextPacket(Unknown Source) at oracle.net.ns.NetInputStream.read(Unknown Source) at oracle.net.ns.NetInputStream.read(Unknown Source) at oracle.net.ns.NetInputStream.read(Unknown Source) at oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:1104) at oracle.jdbc.driver.T4CMAREngine.unmarshalSB1(T4CMAREngine.java:1075) at oracle.jdbc.driver.T4C7Ocommoncall.receive(T4C7Ocommoncall.java:106) at oracle.jdbc.driver.T4CConnection.doRollback(T4CConnection.java:568) - locked <0x0007810e2ac0> (a oracle.jdbc.driver.T4CConnection) at oracle.jdbc.driver.PhysicalConnection.rollback(PhysicalConnection.java:1164) - locked <0x0007810e2ac0> (a oracle.jdbc.driver.T4CConnection) at org.apache.commons.dbcp.DelegatingConnection.rollback(DelegatingConnection.java:328) at org.apache.commons.dbcp.DelegatingConnection.rollback(DelegatingConnection.java:328) at org.apache.commons.dbcp.PoolableConnectionFactory.passivateObject(PoolableConnectionFactory.java:359) at org.apache.commons.pool.impl.GenericObjectPool.addObjectToPool(GenericObjectPool.java:926) at org.apache.commons.pool.impl.GenericObjectPool.returnObject(GenericObjectPool.java:917) - locked <0x000780ba7cc8> (a org.apache.commons.pool.impl.GenericObjectPool) at org.apache.commons.dbcp.PoolableConnection.close(PoolableConnection.java:87) - locked <0x0007810e29b0> (a org.apache.commons.dbcp.PoolableConnection) at org.apache.commons.dbcp.PoolingDriver$PoolGuardConnectionWrapper.close(PoolingDriver.java:269) at org.opencms.ocee.db.transaction.CmsTransactionConnection.close(CmsTransactionConnection.java:79) at org.opencms.ocee.db.transaction.CmsTransaction.close(CmsTransaction.java:121) at org.opencms.ocee.db.transaction.CmsTransactionDbContext.clear(CmsTransactionDbContext.java:99) at org.
