[jira] [Updated] (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:all-tabpanel ] adrian updated MATH-1459: - Description: Create a way to automatically calculate a Jacobian Matrix using a Differentiator. I have done this with a pull request, but would like feedback. https://github.com/apache/commons-math/pull/84 was: Create a way to automatically calculate a Jacobian Matrix using a Differentiator. I have done this with a pull request, but would like feedback. > 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. > https://github.com/apache/commons-math/pull/84 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (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:all-tabpanel ] adrian updated MATH-1459: - Description: 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 was: Create a way to automatically calculate a Jacobian Matrix using a Differentiator. I have done this with a pull request, but would like feedback. https://github.com/apache/commons-math/pull/84 > 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] [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=16461582#comment-16461582 ] adrian commented on MATH-1459: -- [~erans] [https://github.com/apache/commons-math/pull/84] thanks! > 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. -- 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=16461450#comment-16461450
]
Gilles commented on MATH-1458:
--
I've created issue MATH-1460. Please have a look.
{quote}I assumed that a core developer would be able to look at this and I had
contributed enough. Are you saying that I have to provide the patch?
{quote}
We are lacking time and expertise to support all the code in this library.
We've started to split it in more manageable parts that can be maintained more
easily by people not necessarily able to fix all the issues that keep coming
for Commons Math and prevent timely releases.
See the new components [Commons RNG|http://commons.apache.org/rng], [Commons
Numbers|http://commons.apache.org/numbers], [Commons
Statistics|http://commons.apache.org/statistics], [Commons
Geometry|http://commons.apache.org/geometry], ... that are at various stages of
completion.
You are most welcome to contribute to e.g. a new module in "Commons Numbers"
that could contain selected parts of the code currently in package
{{org.apache.commons.math4.analysis}}.
> 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
[jira] [Commented] (MATH-1460) IntegerSequence.Incrementor should fail earlier
[
https://issues.apache.org/jira/browse/MATH-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461414#comment-16461414
]
Gilles commented on MATH-1460:
--
Tentative solution in commit f43069ac6d281b8367dad6f78def4b8336a11ff0 (please
review).
> IntegerSequence.Incrementor should fail earlier
> ---
>
> Key: MATH-1460
> URL: https://issues.apache.org/jira/browse/MATH-1460
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Gilles
>Assignee: Gilles
>Priority: Minor
> Fix For: 4.0
>
>
> Method {{increment(int nTimes)}} allows increment beyond the maximal value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MATH-1460) IntegerSequence.Incrementor should fail earlier
Gilles created MATH-1460:
Summary: IntegerSequence.Incrementor should fail earlier
Key: MATH-1460
URL: https://issues.apache.org/jira/browse/MATH-1460
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.6.1
Reporter: Gilles
Assignee: Gilles
Fix For: 4.0
Method {{increment(int nTimes)}} allows increment beyond the maximal value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IMAGING-216) Imaging.getBufferedImage() drops alpha layer for TIFF images
Matthew Binsfeld created IMAGING-216: Summary: Imaging.getBufferedImage() drops alpha layer for TIFF images Key: IMAGING-216 URL: https://issues.apache.org/jira/browse/IMAGING-216 Project: Commons Imaging Issue Type: Bug Reporter: Matthew Binsfeld When calling Imaging.getBufferedImage(byte[] image) on a TIFF image containing an alpha layer the resulting BufferedImage does not have and does not support alpha layers. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (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=16460916#comment-16460916
]
Alex D Herbert edited comment on MATH-1458 at 5/2/18 11:44 AM:
---
The comment about the Incrementor is for the new IntegerSequence.Incrementor
not the deprecated org.apache.commons.math3.util.Incrementor.
I think the public void increment(int nTimes) method of
IntegerSequence.Incrementor should be:
{code:java}
public void increment(int nTimes) throws MaxCountExceededException {
if (nTimes <= 0) {
throw new NotStrictlyPositiveException(nTimes);
}
// This is a change from: if (!canIncrement(0)) {
if (!canIncrement(nTimes)) {
maxCountCallback.trigger(maximalCount);
}
count += nTimes * increment;
}
{code}
Since I am new to this please allow some naive questions. I assumed that a core
developer would be able to look at this and I had contributed enough. Are you
saying that I have to provide the patch?
was (Author: alexherbert):
The comment about the Incrementor is for the new IntegerSequence.Incrementor
not the deprecated org.apache.commons.math3.util.Incrementor.
I think the public void increment(int nTimes) method of
IntegerSequence.Incrementor should be:
{code:java}
public void increment(int nTimes) throws MaxCountExceededException {
if (nTimes <= 0) {
throw new NotStrictlyPositiveException(nTimes);
}
// This is a change from: if (!canIncrement(0)) {
if (!canIncrement(nTimes)) {
maxCountCallback.trigger(maximalCount);
}
count += nTimes * increment;
}
{code}
Since I am new to this please allow some naive questions. I assumed that a core
developer would be able to look at this and I had contributed enough. Are you
saying that I have to provide the patch?
> 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()
[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=16460916#comment-16460916
]
Alex D Herbert commented on MATH-1458:
--
The comment about the Incrementor is for the new IntegerSequence.Incrementor
not the deprecated org.apache.commons.math3.util.Incrementor.
I think the public void increment(int nTimes) method of
IntegerSequence.Incrementor should be:
{code:java}
public void increment(int nTimes) throws MaxCountExceededException {
if (nTimes <= 0) {
throw new NotStrictlyPositiveException(nTimes);
}
// This is a change from: if (!canIncrement(0)) {
if (!canIncrement(nTimes)) {
maxCountCallback.trigger(maximalCount);
}
count += nTimes * increment;
}
{code}
Since I am new to this please allow some naive questions. I assumed that a core
developer would be able to look at this and I had contributed enough. Are you
saying that I have to provide the patch?
> 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
>
[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=16460872#comment-16460872
]
Gilles commented on MATH-1458:
--
Thanks a lot for the report and thorough analysis.
The next step would be to write a unit test that displays the bug. And then a
patch/PR to fix it.
I don't follow the argument about {{Incrementor}} but please note that it is
_deprecated_ in the development version of the library: updates/fixes should be
performed against the "master" branch in the code repository.
> 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
[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=16460865#comment-16460865 ] Gilles commented on MATH-1459: -- bq. I have done this with a pull request, but would like feedback. Please provide the link to the PR. Thanks. > 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. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FILEUPLOAD-262) Processing of multipart/form-data request failed. null
[
https://issues.apache.org/jira/browse/FILEUPLOAD-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460859#comment-16460859
]
Jochen Wiedmann commented on FILEUPLOAD-262:
Quoting [~vmallavarapu]:
Caused by: java.io.EOFException: null
In other words, this is most likely a client aborting the transfer, for
whatever reason. Not much, we can do here.
> Processing of multipart/form-data request failed. null
> --
>
> Key: FILEUPLOAD-262
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-262
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.2, 1.3.1
> Environment: Application: Jetty 9.1.4, Debian stable x86_64, Java
> 1.7.0_51
> Public access through reverse proxy (apache 2 2.2.22 + mod_proxy)
>Reporter: Kristian Rink
>Priority: Minor
> Labels: eof, exception, stacktrace
> Attachments: fileupload_error_veera.txt
>
>
> Exposing an upload feature in an existing web application, I frequently see
> stack traces as the one posted below in my server log files. Additional notes:
> - The application runs in an embedded jetty (HTTP) behind an apache2
> mod_proxy reverse proxy (HTTPS).
> - These issues do not generally appear, I tried quite some uploading
> myself today and never managed to reproduce this behaviour even while
> uploading loads of files, large files and both together.
> - It does not seem to be generally tied to a particular browser; the
> users associated with these messages use Firefox, MSIE or Chrome.
> - Looking at network traffic (and the transfer monitor in the app), it
> _seems_ all data to be sent with the request have successfully been
> transmitted yet parsing the request, ultimately, fails.
> - On _some_ clients, in such situations users reported the upload was
> canceled with a "connection reset by peer" error, even though I do not
> see reasons for that in our mod_proxy server log.
> - The application uses the approach outlined in [1] to render a progress bar
> based upon JavaScript and DWR. There is code in that controller trying to
> check how much data has been received by the server so far. I do dump these
> information to the log right now, and it seems all(?) data has been received
> before we run into this error, even though I am not sure about that at all as
> I am unsure how the frameworks handles HTTP traffic internally and how this
> is handled in example with chunked transfer encoding:
> 2014-11-21 18:26:01,846 [qtp1780643722-438] INFO WebUIUploadController -
> uploadStats: 2100399 of 2100399
> Stack trace seen in such situations:
> {code:java}
> org.apache.commons.fileupload.FileUploadBase$IOFileUploadException:
> Processing of multipart/form-data request failed. null
> at
> org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:351)
> ~[commons-fileupload-1.3.1.jar:1.3.1]
> at
> org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:115)
> ~[commons-fileupload-1.3.1.jar:1.3.1]
> at
> de.pc.frontend.WebUIUploadController.submitUpload(WebUIUploadController.java:189)
> ~[webprojekt-1.2-SNAPSHOT.jar:na]
> at sun.reflect.GeneratedMethodAccessor104.invoke(Unknown Source)
> ~[na:na]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[na:1.7.0_51]
> at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_51]
> at
> org.springframework.web.bind.annotation.support.HandlerMethodInvoker.invokeHandlerMethod(HandlerMethodInvoker.java:176)
> [spring-web-3.0.6.RELEASE.jar:3.0.6.RELEASE]
> at
> org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.invokeHandlerMethod(AnnotationMethodHandlerAdapter.java:436)
> [spring-webmvc-3.0.6.RELEASE.jar:3.0.6.RELEASE]
> at
> org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.handle(AnnotationMethodHandlerAdapter.java:424)
> [spring-webmvc-3.0.6.RELEASE.jar:3.0.6.RELEASE]
> at
> org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:790)
> [spring-webmvc-3.0.6.RELEASE.jar:3.0.6.RELEASE]
> at
> org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:719)
> [spring-webmvc-3.0.6.RELEASE.jar:3.0.6.RELEASE]
> at
> org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:669)
> [spring-webmvc-3.0.6.RELEASE.jar:3.0.6.RELEASE]
> at
> org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:585)
> [spring-webmvc-3.0.6.RELEASE.jar:3.0.6.RELEASE]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
> [javax.servlet-api-3.1.0.jar:3.1.0]
> at
