[jira] [Commented] (EXEC-41) Patch to enable executing thread to return immediately when process is killed by a watchdog
[ https://issues.apache.org/jira/browse/EXEC-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13160722#comment-13160722 ] Bhavesh Shah commented on EXEC-41: -- Where should I put this patch files? Means in which directory? Patch to enable executing thread to return immediately when process is killed by a watchdog - Key: EXEC-41 URL: https://issues.apache.org/jira/browse/EXEC-41 Project: Commons Exec Issue Type: Improvement Affects Versions: 1.0, 1.1 Environment: Windows XP Reporter: Ernest Mishkin Assignee: Siegfried Goeschl Priority: Minor Fix For: 1.1 Attachments: EXEC-41.patch, commons-exec.patch This has been discussed on the commons-users mailing list. The patch intends to solve the following problem: when a process runs longer than allowed by a configured watchdog's timeout, the watchdog tries to destroy it and then DefaultExecutor tries to clean up by joining with all installed pump stream threads. Problem is, that sometimes the native process doesn't die and thus streams aren't closed and the stream threads do not complete. The patch provides setAlwaysWaitForStreamThreads(boolean) method in PumpStreamHandler. By default, alwaysWaitForStreamThreads is set to true to preserve the current behavior. If set to false, and process is killed by watchdog, DefaultExecutor's call into ErrorStreamHandler.stop will NOT join the stream threads and DefaultExecutor will NOT attempt to close the streams, so the executor's thread won't get stuck. Additionally, this patch fixes a small but annoying bug in DefaultExecuteHandler.setExitValues(int[]) -- 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] (JEXL-83) Make JexlArithmetic immutable (and threadsafe)
[ https://issues.apache.org/jira/browse/JEXL-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13160757#comment-13160757 ] Sebb commented on JEXL-83: -- An alternative solution is to make the boolean variables (strict/debug/silent) volatile. If one thread changes the value, then at least all other threads would see the updated value (which is currently not the case). As far as I can tell the code does not rely on the values remaining unchanged; it checks the values on demand. So the worst that could happen would be minor changes in behaviour during an evaluation. Make JexlArithmetic immutable (and threadsafe) -- Key: JEXL-83 URL: https://issues.apache.org/jira/browse/JEXL-83 Project: Commons JEXL Issue Type: Improvement Reporter: Sebb Assignee: Henri Biestro Fix For: 3.0 Attachments: JEXL-83.patch The JexlArithmetic class is currently not thread-safe because of the single field: /** Whether this JexlArithmetic instance behaves in strict or lenient mode. */ protected boolean strict; If this field were made final, and the setLenient() method removed, then the class would be immutable and therefore thread-safe. This would mean that JexlEngine would also have to change. The class is new to 2.0, so this is the best time to fix this. -- 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] (MATH-716) BracketingNthOrderBrentSolver exceeds maxIterationCount while updating always the same boundary
BracketingNthOrderBrentSolver exceeds maxIterationCount while updating always the same boundary --- Key: MATH-716 URL: https://issues.apache.org/jira/browse/MATH-716 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Pascal Parraud Priority: Minor In some cases, the aging feature in BracketingNthOrderBrentSolver fails. It attempts to balance the bracketing points by targeting a non-zero value instead of the real root. However, the chosen target is too close too zero, and the inverse polynomial approximation is always on the same side, thus always updates the same bracket. In the real used case for a large program, I had a bracket point xA = 12500.0, yA = 3.7e-16, agingA = 0, which is the (really good) estimate of the zero on one side of the root and xB = 12500.03, yB = -7.0e-5, agingB = 97. This shows that the bracketing interval is completely unbalanced, and we never succeed to rebalance it as we always updates (xA, yA) and never updates (xB, yB). -- 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] (MATH-716) BracketingNthOrderBrentSolver exceeds maxIterationCount while updating always the same boundary
[ https://issues.apache.org/jira/browse/MATH-716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe updated MATH-716: --- Assignee: Luc Maisonobe The problem Pascal (who works with me) describes has already been encountered during the development of the algorithm. The solution found at that time seems to be insufficient. What happens is that in order to still gain a few digits while rebalancing the bracketing interval, we base our retargeting on the currently best solution. In this case, we set targetY = -yA/16 and fail to rebalance. Using the other bracket would improve rebalancing but waste evaluations as was observed during development. So its not a perfect solution either. I think a compromise would be to attempt rebalancing with a progressively more aggressive target. We could start from the current setting (i.e -1/16 of the best bracket), and if we still update the same side, move towards larger targets. BracketingNthOrderBrentSolver exceeds maxIterationCount while updating always the same boundary --- Key: MATH-716 URL: https://issues.apache.org/jira/browse/MATH-716 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Pascal Parraud Assignee: Luc Maisonobe Priority: Minor In some cases, the aging feature in BracketingNthOrderBrentSolver fails. It attempts to balance the bracketing points by targeting a non-zero value instead of the real root. However, the chosen target is too close too zero, and the inverse polynomial approximation is always on the same side, thus always updates the same bracket. In the real used case for a large program, I had a bracket point xA = 12500.0, yA = 3.7e-16, agingA = 0, which is the (really good) estimate of the zero on one side of the root and xB = 12500.03, yB = -7.0e-5, agingB = 97. This shows that the bracketing interval is completely unbalanced, and we never succeed to rebalance it as we always updates (xA, yA) and never updates (xB, yB). -- 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] (DBCP-371) DelegatingDatabaseMetaData
[ https://issues.apache.org/jira/browse/DBCP-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13160782#comment-13160782 ] Säll, Jan commented on DBCP-371: Hi When will the DBCP 1.3.1 / 1.4.1 be available? We need to decide how to do - wait for this or go to 1.2 Best regards jan Jan Säll Produktägare och Utvecklingschef Palasso BPO HRM | Logica Sweden Magasin 3, Löfbergskajen, 652 24 Karlstad | Sweden T: +46 54 14 71 37 | M: +46 733 98 10 21 jan.s...@logica.commailto:jan.s...@logica.com | www.logica.se http://www.logica.se/ Från: Fredrik Bertilsson [mailto:freb...@gmail.com] Skickat: den 1 december 2011 08:42 Till: Säll, Jan Ämne: Fwd: [jira] [Closed] (DBCP-371) DelegatingDatabaseMetaData Hej, verkar som att apache har en fix på gång i version 1.4.1. Mvh Fredrik B -- Forwarded message -- From: Phil Steitz (Closed) (JIRA) j...@apache.orgmailto:j...@apache.org Date: Thu, Dec 1, 2011 at 8:01 AM Subject: [jira] [Closed] (DBCP-371) DelegatingDatabaseMetaData To: freb...@gmail.commailto:freb...@gmail.com [ https://issues.apache.org/jira/browse/DBCP-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-371. Resolution: Duplicate Fix Version/s: (was: 1.2) 1.4.1 This duplicates DBCP-330, which has been fixed in the DBCP_1_4 branch. The fix will be included in DBCP 1.3.1 / 1.4.1 -- 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.jspahttps://issues.apache.org/jira/secure/ContactAdministrators%21default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira -- Mvh Fredrik Bertilsson 0766-519617 Think green - keep it on the screen. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. DelegatingDatabaseMetaData -- Key: DBCP-371 URL: https://issues.apache.org/jira/browse/DBCP-371 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.3, 1.4 Environment: Informix database Reporter: Fredrik Bertilsson Priority: Critical Fix For: 1.4.1 When calling Connection.getMetaData() new objects of DelegationDatabaseMetaData and corresponding vendor specific objects (like IfxDatabaseMetaData) are created and never released for garabage collection. This bug seem to have been introduced in version 1.3. Version 1.2 does not have this problem. -- 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] (MATH-710) Add support for fast cryptographically secure pseudorandom number generator ISAAC
[ https://issues.apache.org/jira/browse/MATH-710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eldar Agalarov updated MATH-710: Attachment: ISAACRandom.java.patch Add support for fast cryptographically secure pseudorandom number generator ISAAC - Key: MATH-710 URL: https://issues.apache.org/jira/browse/MATH-710 Project: Commons Math Issue Type: New Feature Affects Versions: 2.2 Reporter: Eldar Agalarov Assignee: Luc Maisonobe Priority: Minor Fix For: 3.0 Attachments: ISAACRandom.java, ISAACRandom.java.patch, ISAACTest.java Original Estimate: 1h Remaining Estimate: 1h Dear developers, please add to Commons Math library support for ISAAC random number generator. This is a free and open-source CSPRNG (see at http://burtleburtle.net/bob/rand/isaacafa.html). Rewrited (with some improvements) Java code from original C version is attached. -- 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-710) Add support for fast cryptographically secure pseudorandom number generator ISAAC
[ https://issues.apache.org/jira/browse/MATH-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13160840#comment-13160840 ] Eldar Agalarov commented on MATH-710: - Thank you Luc! SVN patch files with minor changes added. Add support for fast cryptographically secure pseudorandom number generator ISAAC - Key: MATH-710 URL: https://issues.apache.org/jira/browse/MATH-710 Project: Commons Math Issue Type: New Feature Affects Versions: 2.2 Reporter: Eldar Agalarov Assignee: Luc Maisonobe Priority: Minor Fix For: 3.0 Attachments: ISAACRandom.java, ISAACRandom.java.patch, ISAACTest.java Original Estimate: 1h Remaining Estimate: 1h Dear developers, please add to Commons Math library support for ISAAC random number generator. This is a free and open-source CSPRNG (see at http://burtleburtle.net/bob/rand/isaacafa.html). Rewrited (with some improvements) Java code from original C version is attached. -- 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] (MATH-710) Add support for fast cryptographically secure pseudorandom number generator ISAAC
[ https://issues.apache.org/jira/browse/MATH-710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eldar Agalarov updated MATH-710: Attachment: ISAACTest.java.patch Add support for fast cryptographically secure pseudorandom number generator ISAAC - Key: MATH-710 URL: https://issues.apache.org/jira/browse/MATH-710 Project: Commons Math Issue Type: New Feature Affects Versions: 2.2 Reporter: Eldar Agalarov Assignee: Luc Maisonobe Priority: Minor Fix For: 3.0 Attachments: ISAACRandom.java, ISAACRandom.java.patch, ISAACTest.java, ISAACTest.java.patch Original Estimate: 1h Remaining Estimate: 1h Dear developers, please add to Commons Math library support for ISAAC random number generator. This is a free and open-source CSPRNG (see at http://burtleburtle.net/bob/rand/isaacafa.html). Rewrited (with some improvements) Java code from original C version is attached. -- 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] [Reopened] (MATH-710) Add support for fast cryptographically secure pseudorandom number generator ISAAC
[ https://issues.apache.org/jira/browse/MATH-710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eldar Agalarov reopened MATH-710: - Patch files added with minor changes Add support for fast cryptographically secure pseudorandom number generator ISAAC - Key: MATH-710 URL: https://issues.apache.org/jira/browse/MATH-710 Project: Commons Math Issue Type: New Feature Affects Versions: 2.2 Reporter: Eldar Agalarov Assignee: Luc Maisonobe Priority: Minor Fix For: 3.0 Attachments: ISAACRandom.java, ISAACRandom.java.patch, ISAACTest.java, ISAACTest.java.patch Original Estimate: 1h Remaining Estimate: 1h Dear developers, please add to Commons Math library support for ISAAC random number generator. This is a free and open-source CSPRNG (see at http://burtleburtle.net/bob/rand/isaacafa.html). Rewrited (with some improvements) Java code from original C version is attached. -- 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] (MATH-717) A varied class of Array2DRowRealMatrix is needed to contain float type instead of double.
A varied class of Array2DRowRealMatrix is needed to contain float type instead of double. - Key: MATH-717 URL: https://issues.apache.org/jira/browse/MATH-717 Project: Commons Math Issue Type: Improvement Affects Versions: 2.2 Environment: All Reporter: Dusan Ku The current implementation of Array2DRowRealMatrix takes only double type as its base element value in the matrix. However, the memory size of double is bigger than float, the downside of which makes the matrix dimension quite limited, compared to float type as its base element type. For small sized problem, this does not make such a big difference, but for large problems, this limits the usability of this library quite limited. In my case, I easily hit an error even after I increase the memory option to 1G. This could have been much more enhanced just by using 'float[][]' instead of the current Array2DRowRealMatrix. Therefore, the solution I may suggest is to add another class similar to Array2DRowRealMatrix containing float type for its matrix variable instead of double. Of course, a better way is welcome as long as the needs can be fulfilled. -- 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] (MATH-717) A varied class of Array2DRowRealMatrix is needed to contain float type instead of double.
[ https://issues.apache.org/jira/browse/MATH-717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dusan Ku updated MATH-717: -- Description: The current implementation of Array2DRowRealMatrix takes only double type as its base element value in the matrix. However, the memory size of double is bigger than float, the downside of which makes the matrix dimension quite limited, compared to float type as its base element type. For small sized problem, this does not make such a big difference, but for large problems, this limits the usability of this library quite severely. In my case, I easily hit an error even after I increase the memory option to 1G. This could have been much more enhanced just by using 'float[][]' instead of the current Array2DRowRealMatrix. Therefore, the solution I may suggest is to add another class similar to Array2DRowRealMatrix containing float type for its matrix variable instead of double. Of course, a better way is welcome as long as the needs can be fulfilled. was: The current implementation of Array2DRowRealMatrix takes only double type as its base element value in the matrix. However, the memory size of double is bigger than float, the downside of which makes the matrix dimension quite limited, compared to float type as its base element type. For small sized problem, this does not make such a big difference, but for large problems, this limits the usability of this library quite limited. In my case, I easily hit an error even after I increase the memory option to 1G. This could have been much more enhanced just by using 'float[][]' instead of the current Array2DRowRealMatrix. Therefore, the solution I may suggest is to add another class similar to Array2DRowRealMatrix containing float type for its matrix variable instead of double. Of course, a better way is welcome as long as the needs can be fulfilled. A varied class of Array2DRowRealMatrix is needed to contain float type instead of double. - Key: MATH-717 URL: https://issues.apache.org/jira/browse/MATH-717 Project: Commons Math Issue Type: Improvement Affects Versions: 2.2 Environment: All Reporter: Dusan Ku Labels: features The current implementation of Array2DRowRealMatrix takes only double type as its base element value in the matrix. However, the memory size of double is bigger than float, the downside of which makes the matrix dimension quite limited, compared to float type as its base element type. For small sized problem, this does not make such a big difference, but for large problems, this limits the usability of this library quite severely. In my case, I easily hit an error even after I increase the memory option to 1G. This could have been much more enhanced just by using 'float[][]' instead of the current Array2DRowRealMatrix. Therefore, the solution I may suggest is to add another class similar to Array2DRowRealMatrix containing float type for its matrix variable instead of double. Of course, a better way is welcome as long as the needs can be fulfilled. -- 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-690) Remove methods from MathUtils
[ https://issues.apache.org/jira/browse/MATH-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13160927#comment-13160927 ] Gilles commented on MATH-690: - Revision 1209100: * Removed sign methods. Remove methods from MathUtils --- Key: MATH-690 URL: https://issues.apache.org/jira/browse/MATH-690 Project: Commons Math Issue Type: Task Reporter: Gilles Assignee: Gilles Priority: Trivial Labels: api-change Fix For: 3.0 I propose to remove the following methods from MathUtils: public static double sign(final double x) public static float sign(final float x) public static double sinh(double x) public static double cosh(double x) Also, sign and indicator functions seem redundant (and the float and double versions are not dealing correctly with -0.0). -- 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] (MATH-690) Remove methods from MathUtils
[ https://issues.apache.org/jira/browse/MATH-690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-690. - Resolution: Fixed Remove methods from MathUtils --- Key: MATH-690 URL: https://issues.apache.org/jira/browse/MATH-690 Project: Commons Math Issue Type: Task Reporter: Gilles Assignee: Gilles Priority: Trivial Labels: api-change Fix For: 3.0 I propose to remove the following methods from MathUtils: public static double sign(final double x) public static float sign(final float x) public static double sinh(double x) public static double cosh(double x) Also, sign and indicator functions seem redundant (and the float and double versions are not dealing correctly with -0.0). -- 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] (MATH-689) Breaking up MathUtils
[ https://issues.apache.org/jira/browse/MATH-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-689. - Resolution: Fixed Breaking up MathUtils --- Key: MATH-689 URL: https://issues.apache.org/jira/browse/MATH-689 Project: Commons Math Issue Type: Task Reporter: Gilles Priority: Trivial Labels: api-change Fix For: 3.0 Issue related to this [proposal|http://www.mail-archive.com/dev@commons.apache.org/msg25617.html]. There seemed to be a global agreement on the following break-up: * Arithmetics (for addAndCheck, factorial, gcd, ...) * Precision (for equals, compare, ...) * Binomial (for binomialCoefficient) * MathArrays (for linearCombination, distance, safeNorm, sortInPlace, copyOf, ...) I think that ordinary mathematical functions (pow, cosh, ...) should go into FastMath (if not already available there). Those who are willing to work on this issue, please coordinate here. -- 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-690) Remove methods from MathUtils
[ https://issues.apache.org/jira/browse/MATH-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13160943#comment-13160943 ] Gilles commented on MATH-690: - Modified unit tests committed in r1209118. Remove methods from MathUtils --- Key: MATH-690 URL: https://issues.apache.org/jira/browse/MATH-690 Project: Commons Math Issue Type: Task Reporter: Gilles Assignee: Gilles Priority: Trivial Labels: api-change Fix For: 3.0 I propose to remove the following methods from MathUtils: public static double sign(final double x) public static float sign(final float x) public static double sinh(double x) public static double cosh(double x) Also, sign and indicator functions seem redundant (and the float and double versions are not dealing correctly with -0.0). -- 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] (FILEUPLOAD-202) org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. Stream ended unexpectedly
org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing
of multipart/form-data request failed. Stream ended unexpectedly
---
Key: FILEUPLOAD-202
URL: https://issues.apache.org/jira/browse/FILEUPLOAD-202
Project: Commons FileUpload
Issue Type: Bug
Affects Versions: 1.2.1
Reporter: tina
Fix For: 1.2.1
I used this one to write the servlet
http://www.servletworld.com/servlet-tutorials/servlet-file-upload-example.html
I can successfully upload the file through localhost, however, when I use
Jmeter to test the app server using 300 threads, it
will report this error:
[10:40:23.577] {http--8080-244$1283730842}
WebApp[http://localhost:8080/OrderFile] CommonsFileUploadServlet: Error
encountered while parsing the request
[10:40:23.577] {http--8080-244$1283730842}
org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing
of multipart/form-data request failed. Stream ended unexpectedly
[10:40:23.577] {http--8080-244$1283730842} at
org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:371)
[10:40:23.577] {http--8080-244$1283730842} at
org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:126)
[10:40:23.577] {http--8080-244$1283730842} at
CommonsFileUploadServlet.doPost(CommonsFileUploadServlet.java:66)
[10:40:23.577] {http--8080-244$1283730842} at
javax.servlet.http.HttpServlet.service(HttpServlet.java:153)
[10:40:23.577] {http--8080-244$1283730842} at
javax.servlet.http.HttpServlet.service(HttpServlet.java:91)
[10:40:23.577] {http--8080-244$1283730842} at
com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:103)
[10:40:23.577] {http--8080-244$1283730842} at
com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:187)
[10:40:23.577] {http--8080-244$1283730842} at
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:265)
[10:40:23.577] {http--8080-244$1283730842} at
com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:273)
[10:40:23.577] {http--8080-244$1283730842} at
com.caucho.server.port.TcpConnection.run(TcpConnection.java:682)
[10:40:23.577] {http--8080-244$1283730842} at
com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:743)
[10:40:23.577] {http--8080-244$1283730842} at
com.caucho.util.ThreadPool$Item.run(ThreadPool.java:662)
[10:40:23.577] {http--8080-244$1283730842} at
java.lang.Thread.run(Thread.java:619)
[10:40:23.577] {http--8080-244$1283730842} Caused by:
org.apache.commons.fileupload.MultipartStream$MalformedStreamException: Stream
ended unexpectedly
[10:40:23.577] {http--8080-244$1283730842} at
org.apache.commons.fileupload.MultipartStream$ItemInputStream.makeAvailable(MultipartStream.java:982)
[10:40:23.577] {http--8080-244$1283730842} at
org.apache.commons.fileupload.MultipartStream$ItemInputStream.read(MultipartStream.java:886)
[10:40:23.577] {http--8080-244$1283730842} at
java.io.FilterInputStream.read(FilterInputStream.java:116)
[10:40:23.577] {http--8080-244$1283730842} at
org.apache.commons.fileupload.util.LimitedInputStream.read(LimitedInputStream.java:125)
[10:40:23.577] {http--8080-244$1283730842} at
java.io.FilterInputStream.read(FilterInputStream.java:90)
[10:40:23.577] {http--8080-244$1283730842} at
org.apache.commons.fileupload.util.Streams.copy(Streams.java:96)
[10:40:23.577] {http--8080-244$1283730842} at
org.apache.commons.fileupload.util.Streams.copy(Streams.java:66)
[10:40:23.577] {http--8080-244$1283730842} at
org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:366)
[10:40:23.577] {http--8080-244$1283730842} ... 12 more
Is it because of the size limit? the uploaded file size is 8KB.
Thanks!
--
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] (CHAIN-58) Update Chain Context interface to use K,V generics
[
https://issues.apache.org/jira/browse/CHAIN-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13161237#comment-13161237
]
Simone Tripodi commented on CHAIN-58:
-
Hi Elijah,
with a fresh checkout I finally have your patch applied :) Thanks for the hint!
I need 1-2 days before committing it because I have few minor
observations/modifications to apply, thanks for submitting this great
contribution!
Update Chain Context interface to use K,V generics
--
Key: CHAIN-58
URL: https://issues.apache.org/jira/browse/CHAIN-58
Project: Commons Chain
Issue Type: Improvement
Affects Versions: 2.0
Reporter: Elijah Zupancic
Fix For: 2.0
Attachments: chain-58.diff
As discussed in the mailing list, I am suggesting that we change the
definition of Context from:
{noformat}
public interface Context extends MapString, Object {
{noformat}
to:
{noformat}
public interface ContextK, V extends MapK, V {
{noformat}
--
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-716) BracketingNthOrderBrentSolver exceeds maxIterationCount while updating always the same boundary
[
https://issues.apache.org/jira/browse/MATH-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13161241#comment-13161241
]
Luc Maisonobe commented on MATH-716:
The following simple test reproduces the bad behavior with a trivial function:
{code}
@Test
public void testIssue716() {
BracketingNthOrderBrentSolver solver =
new BracketingNthOrderBrentSolver(1.0e-12, 1.0e-10, 0.0, 5);
UnivariateFunction sharpTurn = new UnivariateFunction() {
public double value(double x) {
return (2 * x + 1) / (1.0e9 * (x + 1));
}
};
double result = solver.solve(100, sharpTurn, -0.999, 30, 15,
AllowedSolution.RIGHT_SIDE);
Assert.assertEquals(0, sharpTurn.value(result),
solver.getFunctionValueAccuracy());
Assert.assertTrue(sharpTurn.value(result) = 0);
Assert.assertEquals(-0.5, result, 1.0e-10);
}
{code}
The test fails with TooManyEvaluationsException. In fact, only the right side
of the bracketing interval is updated and very slowly decreases from 15.0 to
14.999677603318897 while the left side of the bracketing interval is stuck at
-0.999.
BracketingNthOrderBrentSolver exceeds maxIterationCount while updating always
the same boundary
---
Key: MATH-716
URL: https://issues.apache.org/jira/browse/MATH-716
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Reporter: Pascal Parraud
Assignee: Luc Maisonobe
Priority: Minor
In some cases, the aging feature in BracketingNthOrderBrentSolver fails.
It attempts to balance the bracketing points by targeting a non-zero value
instead of the real root. However, the chosen target is too close too zero,
and the inverse polynomial approximation is always on the same side, thus
always updates the same bracket.
In the real used case for a large program, I had a bracket point xA =
12500.0, yA = 3.7e-16, agingA = 0, which is the (really good) estimate of the
zero on one side of the root and xB = 12500.03, yB = -7.0e-5, agingB = 97.
This shows that the bracketing interval is completely unbalanced, and we
never succeed to rebalance it as we always updates (xA, yA) and never updates
(xB, yB).
--
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] (DAEMON-230) Procrun Documentation
[ https://issues.apache.org/jira/browse/DAEMON-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved DAEMON-230. - Resolution: Fixed Thanks for the report; fixed in SVN Procrun Documentation - Key: DAEMON-230 URL: https://issues.apache.org/jira/browse/DAEMON-230 Project: Commons Daemon Issue Type: Bug Components: Procrun Reporter: David Haveman Priority: Minor the page http://commons.apache.org/daemon/procrun.html refrences the switch to add JVM options as --JvmOptions, but the examples show it as JvmOption: If a parameter is repeated, then normally the last value takes precedence. However some parameters can take multiple values - for example StartParams and JvmOption. If these parameters are prefixed with ++, then the value will be appended to the existing value. For example: --Startup=manual --Startup=auto --JvmOption=-Done=1 ++JvmOption=-Dtwo=2 -- 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] (DAEMON-230) Procrun Documentation
[ https://issues.apache.org/jira/browse/DAEMON-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13161283#comment-13161283 ] David Haveman commented on DAEMON-230: -- I am currently out of the office, i will be returning Friday December 2nd, 2011. Please contact Bob Falk or Patrick McCormack for assistance. Procrun Documentation - Key: DAEMON-230 URL: https://issues.apache.org/jira/browse/DAEMON-230 Project: Commons Daemon Issue Type: Bug Components: Procrun Reporter: David Haveman Priority: Minor the page http://commons.apache.org/daemon/procrun.html refrences the switch to add JVM options as --JvmOptions, but the examples show it as JvmOption: If a parameter is repeated, then normally the last value takes precedence. However some parameters can take multiple values - for example StartParams and JvmOption. If these parameters are prefixed with ++, then the value will be appended to the existing value. For example: --Startup=manual --Startup=auto --JvmOption=-Done=1 ++JvmOption=-Dtwo=2 -- 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] (MATH-716) BracketingNthOrderBrentSolver exceeds maxIterationCount while updating always the same boundary
[ https://issues.apache.org/jira/browse/MATH-716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-716. Resolution: Fixed Fix Version/s: 3.0 Fixed in subversion repository as of r1209307. Thanks for the report. BracketingNthOrderBrentSolver exceeds maxIterationCount while updating always the same boundary --- Key: MATH-716 URL: https://issues.apache.org/jira/browse/MATH-716 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Pascal Parraud Assignee: Luc Maisonobe Priority: Minor Fix For: 3.0 In some cases, the aging feature in BracketingNthOrderBrentSolver fails. It attempts to balance the bracketing points by targeting a non-zero value instead of the real root. However, the chosen target is too close too zero, and the inverse polynomial approximation is always on the same side, thus always updates the same bracket. In the real used case for a large program, I had a bracket point xA = 12500.0, yA = 3.7e-16, agingA = 0, which is the (really good) estimate of the zero on one side of the root and xB = 12500.03, yB = -7.0e-5, agingB = 97. This shows that the bracketing interval is completely unbalanced, and we never succeed to rebalance it as we always updates (xA, yA) and never updates (xB, yB). -- 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] (SCXML-163) Generics in API
Generics in API --- Key: SCXML-163 URL: https://issues.apache.org/jira/browse/SCXML-163 Project: Commons SCXML Issue Type: Improvement Affects Versions: 0.9 Reporter: Tomáš Zeman Priority: Minor Is it possible to add generics? There is no type safety at all. -- 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] (SCXML-163) Generics in API
[ https://issues.apache.org/jira/browse/SCXML-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Akolkar updated SCXML-163: Fix Version/s: 1.0 If you post a patch, its likely I'll take a look. Generics in API --- Key: SCXML-163 URL: https://issues.apache.org/jira/browse/SCXML-163 Project: Commons SCXML Issue Type: Improvement Affects Versions: 0.9 Reporter: Tomáš Zeman Priority: Minor Labels: api-change Fix For: 1.0 Is it possible to add generics? There is no type safety at all. -- 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
Re: [jira] [Created] (FILEUPLOAD-202) org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. Stream ended unexpectedly
In order to exclude thread-safety issue, did you try to run the jmeter test
with just one thread?
Sent from my mobile device, so please excuse typos and brevity.
Maurizio Cucchiara
Il giorno 01/dic/2011 20.13, tina (Created) (JIRA) j...@apache.org ha
scritto:
org.apache.commons.fileupload.FileUploadBase$IOFileUploadException:
Processing of multipart/form-data request failed. Stream ended unexpectedly
---
Key: FILEUPLOAD-202
URL: https://issues.apache.org/jira/browse/FILEUPLOAD-202
Project: Commons FileUpload
Issue Type: Bug
Affects Versions: 1.2.1
Reporter: tina
Fix For: 1.2.1
I used this one to write the servlet
http://www.servletworld.com/servlet-tutorials/servlet-file-upload-example.html
I can successfully upload the file through localhost, however, when I use
Jmeter to test the app server using 300 threads, it
will report this error:
[10:40:23.577] {http--8080-244$1283730842} WebApp[
http://localhost:8080/OrderFile] CommonsFileUploadServlet: Error
encountered while parsing the request
[10:40:23.577] {http--8080-244$1283730842}
org.apache.commons.fileupload.FileUploadBase$IOFileUploadException:
Processing of multipart/form-data request failed. Stream ended unexpectedly
[10:40:23.577] {http--8080-244$1283730842} at
org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:371)
[10:40:23.577] {http--8080-244$1283730842} at
org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:126)
[10:40:23.577] {http--8080-244$1283730842} at
CommonsFileUploadServlet.doPost(CommonsFileUploadServlet.java:66)
[10:40:23.577] {http--8080-244$1283730842} at
javax.servlet.http.HttpServlet.service(HttpServlet.java:153)
[10:40:23.577] {http--8080-244$1283730842} at
javax.servlet.http.HttpServlet.service(HttpServlet.java:91)
[10:40:23.577] {http--8080-244$1283730842} at
com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:103)
[10:40:23.577] {http--8080-244$1283730842} at
com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:187)
[10:40:23.577] {http--8080-244$1283730842} at
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:265)
[10:40:23.577] {http--8080-244$1283730842} at
com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:273)
[10:40:23.577] {http--8080-244$1283730842} at
com.caucho.server.port.TcpConnection.run(TcpConnection.java:682)
[10:40:23.577] {http--8080-244$1283730842} at
com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:743)
[10:40:23.577] {http--8080-244$1283730842} at
com.caucho.util.ThreadPool$Item.run(ThreadPool.java:662)
[10:40:23.577] {http--8080-244$1283730842} at
java.lang.Thread.run(Thread.java:619)
[10:40:23.577] {http--8080-244$1283730842} Caused by:
org.apache.commons.fileupload.MultipartStream$MalformedStreamException:
Stream ended unexpectedly
[10:40:23.577] {http--8080-244$1283730842} at
org.apache.commons.fileupload.MultipartStream$ItemInputStream.makeAvailable(MultipartStream.java:982)
[10:40:23.577] {http--8080-244$1283730842} at
org.apache.commons.fileupload.MultipartStream$ItemInputStream.read(MultipartStream.java:886)
[10:40:23.577] {http--8080-244$1283730842} at
java.io.FilterInputStream.read(FilterInputStream.java:116)
[10:40:23.577] {http--8080-244$1283730842} at
org.apache.commons.fileupload.util.LimitedInputStream.read(LimitedInputStream.java:125)
[10:40:23.577] {http--8080-244$1283730842} at
java.io.FilterInputStream.read(FilterInputStream.java:90)
[10:40:23.577] {http--8080-244$1283730842} at
org.apache.commons.fileupload.util.Streams.copy(Streams.java:96)
[10:40:23.577] {http--8080-244$1283730842} at
org.apache.commons.fileupload.util.Streams.copy(Streams.java:66)
[10:40:23.577] {http--8080-244$1283730842} at
org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:366)
[10:40:23.577] {http--8080-244$1283730842} ... 12 more
Is it because of the size limit? the uploaded file size is 8KB.
Thanks!
--
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] (FILEUPLOAD-202) org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. Stream ended unexpectedly
[
https://issues.apache.org/jira/browse/FILEUPLOAD-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13161442#comment-13161442
]
Maurizio Cucchiara commented on FILEUPLOAD-202:
---
In order to exclude a thread-safety issue, did you try to run the jmeter test
with just one thread?
org.apache.commons.fileupload.FileUploadBase$IOFileUploadException:
Processing of multipart/form-data request failed. Stream ended unexpectedly
---
Key: FILEUPLOAD-202
URL: https://issues.apache.org/jira/browse/FILEUPLOAD-202
Project: Commons FileUpload
Issue Type: Bug
Affects Versions: 1.2.1
Reporter: tina
Labels: fileupload
Fix For: 1.2.1
Original Estimate: 1h
Remaining Estimate: 1h
I used this one to write the servlet
http://www.servletworld.com/servlet-tutorials/servlet-file-upload-example.html
I can successfully upload the file through localhost, however, when I use
Jmeter to test the app server using 300 threads, it
will report this error:
[10:40:23.577] {http--8080-244$1283730842}
WebApp[http://localhost:8080/OrderFile] CommonsFileUploadServlet: Error
encountered while parsing the request
[10:40:23.577] {http--8080-244$1283730842}
org.apache.commons.fileupload.FileUploadBase$IOFileUploadException:
Processing of multipart/form-data request failed. Stream ended unexpectedly
[10:40:23.577] {http--8080-244$1283730842}at
org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:371)
[10:40:23.577] {http--8080-244$1283730842}at
org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:126)
[10:40:23.577] {http--8080-244$1283730842}at
CommonsFileUploadServlet.doPost(CommonsFileUploadServlet.java:66)
[10:40:23.577] {http--8080-244$1283730842}at
javax.servlet.http.HttpServlet.service(HttpServlet.java:153)
[10:40:23.577] {http--8080-244$1283730842}at
javax.servlet.http.HttpServlet.service(HttpServlet.java:91)
[10:40:23.577] {http--8080-244$1283730842}at
com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:103)
[10:40:23.577] {http--8080-244$1283730842}at
com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:187)
[10:40:23.577] {http--8080-244$1283730842}at
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:265)
[10:40:23.577] {http--8080-244$1283730842}at
com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:273)
[10:40:23.577] {http--8080-244$1283730842}at
com.caucho.server.port.TcpConnection.run(TcpConnection.java:682)
[10:40:23.577] {http--8080-244$1283730842}at
com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:743)
[10:40:23.577] {http--8080-244$1283730842}at
com.caucho.util.ThreadPool$Item.run(ThreadPool.java:662)
[10:40:23.577] {http--8080-244$1283730842}at
java.lang.Thread.run(Thread.java:619)
[10:40:23.577] {http--8080-244$1283730842} Caused by:
org.apache.commons.fileupload.MultipartStream$MalformedStreamException:
Stream ended unexpectedly
[10:40:23.577] {http--8080-244$1283730842}at
org.apache.commons.fileupload.MultipartStream$ItemInputStream.makeAvailable(MultipartStream.java:982)
[10:40:23.577] {http--8080-244$1283730842}at
org.apache.commons.fileupload.MultipartStream$ItemInputStream.read(MultipartStream.java:886)
[10:40:23.577] {http--8080-244$1283730842}at
java.io.FilterInputStream.read(FilterInputStream.java:116)
[10:40:23.577] {http--8080-244$1283730842}at
org.apache.commons.fileupload.util.LimitedInputStream.read(LimitedInputStream.java:125)
[10:40:23.577] {http--8080-244$1283730842}at
java.io.FilterInputStream.read(FilterInputStream.java:90)
[10:40:23.577] {http--8080-244$1283730842}at
org.apache.commons.fileupload.util.Streams.copy(Streams.java:96)
[10:40:23.577] {http--8080-244$1283730842}at
org.apache.commons.fileupload.util.Streams.copy(Streams.java:66)
[10:40:23.577] {http--8080-244$1283730842}at
org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:366)
[10:40:23.577] {http--8080-244$1283730842}... 12 more
Is it because of the size limit? the uploaded file size is 8KB.
Thanks!
--
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] (FILEUPLOAD-202) org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. Stream ended unexpectedly
[
https://issues.apache.org/jira/browse/FILEUPLOAD-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13161452#comment-13161452
]
tina commented on FILEUPLOAD-202:
-
Yes. I did. only one thread works ok. If I set the threads count to 250, it
works ok. But if I set count to 300,it will report that error.
org.apache.commons.fileupload.FileUploadBase$IOFileUploadException:
Processing of multipart/form-data request failed. Stream ended unexpectedly
---
Key: FILEUPLOAD-202
URL: https://issues.apache.org/jira/browse/FILEUPLOAD-202
Project: Commons FileUpload
Issue Type: Bug
Affects Versions: 1.2.1
Reporter: tina
Labels: fileupload
Fix For: 1.2.1
Original Estimate: 1h
Remaining Estimate: 1h
I used this one to write the servlet
http://www.servletworld.com/servlet-tutorials/servlet-file-upload-example.html
I can successfully upload the file through localhost, however, when I use
Jmeter to test the app server using 300 threads, it
will report this error:
[10:40:23.577] {http--8080-244$1283730842}
WebApp[http://localhost:8080/OrderFile] CommonsFileUploadServlet: Error
encountered while parsing the request
[10:40:23.577] {http--8080-244$1283730842}
org.apache.commons.fileupload.FileUploadBase$IOFileUploadException:
Processing of multipart/form-data request failed. Stream ended unexpectedly
[10:40:23.577] {http--8080-244$1283730842}at
org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:371)
[10:40:23.577] {http--8080-244$1283730842}at
org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:126)
[10:40:23.577] {http--8080-244$1283730842}at
CommonsFileUploadServlet.doPost(CommonsFileUploadServlet.java:66)
[10:40:23.577] {http--8080-244$1283730842}at
javax.servlet.http.HttpServlet.service(HttpServlet.java:153)
[10:40:23.577] {http--8080-244$1283730842}at
javax.servlet.http.HttpServlet.service(HttpServlet.java:91)
[10:40:23.577] {http--8080-244$1283730842}at
com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:103)
[10:40:23.577] {http--8080-244$1283730842}at
com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:187)
[10:40:23.577] {http--8080-244$1283730842}at
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:265)
[10:40:23.577] {http--8080-244$1283730842}at
com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:273)
[10:40:23.577] {http--8080-244$1283730842}at
com.caucho.server.port.TcpConnection.run(TcpConnection.java:682)
[10:40:23.577] {http--8080-244$1283730842}at
com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:743)
[10:40:23.577] {http--8080-244$1283730842}at
com.caucho.util.ThreadPool$Item.run(ThreadPool.java:662)
[10:40:23.577] {http--8080-244$1283730842}at
java.lang.Thread.run(Thread.java:619)
[10:40:23.577] {http--8080-244$1283730842} Caused by:
org.apache.commons.fileupload.MultipartStream$MalformedStreamException:
Stream ended unexpectedly
[10:40:23.577] {http--8080-244$1283730842}at
org.apache.commons.fileupload.MultipartStream$ItemInputStream.makeAvailable(MultipartStream.java:982)
[10:40:23.577] {http--8080-244$1283730842}at
org.apache.commons.fileupload.MultipartStream$ItemInputStream.read(MultipartStream.java:886)
[10:40:23.577] {http--8080-244$1283730842}at
java.io.FilterInputStream.read(FilterInputStream.java:116)
[10:40:23.577] {http--8080-244$1283730842}at
org.apache.commons.fileupload.util.LimitedInputStream.read(LimitedInputStream.java:125)
[10:40:23.577] {http--8080-244$1283730842}at
java.io.FilterInputStream.read(FilterInputStream.java:90)
[10:40:23.577] {http--8080-244$1283730842}at
org.apache.commons.fileupload.util.Streams.copy(Streams.java:96)
[10:40:23.577] {http--8080-244$1283730842}at
org.apache.commons.fileupload.util.Streams.copy(Streams.java:66)
[10:40:23.577] {http--8080-244$1283730842}at
org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:366)
[10:40:23.577] {http--8080-244$1283730842}... 12 more
Is it because of the size limit? the uploaded file size is 8KB.
Thanks!
--
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] (FILEUPLOAD-202) org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. Stream ended unexpectedly
[
https://issues.apache.org/jira/browse/FILEUPLOAD-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13161467#comment-13161467
]
Maurizio Cucchiara commented on FILEUPLOAD-202:
---
It could be interesting to know what application server you are using (Tomcat,
JBoss, etc.)
org.apache.commons.fileupload.FileUploadBase$IOFileUploadException:
Processing of multipart/form-data request failed. Stream ended unexpectedly
---
Key: FILEUPLOAD-202
URL: https://issues.apache.org/jira/browse/FILEUPLOAD-202
Project: Commons FileUpload
Issue Type: Bug
Affects Versions: 1.2.1
Reporter: tina
Labels: fileupload
Fix For: 1.2.1
Original Estimate: 1h
Remaining Estimate: 1h
I used this one to write the servlet
http://www.servletworld.com/servlet-tutorials/servlet-file-upload-example.html
I can successfully upload the file through localhost, however, when I use
Jmeter to test the app server using 300 threads, it
will report this error:
[10:40:23.577] {http--8080-244$1283730842}
WebApp[http://localhost:8080/OrderFile] CommonsFileUploadServlet: Error
encountered while parsing the request
[10:40:23.577] {http--8080-244$1283730842}
org.apache.commons.fileupload.FileUploadBase$IOFileUploadException:
Processing of multipart/form-data request failed. Stream ended unexpectedly
[10:40:23.577] {http--8080-244$1283730842}at
org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:371)
[10:40:23.577] {http--8080-244$1283730842}at
org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:126)
[10:40:23.577] {http--8080-244$1283730842}at
CommonsFileUploadServlet.doPost(CommonsFileUploadServlet.java:66)
[10:40:23.577] {http--8080-244$1283730842}at
javax.servlet.http.HttpServlet.service(HttpServlet.java:153)
[10:40:23.577] {http--8080-244$1283730842}at
javax.servlet.http.HttpServlet.service(HttpServlet.java:91)
[10:40:23.577] {http--8080-244$1283730842}at
com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:103)
[10:40:23.577] {http--8080-244$1283730842}at
com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:187)
[10:40:23.577] {http--8080-244$1283730842}at
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:265)
[10:40:23.577] {http--8080-244$1283730842}at
com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:273)
[10:40:23.577] {http--8080-244$1283730842}at
com.caucho.server.port.TcpConnection.run(TcpConnection.java:682)
[10:40:23.577] {http--8080-244$1283730842}at
com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:743)
[10:40:23.577] {http--8080-244$1283730842}at
com.caucho.util.ThreadPool$Item.run(ThreadPool.java:662)
[10:40:23.577] {http--8080-244$1283730842}at
java.lang.Thread.run(Thread.java:619)
[10:40:23.577] {http--8080-244$1283730842} Caused by:
org.apache.commons.fileupload.MultipartStream$MalformedStreamException:
Stream ended unexpectedly
[10:40:23.577] {http--8080-244$1283730842}at
org.apache.commons.fileupload.MultipartStream$ItemInputStream.makeAvailable(MultipartStream.java:982)
[10:40:23.577] {http--8080-244$1283730842}at
org.apache.commons.fileupload.MultipartStream$ItemInputStream.read(MultipartStream.java:886)
[10:40:23.577] {http--8080-244$1283730842}at
java.io.FilterInputStream.read(FilterInputStream.java:116)
[10:40:23.577] {http--8080-244$1283730842}at
org.apache.commons.fileupload.util.LimitedInputStream.read(LimitedInputStream.java:125)
[10:40:23.577] {http--8080-244$1283730842}at
java.io.FilterInputStream.read(FilterInputStream.java:90)
[10:40:23.577] {http--8080-244$1283730842}at
org.apache.commons.fileupload.util.Streams.copy(Streams.java:96)
[10:40:23.577] {http--8080-244$1283730842}at
org.apache.commons.fileupload.util.Streams.copy(Streams.java:66)
[10:40:23.577] {http--8080-244$1283730842}at
org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:366)
[10:40:23.577] {http--8080-244$1283730842}... 12 more
Is it because of the size limit? the uploaded file size is 8KB.
Thanks!
--
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
