[jira] [Resolved] (COMPRESS-451) IOUtils.copy hangs with misconfigured or corrupted inputs
[
https://issues.apache.org/jira/browse/COMPRESS-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-451.
-
Resolution: Fixed
Fix Version/s: 1.17
fixed with git commit 0aeda4fc, thanks!
> IOUtils.copy hangs with misconfigured or corrupted inputs
> -
>
> Key: COMPRESS-451
> URL: https://issues.apache.org/jira/browse/COMPRESS-451
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.0
>Reporter: John Doe
>Priority: Major
> Fix For: 1.17
>
>
> When the buffersize is misconfigured or corrupted, i.e., 0, the while loop in
> IOUtils.copy() function hangs endlessly. Here is the code snippet.
> {code:java}
> public static long copy(final InputStream input, final OutputStream
> output, int buffersize) throws IOException {
> final byte[] buffer = new byte[buffersize];//buffersize is
> misconfigured or corrupted
> int n = 0;
> long count=0;
> while (-1 != (n = input.read(buffer))) {//input.read returns 0 when
> buffer.length==0
> output.write(buffer, 0, n);
> count += n;
> }
> return count;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (COMPRESS-451) IOUtils.copy hangs with misconfigured or corrupted inputs
John Doe created COMPRESS-451:
-
Summary: IOUtils.copy hangs with misconfigured or corrupted inputs
Key: COMPRESS-451
URL: https://issues.apache.org/jira/browse/COMPRESS-451
Project: Commons Compress
Issue Type: Bug
Affects Versions: 1.0
Reporter: John Doe
When the buffersize is misconfigured or corrupted, i.e., 0, the while loop in
IOUtils.copy() function hangs endlessly. Here is the code snippet.
{code:java}
public static long copy(final InputStream input, final OutputStream output,
int buffersize) throws IOException {
final byte[] buffer = new byte[buffersize];//buffersize is
misconfigured or corrupted
int n = 0;
long count=0;
while (-1 != (n = input.read(buffer))) {//input.read returns 0 when
buffer.length==0
output.write(buffer, 0, n);
count += n;
}
return count;
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MATH-1459) Create a way to calculate the Jacobian Matrix using a Differentiator
[ https://issues.apache.org/jira/browse/MATH-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16463107#comment-16463107 ] adrian commented on MATH-1459: -- [~erans] I think I've fixed most of the things you suggest. * The checkstyle changes are fixed. * Passing in the differentiator is fixed. * As for the unit tests, I think I've fixed some of what you discuss over at the pull request, but I can address it further if you'd like. > Create a way to calculate the Jacobian Matrix using a Differentiator > > > Key: MATH-1459 > URL: https://issues.apache.org/jira/browse/MATH-1459 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 4.X >Reporter: adrian >Priority: Minor > Fix For: 4.X > > > Create a way to automatically calculate a Jacobian Matrix using a > Differentiator. > I have done this with a pull request, but would like feedback. > edit: https://github.com/apache/commons-math/pull/84 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (DBUTILS-138) Exception in closing statement leave connections open
Stefano Lissa created DBUTILS-138:
-
Summary: Exception in closing statement leave connections open
Key: DBUTILS-138
URL: https://issues.apache.org/jira/browse/DBUTILS-138
Project: Commons DbUtils
Issue Type: Bug
Affects Versions: 1.7
Environment: SQL Server 2012, Java 8, MS JDBC Driver 4.
Reporter: Stefano Lissa
On class QueryRunner starting at line 393 (see the snippet below) if the
statement close attempt results in an exception, the connection is not closed
correctly. I was not able to intercept the exception since it happens in a
production environment with SQL Server 2012, Java 8 and original MS drivers,
but the effect is the connection pool fills up and finally starts to log
abandoned connections opened by QueryRunner.
{noformat}
} finally {
try {
close(rs);
} finally {
close(stmt);
if (closeConn) {
close(conn);
}
}
}{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DAEMON-243) Support for Failure Recovery
[
https://issues.apache.org/jira/browse/DAEMON-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16462803#comment-16462803
]
Marat Abrarov commented on DAEMON-243:
--
I was a little bit wrong in my previous comment - there is one more option
named "failure flag" ("Enable actions for stops with errors" checkbox on
"Recovery" tab of Windows service view at "Services" MMC snap-in). Refer to
[https://serverfault.com/questions/72318/set-up-recovery-actions-to-take-place-when-a-service-fails]
for details. This flag can be used with existing Commons Daemon (tested on
1.0.15.0 version) to make recovery actions working, but I'm wondering why
doesn't prunsrv turn on this flag by default (this looks like an opportunity
for enhancement) or doesn't provide some command option for installing service
with this flag?
> Support for Failure Recovery
>
>
> Key: DAEMON-243
> URL: https://issues.apache.org/jira/browse/DAEMON-243
> Project: Commons Daemon
> Issue Type: New Feature
> Components: Procrun
>Affects Versions: 1.0.10
> Environment: MS Windows
>Reporter: Peter Ehrbar
>Priority: Minor
>
> The MS Windows Service Controller provides functionality to perform some
> basic failure recovery actions: Restart service or execute any command or
> restart the machine. This can be configured using the Service Controller GUI
> or in a shell with SC.EXE (commands FAILURE and FAILUREFLAG).
> It would be convenient if this could be configured also using procrun.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MATH-1458) Simpson Integrator computes incorrect value at minimum iterations=1 and wastes an iteration
[
https://issues.apache.org/jira/browse/MATH-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16462262#comment-16462262
]
Alex D Herbert commented on MATH-1458:
--
I've branched the git repo and will create tests that the current
SimpsonItegrator fails. I'll then fix it and submit a pull request for review.
> Simpson Integrator computes incorrect value at minimum iterations=1 and
> wastes an iteration
> ---
>
> Key: MATH-1458
> URL: https://issues.apache.org/jira/browse/MATH-1458
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
> Environment: openjdk version "1.8.0_162"
>
> OpenJDK Runtime Environment (build 1.8.0_162-8u162-b12-0ubuntu0.16.04.2-b12)
>
> OpenJDK 64-Bit Server VM (build 25.162-b12, mixed mode)
>Reporter: Alex D Herbert
>Priority: Minor
> Labels: documentation, easyfix, newbie, patch
>
> org.apache.commons.math3.analysis.integration.SimpsonIntergrator
> When used with minimalIterationCount == 1 the integrator computes the wrong
> value due to the inlining of computation of stage 1 and stage 0 of the
> TrapezoidIntegrator. Each stage is successive since it relies on the result
> of the previous stage. So stage 0 must be computed first. This inlining
> causes stage 1 to be computed before stage 0:
> {code:java}
> return (4 * qtrap.stage(this, 1) - qtrap.stage(this, 0)) / 3.0;
> {code}
> This can be fixed using:
> {code:java}
> final double s0 = qtrap.stage(this, 0);
> return (4 * qtrap.stage(this, 1) - s0) / 3.0;{code}
> What is not clear is why setting minimum iterations to 1 results in no
> iteration. This is not documented. I would expect setting it to 1 would
> compute the first Simpson sum and then perform 1 refinement. This would make
> it functionality equivalent to the other Integrator classes which compute two
> sums for the first iteration and allow them to be compared if minimum
> iterations = 1. If convergence fails then each additional iteration computes
> an additional sum.
> Note when used with minimalIterationCount > 1 the SimpsonIntegrator wastes a
> stage since it computes the following stages: 0, 0, 1, 2, 3. i.e. stage 0 is
> computed twice. This is because the iteration is incremented after the stage
> is computed:
> {code:java}
> final double t = qtrap.stage(this, getIterations());
> incrementCount();
> {code}
> This should be:
> {code:java}
> incrementCount();
> final double t = qtrap.stage(this, getIterations());
> {code}
> On the first iteration it thus computes the trapezoid sum and compares it to
> zero. This would result in a bad computation if integrating a function whose
> trapezoid sum is zero (e.g. y=x^3 in the range -1 to 1). However since
> iteration only occurs for minimalIterationCount>1 no termination comparison
> is made on the first loop. The first termination comparison can be made at
> iteration=2 where the comparison will be between the Trapezoid sum and the
> first Simpson sum. This is a bug.
> However I do not want to submit a formal patch as there is a lack of
> consistency across all the integrators in their doIntegrate() method with the
> use of incrementCount() and what the iteration number should be at the start
> of the while (true) loop:
> * IterativeLegendreGauss integrator uses getIterations()+1 to mark the
> current iteration inside the loop and calls incrementCount() at the end.
> * TrapezoidIntegrator calls incrementCount() outside the loop, uses
> getIterations() to mark the current iteration and calls incrementCount() at
> the end.
> * The MidpointIntegrator calls incrementCount() at the start of the loop and
> uses getIterations() to mark the current iteration.
> * The RombergIntegrator calls incrementCount() outside the loop, uses
> getIterations() to mark the current iteration and calls incrementCount() in
> the middle of the loop before termination conditions have been checked. This
> allows it to fail when the iterations are equal to the maximum iterations
> even if convergence has been achieved (see Note*).
> * The SimpsonIntegrator uses getIterations() to mark the current iteration
> and calls incrementCount() immediately after.
> Note*: This may not be discovered in a unit test since the incrementCount()
> uses a backing Incrementor where the Incrementor.increment() method calls
> Incrementor.increment(1) which ends up calling canIncrement(0) \{ instead of
> canIncrement(nTimes) } to check if the maxCountCallback should be triggered.
> I expect that all uses of the Incrementor actually trigger the
> maxCountCallback when the c
[jira] [Commented] (MATH-1459) Create a way to calculate the Jacobian Matrix using a Differentiator
[
https://issues.apache.org/jira/browse/MATH-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16462240#comment-16462240
]
Gilles commented on MATH-1459:
--
I've already fixed the tolerance typo (1e14 vs 1e-14); thanks.
Please run
{noformat}
$ mvn site
{noformat}
It will generate various reports in the {{target/site}} directory so that you
can verify that your submission does not trigger "CheckStyle" warnings. All
methods and fields must be documented.
I also think that the unit test class is problematic as it will run many tests
(from the base class) that are not impacted by the overridden "builder".
As for the feature itself, I wonder whether the differentiator should be a
parameter (of some factory method); that way, the user would be responsible for
the possible caveats that currently only appear as warnings in the doc.
> Create a way to calculate the Jacobian Matrix using a Differentiator
>
>
> Key: MATH-1459
> URL: https://issues.apache.org/jira/browse/MATH-1459
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 4.X
>Reporter: adrian
>Priority: Minor
> Fix For: 4.X
>
>
> Create a way to automatically calculate a Jacobian Matrix using a
> Differentiator.
> I have done this with a pull request, but would like feedback.
> edit: https://github.com/apache/commons-math/pull/84
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
