[jira] [Comment Edited] (POOL-340) borrowObject is stuck, if create fails
[
https://issues.apache.org/jira/browse/POOL-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16459125#comment-16459125
]
Phil Steitz edited comment on POOL-340 at 4/30/18 9:57 PM:
---
Another workaround-ish idea is to achieve the effect of propagation of the
swallowed exception on returnObject by configuring a
SwallowedExceptionListener. See
BaseGenericObjectPool#setSwallowedExceptionListener.
Two more notes on this:
# If threads are waiting on borrow requests and there are no idle instances
available and a return fails validation, the current code does try to create a
new instance to "replace" the one failing validation. If that create fails
with an exception, the failure can be picked up with a
SwallowedExceptionListener.
# Another workaround if you are OK with the slight additional overhead would
be to set timeBetweenEvictionRunsMillis to a positive number (so the
maintenance thread runs) and set minIdle to 1. Then each
timeBetweenEvictionRunsMillis ms, the maintenance thread will run and it will
try to create an instance if there are none idle (regardless of whether or not
there are take waiters).
was (Author: psteitz):
Another workaround-ish idea is to achieve the effect of propagation of the
swallowed exception on returnObject by configuring a
SwallowedExceptionListener. See
BaseGenericObjectPool#setSwallowedExceptionListener.
One more note on this. If threads are waiting on borrow requests and there are
no idle instances available and a return fails validation, the current code
does try to create a new instance to "replace" the one failing validation. If
that create fails with an exception, the failure can be picked up with a
SwallowedExceptionListener.
> borrowObject is stuck, if create fails
> --
>
> Key: POOL-340
> URL: https://issues.apache.org/jira/browse/POOL-340
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.4, 2.4.1, 2.4.2, 2.4.3, 2.5.0
>Reporter: Pavel Kolesov
>Priority: Critical
>
> After changes in 2.4.3 there is a high chance of a scenario, in which
> borrowObject waits infinitely, if create fails or no one calls a create.
> {noformat}
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x83cfd978> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> org.apache.commons.pool2.impl.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:583)
> at
> org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:442)
> at
> org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:363)
> {noformat}
> If pool is exhausted, when borrowObject tries to get idle object, it waits
> for new object to be created.
> If all objects are returned to pool invalid and destroyed, and it is
> impossible to create a new one, borrowObject will not return.
> Even if afterwards it is becomes possible to crate a new object but no one
> creates it, borrowObject will not return either.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (POOL-340) borrowObject is stuck, if create fails
[
https://issues.apache.org/jira/browse/POOL-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16459125#comment-16459125
]
Phil Steitz commented on POOL-340:
--
Another workaround-ish idea is to achieve the effect of propagation of the
swallowed exception on returnObject by configuring a
SwallowedExceptionListener. See
BaseGenericObjectPool#setSwallowedExceptionListener.
One more note on this. If threads are waiting on borrow requests and there are
no idle instances available and a return fails validation, the current code
does try to create a new instance to "replace" the one failing validation. If
that create fails with an exception, the failure can be picked up with a
SwallowedExceptionListener.
> borrowObject is stuck, if create fails
> --
>
> Key: POOL-340
> URL: https://issues.apache.org/jira/browse/POOL-340
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.4, 2.4.1, 2.4.2, 2.4.3, 2.5.0
>Reporter: Pavel Kolesov
>Priority: Critical
>
> After changes in 2.4.3 there is a high chance of a scenario, in which
> borrowObject waits infinitely, if create fails or no one calls a create.
> {noformat}
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x83cfd978> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> org.apache.commons.pool2.impl.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:583)
> at
> org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:442)
> at
> org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:363)
> {noformat}
> If pool is exhausted, when borrowObject tries to get idle object, it waits
> for new object to be created.
> If all objects are returned to pool invalid and destroyed, and it is
> impossible to create a new one, borrowObject will not return.
> Even if afterwards it is becomes possible to crate a new object but no one
> creates it, borrowObject will not return either.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-663) SftpClientFactory does not pass proxyUser or proxyPassword to non-PROXY_STREAM types
[ https://issues.apache.org/jira/browse/VFS-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16459108#comment-16459108 ] Will Buck commented on VFS-663: --- Link to the PR of my forked branch to trunk: https://github.com/apache/commons-vfs/pull/37 > SftpClientFactory does not pass proxyUser or proxyPassword to > non-PROXY_STREAM types > > > Key: VFS-663 > URL: https://issues.apache.org/jira/browse/VFS-663 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.1, 2.2 >Reporter: Will Buck >Priority: Major > > I've discovered that while version 2.1 added `setProxyUser` and > `setProxyPassword` to ` > SftpFileSystemConfigBuilder`, these properties are only read via > `getProxyUser` and `getProxyPassword` for the `ProxyType` `PROXY_STREAM`, but > not for the other two supported proxy types (`PROXY_HTTP` and `PROXY_SOCKS5`) > The fix for this is reasonably straightforward, as both > `com.jcraft.jsch.ProxyHTTP` and `com.jcraft.jsch.ProxySOCKS5` support a > `setUserPasswd` function and utilization of a username and password for > connection. > I've created a fork with the changes I would propose to fix the bug, but am > open to changes with it if I have missed any style guidelines. I am unsure > how to go about writing a clear test for this and would love some assistance > in doing so, however I have built the fork and imported it into a project my > client is working on, and it seems to have solved the issue we were having > (an exception was being thrown, 'Proxy Authentication Required'). > I would welcome feedback and hope to resolve this issue so that other users > of the library will be able to connect to authenticated proxies easily! > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (VFS-663) SftpClientFactory does not pass proxyUser or proxyPassword to non-PROXY_STREAM types
Will Buck created VFS-663: - Summary: SftpClientFactory does not pass proxyUser or proxyPassword to non-PROXY_STREAM types Key: VFS-663 URL: https://issues.apache.org/jira/browse/VFS-663 Project: Commons VFS Issue Type: Bug Affects Versions: 2.2, 2.1 Reporter: Will Buck I've discovered that while version 2.1 added `setProxyUser` and `setProxyPassword` to ` SftpFileSystemConfigBuilder`, these properties are only read via `getProxyUser` and `getProxyPassword` for the `ProxyType` `PROXY_STREAM`, but not for the other two supported proxy types (`PROXY_HTTP` and `PROXY_SOCKS5`) The fix for this is reasonably straightforward, as both `com.jcraft.jsch.ProxyHTTP` and `com.jcraft.jsch.ProxySOCKS5` support a `setUserPasswd` function and utilization of a username and password for connection. I've created a fork with the changes I would propose to fix the bug, but am open to changes with it if I have missed any style guidelines. I am unsure how to go about writing a clear test for this and would love some assistance in doing so, however I have built the fork and imported it into a project my client is working on, and it seems to have solved the issue we were having (an exception was being thrown, 'Proxy Authentication Required'). I would welcome feedback and hope to resolve this issue so that other users of the library will be able to connect to authenticated proxies easily! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NUMBERS-68) Numbers are "value" objects
[
https://issues.apache.org/jira/browse/NUMBERS-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16459064#comment-16459064
]
Gilles commented on NUMBERS-68:
---
Classes {{Quaternion}} and {{Fraction}} should also be checked.
> Numbers are "value" objects
> ---
>
> Key: NUMBERS-68
> URL: https://issues.apache.org/jira/browse/NUMBERS-68
> Project: Commons Numbers
> Issue Type: Task
> Components: complex, fraction, quaternion
>Reporter: Gilles
>Priority: Major
> Labels: api, design, gsoc2018
> Fix For: 1.0
>
>
> Consider making _value_ classes {{final}}.
> See http://blog.joda.org/2014/03/valjos-value-java-objects.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MATH-1233) Uncommon wilcoxon signed-rank p-values
[ https://issues.apache.org/jira/browse/MATH-1233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16458905#comment-16458905 ] Phil Steitz commented on MATH-1233: --- A first attempt at a fix for this was implemented in [this issue|https://github.com/Hipparchus-Math/hipparchus/issues/37] in Hipparchus. Current code there discards tied pairs, which would result in an exception if all pairs are tied. I agree that it should be configurable how ties are handled and the scipy alternatives make sense. Hipparchus currently implements the simplest one, what scipy calls "wilcox." Another problem with the current [math] implementation is that the continuity correction is not applied correctly. That was fixed in the Hipparchus patch, which should backport easily. > Uncommon wilcoxon signed-rank p-values > -- > > Key: MATH-1233 > URL: https://issues.apache.org/jira/browse/MATH-1233 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.5 >Reporter: Icaro Cavalcante Dourado >Assignee: Rob Tompkins >Priority: Major > Fix For: 4.0 > > Attachments: MATH-1233-test.patch > > > This implementation in WilcoxonSignedRankTest looks weird. For equal vectors, > the correct pValue should be 1, because it is the probability of the vectors > to come from same population. > On the opposite, this implementation returns ~0 for equal vectors. So we need > to analyze the returned pValue > significanceLevel to reject H0 hypothesis, > while in R and many others tools we perform the opposite: pValue <= > significanceLevel gives us an argument to reject null hypothesis. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MATH-1453) Mann-Whitney U Test returns maximum of U1 and U2
[
https://issues.apache.org/jira/browse/MATH-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16458890#comment-16458890
]
Phil Steitz commented on MATH-1453:
---
The minimum value is what should be reported as the value of the statistic.
That is in fact what is used by the code to estimate p-values. The p-value
computation also suffers from some accuracy issues. First, no continuity
correction is applied when computing the normal approximation. Second (as
noted in the javadoc), nothing is done to adjust the variance in the presence
of ties in the data. The patch applied to fix [this
issue|https://github.com/Hipparchus-Math/hipparchus/issues/38] in Hipparchus
could be fairly easily backported to current [math] code. The patch there also
includes exact computation of p-values for very small samples. Patches welcome
there too, of course.
> Mann-Whitney U Test returns maximum of U1 and U2
>
>
> Key: MATH-1453
> URL: https://issues.apache.org/jira/browse/MATH-1453
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Nikos Katsipoulakis
>Priority: Critical
>
> Currently, I need to use Mann-Whitney U Test and I figured out that Apache
> Commons Math has it implemented. After consulting the
> [Wiki|https://en.wikipedia.org/wiki/Mann%E2%80%93Whitney_U_test] presented in
> the Java Doc, it indicates that the U statistic of this test is the minimum
> among U1 and U2. However, when I look into Apache Commons Math
> {{MannWhitneyUTest.mannWhitneyU()}} method, it returns the maximum of U1 and
> U2. In fact, the code of this method is the following:
>
> {code:java}
> public double mannWhitneyU(double[] x, double[] y) throws
> NullArgumentException, NoDataException {
> this.ensureDataConformance(x, y);
> double[] z = this.concatenateSamples(x, y);
> double[] ranks = this.naturalRanking.rank(z);
> double sumRankX = 0.0D;
> for(int i = 0; i < x.length; ++i) {
> sumRankX += ranks[i];
> }
> double U1 = sumRankX - (double)((long)x.length * (long)(x.length + 1) / 2L);
> double U2 = (double)((long)x.length * (long)y.length) - U1;
> return FastMath.max(U1, U2);
> }
> {code}
> Also, in the Java Doc it is stated that the maximum value of U1 and U2 is
> returned.
>
> My question is why Apache Commons returns the maximum of those two values,
> whereas all other sources I found online indicate returning the minimum? If
> this is not wrong, then shouldn't the Java Doc be updated to include a source
> that justifies that the maximum U should be returned.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (COMPRESS-445) Zip Bomb Detection
[
https://issues.apache.org/jira/browse/COMPRESS-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-445.
-
Resolution: Fixed
For {{SevenZFile}} I solved it by providing an explicit method that provides
the statistics for the current entry.
> Zip Bomb Detection
> --
>
> Key: COMPRESS-445
> URL: https://issues.apache.org/jira/browse/COMPRESS-445
> Project: Commons Compress
> Issue Type: Improvement
> Components: Archivers
>Reporter: PJ Fanning
>Priority: Major
> Labels: zip
> Fix For: 1.17
>
> Attachments: InputStreamStatistics.patch.gz
>
>
> It would be a nice feature if ZipFile had support for detecting Zip Bombs.
> Apache Poi has an implementation based on the java util ZipFile but this
> relies on Reflection and changes in Java 10 mean this code will not work in
> that version.
> [https://github.com/apache/poi/blob/trunk/src/ooxml/java/org/apache/poi/openxml4j/util/ZipSecureFile.java]
> One option would be to add equivalent change support in commons-compress and
> for Poi to use the commons version.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NUMBERS-68) Numbers are "value" objects
[
https://issues.apache.org/jira/browse/NUMBERS-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16458580#comment-16458580
]
Eric Barnhill commented on NUMBERS-68:
--
I believe the class now meets the VALJO criteria and this can be closed.
> Numbers are "value" objects
> ---
>
> Key: NUMBERS-68
> URL: https://issues.apache.org/jira/browse/NUMBERS-68
> Project: Commons Numbers
> Issue Type: Task
> Components: complex, fraction, quaternion
>Reporter: Gilles
>Priority: Major
> Labels: api, design, gsoc2018
> Fix For: 1.0
>
>
> Consider making _value_ classes {{final}}.
> See http://blog.joda.org/2014/03/valjos-value-java-objects.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NUMBERS-68) Numbers are "value" objects
[
https://issues.apache.org/jira/browse/NUMBERS-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16458534#comment-16458534
]
Gilles commented on NUMBERS-68:
---
Commit 65b5d844c4f1258dfac41fb595906854ca83a9be should hopefully fix it.
> Numbers are "value" objects
> ---
>
> Key: NUMBERS-68
> URL: https://issues.apache.org/jira/browse/NUMBERS-68
> Project: Commons Numbers
> Issue Type: Task
> Components: complex, fraction, quaternion
>Reporter: Gilles
>Priority: Major
> Labels: api, design, gsoc2018
> Fix For: 1.0
>
>
> Consider making _value_ classes {{final}}.
> See http://blog.joda.org/2014/03/valjos-value-java-objects.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NUMBERS-68) Numbers are "value" objects
[
https://issues.apache.org/jira/browse/NUMBERS-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16458467#comment-16458467
]
Eric Barnhill commented on NUMBERS-68:
--
I get a warning about serial versionID in ComplexParsingException.
> Numbers are "value" objects
> ---
>
> Key: NUMBERS-68
> URL: https://issues.apache.org/jira/browse/NUMBERS-68
> Project: Commons Numbers
> Issue Type: Task
> Components: complex, fraction, quaternion
>Reporter: Gilles
>Priority: Major
> Labels: api, design, gsoc2018
> Fix For: 1.0
>
>
> Consider making _value_ classes {{final}}.
> See http://blog.joda.org/2014/03/valjos-value-java-objects.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (NUMBERS-60) Check Javadoc with respect to NaN
[
https://issues.apache.org/jira/browse/NUMBERS-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Barnhill resolved NUMBERS-60.
--
Resolution: Fixed
The NaN issue was resolved and the multiplication / division issue was moved to
another ticket.
> Check Javadoc with respect to NaN
> -
>
> Key: NUMBERS-60
> URL: https://issues.apache.org/jira/browse/NUMBERS-60
> Project: Commons Numbers
> Issue Type: Task
> Components: complex
>Reporter: Gilles
>Priority: Minor
> Labels: API, javadoc
> Fix For: 1.0
>
>
> See e.g. the doc for method {{negate}}:
> {code}
> /**
> * Returns a {@code Complex} whose value is {@code (-this)}.
> * Returns {@code NaN} if either real or imaginary
> * part of this complex number is {@code Double.NaN}.
> *
> * @return {@code -this}.
> */
> public Complex negate() {
> return new Complex(-real, -imaginary);
> }
> {code}
> The "NaN" advertized in the the Javadoc seems to refer to the {{Complex.NaN}}
> field, but {{negate}} is able to construct instances for which the contract
> of method {{equals(Object)}} will be broken.
> As a related issue, I would make the {{NaN}} field "private" (and rename it
> "NAN" to avoid the CheckStyle warning); users who need to check for (any
> combination of) NaN should use the {{isNaN()}} method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (NUMBERS-64) Method "norm()"
[
https://issues.apache.org/jira/browse/NUMBERS-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Barnhill resolved NUMBERS-64.
--
Resolution: Fixed
> Method "norm()"
> ---
>
> Key: NUMBERS-64
> URL: https://issues.apache.org/jira/browse/NUMBERS-64
> Project: Commons Numbers
> Issue Type: Task
> Components: complex
>Reporter: Gilles
>Priority: Minor
> Labels: API
> Fix For: 1.0
>
>
> Method is trivial, not used within the class, and [not
> standard|https://math.stackexchange.com/questions/285398/what-is-the-norm-of-a-complex-number].
> Should we perhaps remove it?
> However, if keeping it to mimic the C++ standard library, the computation
> should be implemented directly; currently, it calls method {{abs()}} which
> entails many unnecessary checks and operations.
> Javadoc links to an unrelated page.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (NUMBERS-53) Factory methods are not "static"
[
https://issues.apache.org/jira/browse/NUMBERS-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Barnhill resolved NUMBERS-53.
--
Resolution: Fixed
> Factory methods are not "static"
>
>
> Key: NUMBERS-53
> URL: https://issues.apache.org/jira/browse/NUMBERS-53
> Project: Commons Numbers
> Issue Type: Bug
> Components: complex
>Reporter: Gilles
>Priority: Blocker
> Fix For: 1.0
>
>
> * {{polar(x,y)}}
> * {{cis\(x\)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (LANG-1391) Improve Javadoc for StringUtils.isAnyEmpty(null)
[
https://issues.apache.org/jira/browse/LANG-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Schumacher updated LANG-1391:
Priority: Minor (was: Major)
> Improve Javadoc for StringUtils.isAnyEmpty(null)
> -
>
> Key: LANG-1391
> URL: https://issues.apache.org/jira/browse/LANG-1391
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.7
>Reporter: Sauro Matulli
>Priority: Minor
> Fix For: 3.8
>
>
>
> The StringUtils.isAnyEmpty(null) method returns an incorrect value from what
> is specified in the javadoc.
> JAVADOC: StringUtils.isAnyEmpty(null) = true
> Test: System.out.println("" + StringUtils.isAnyEmpty(null)); --> false
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (POOL-340) borrowObject is stuck, if create fails
[
https://issues.apache.org/jira/browse/POOL-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16458401#comment-16458401
]
Pavel Kolesov commented on POOL-340:
[~psteitz], thank you for the workaround idea. Can't really argue with your
view of the problem, just adding one more thing to notice - if factory is
"down" borrowObject can either stuck or propagate the factory's exception.
> borrowObject is stuck, if create fails
> --
>
> Key: POOL-340
> URL: https://issues.apache.org/jira/browse/POOL-340
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.4, 2.4.1, 2.4.2, 2.4.3, 2.5.0
>Reporter: Pavel Kolesov
>Priority: Critical
>
> After changes in 2.4.3 there is a high chance of a scenario, in which
> borrowObject waits infinitely, if create fails or no one calls a create.
> {noformat}
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x83cfd978> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> org.apache.commons.pool2.impl.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:583)
> at
> org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:442)
> at
> org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:363)
> {noformat}
> If pool is exhausted, when borrowObject tries to get idle object, it waits
> for new object to be created.
> If all objects are returned to pool invalid and destroyed, and it is
> impossible to create a new one, borrowObject will not return.
> Even if afterwards it is becomes possible to crate a new object but no one
> creates it, borrowObject will not return either.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (POOL-340) borrowObject is stuck, if create fails
[
https://issues.apache.org/jira/browse/POOL-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16458398#comment-16458398
]
Pavel Kolesov edited comment on POOL-340 at 4/30/18 8:32 AM:
-
[~garydgregory], thank you for your response and sorry for the delay. I've come
up with such test (not the shortest one, unfortunately):
{code}
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicBoolean;
import org.apache.commons.pool2.BasePooledObjectFactory;
import org.apache.commons.pool2.PooledObject;
import org.junit.Assert;
import org.junit.Ignore;
import org.junit.Test;
public class GenericObjectPoolTest {
@Test(timeout = 10_000)
@Ignore("Doesn't pass, waiting for
https://issues.apache.org/jira/browse/POOL-340;)
public void testBorrowObjectStuck() {
SingleObjectFactory factory = new SingleObjectFactory();
GenericObjectPoolConfig config = new GenericObjectPoolConfig();
config.setMaxIdle(1);
config.setMaxTotal(1);
config.setBlockWhenExhausted(true);
config.setMinIdle(0);
config.setTestOnBorrow(true);
config.setTestOnReturn(true);
config.setTestWhileIdle(false);
config.setTimeBetweenEvictionRunsMillis(-1);
config.setMinEvictableIdleTimeMillis(-1);
config.setSoftMinEvictableIdleTimeMillis(-1);
config.setMaxWaitMillis(-1);
GenericObjectPool pool = new GenericObjectPool<>(factory,
config);
AtomicBoolean failed = new AtomicBoolean();
CountDownLatch barrier = new CountDownLatch(1);
Thread thread1 = new Thread(new WinnerRunnable(pool, barrier, failed));
thread1.start();
// wait for object to be created
while(!factory.created.get()) {
sleepIgnoreException(5);
}
// now borrow
barrier.countDown();
try {
pool.borrowObject();
} catch (Exception e) {
e.printStackTrace();
}
Assert.assertFalse(failed.get());
}
private static class SingleObjectFactory extends
BasePooledObjectFactory {
private final AtomicBoolean created = new AtomicBoolean();
private final AtomicBoolean validated = new AtomicBoolean();
@Override
public Object create() throws Exception {
if (!created.getAndSet(true)) {
return new Object();
}
throw new Exception("Already created");
}
@Override
public PooledObject wrap(Object obj) {
return new DefaultPooledObject<>(new Object());
}
@Override
public boolean validateObject(PooledObject p) {
// return valid once
if (!validated.getAndSet(true)) {
return true;
}
System.out.println("invalid");
return false;
}
}
private static class WinnerRunnable implements Runnable {
private final GenericObjectPool pool;
private final AtomicBoolean failed;
private final CountDownLatch barrier;
private WinnerRunnable(GenericObjectPool pool, CountDownLatch
barrier, AtomicBoolean failed) {
this.pool = pool;
this.failed = failed;
this.barrier = barrier;
}
@Override
public void run() {
try {
Object obj = pool.borrowObject();
// wait for another thread to start borrowObject
if (!barrier.await(5, TimeUnit.SECONDS)) {
System.out.println("Timeout waiting");
failed.set(true);
} else {
// just to make sure, borrowObject has started waiting on
queue
sleepIgnoreException(1000);
}
pool.returnObject(obj);
} catch (Exception e) {
failed.set(true);
e.printStackTrace();
}
}
}
private static void sleepIgnoreException(long millis) {
try {
Thread.sleep(millis);
} catch(Throwable e) {
// ignore
}
}
}
{code}
was (Author: pavelk):
[~garydgregory], thank you for your response and sorry for the delay. I've come
up with such test (not the shortest one, unfortunately):
{code}
package org.apache.commons.pool2.impl;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicBoolean;
import org.apache.commons.pool2.BasePooledObjectFactory;
import org.apache.commons.pool2.PooledObject;
import org.junit.Assert;
import org.junit.Ignore;
import org.junit.Test;
public class GenericObjectPoolTest {
@Test(timeout = 10_000)
[jira] [Commented] (POOL-340) borrowObject is stuck, if create fails
[
https://issues.apache.org/jira/browse/POOL-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16458398#comment-16458398
]
Pavel Kolesov commented on POOL-340:
[~garydgregory], thank you for your response and sorry for the delay. I've come
up with such test (not the shortest one, unfortunately):
{code}
package org.apache.commons.pool2.impl;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicBoolean;
import org.apache.commons.pool2.BasePooledObjectFactory;
import org.apache.commons.pool2.PooledObject;
import org.junit.Assert;
import org.junit.Ignore;
import org.junit.Test;
public class GenericObjectPoolTest {
@Test(timeout = 10_000)
@Ignore("Doesn't pass, waiting for
https://issues.apache.org/jira/browse/POOL-340;)
public void testBorrowObjectStuck() {
SingleObjectFactory factory = new SingleObjectFactory();
GenericObjectPoolConfig config = new GenericObjectPoolConfig();
config.setMaxIdle(1);
config.setMaxTotal(1);
config.setBlockWhenExhausted(true);
config.setMinIdle(0);
config.setTestOnBorrow(true);
config.setTestOnReturn(true);
config.setTestWhileIdle(false);
config.setTimeBetweenEvictionRunsMillis(-1);
config.setMinEvictableIdleTimeMillis(-1);
config.setSoftMinEvictableIdleTimeMillis(-1);
config.setMaxWaitMillis(-1);
GenericObjectPool pool = new GenericObjectPool<>(factory,
config);
AtomicBoolean failed = new AtomicBoolean();
CountDownLatch barrier = new CountDownLatch(1);
Thread thread1 = new Thread(new WinnerRunnable(pool, barrier, failed));
thread1.start();
// wait for object to be created
while(!factory.created.get()) {
sleepIgnoreException(5);
}
// now borrow
barrier.countDown();
try {
pool.borrowObject();
} catch (Exception e) {
e.printStackTrace();
}
Assert.assertFalse(failed.get());
}
private static class SingleObjectFactory extends
BasePooledObjectFactory {
private final AtomicBoolean created = new AtomicBoolean();
private final AtomicBoolean validated = new AtomicBoolean();
@Override
public Object create() throws Exception {
if (!created.getAndSet(true)) {
return new Object();
}
throw new Exception("Already created");
}
@Override
public PooledObject wrap(Object obj) {
return new DefaultPooledObject<>(new Object());
}
@Override
public boolean validateObject(PooledObject p) {
// return valid once
if (!validated.getAndSet(true)) {
return true;
}
System.out.println("invalid");
return false;
}
}
private static class WinnerRunnable implements Runnable {
private final GenericObjectPool pool;
private final AtomicBoolean failed;
private final CountDownLatch barrier;
private WinnerRunnable(GenericObjectPool pool, CountDownLatch
barrier, AtomicBoolean failed) {
this.pool = pool;
this.failed = failed;
this.barrier = barrier;
}
@Override
public void run() {
try {
Object obj = pool.borrowObject();
// wait for another thread to start borrowObject
if (!barrier.await(5, TimeUnit.SECONDS)) {
System.out.println("Timeout waiting");
failed.set(true);
} else {
// just to make sure, borrowObject has started waiting on
queue
sleepIgnoreException(1000);
}
pool.returnObject(obj);
} catch (Exception e) {
failed.set(true);
e.printStackTrace();
}
}
}
private static void sleepIgnoreException(long millis) {
try {
Thread.sleep(millis);
} catch(Throwable e) {
// ignore
}
}
}
{code}
> borrowObject is stuck, if create fails
> --
>
> Key: POOL-340
> URL: https://issues.apache.org/jira/browse/POOL-340
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.4, 2.4.1, 2.4.2, 2.4.3, 2.5.0
>Reporter: Pavel Kolesov
>Priority: Critical
>
> After changes in 2.4.3 there is a high chance of a scenario, in which
> borrowObject waits infinitely, if create fails or no one calls a create.
> {noformat}
>java.lang.Thread.State: WAITING (parking)
> at
[jira] [Commented] (JEXL-259) Shorter ant-ish variables prevent longer ant-ish variables from being resolved properly
[
https://issues.apache.org/jira/browse/JEXL-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16458364#comment-16458364
]
Dmitri Blinov commented on JEXL-259:
I understand the difficulty of the resolving dotted names that can clash with
properties of the objects themselves, since as I think, Jexl is an interpreted
scripting language, and should process access operators one by one, without
peeping over what would come next in chain. But something needs to be done with
that, because to my mind, clashing of the multi-levelled names is natural for
people to put their thoughts in order, I think there are many examples like
system property names {{java.vendor}} and {{java.vendor.url}} to name a few. If
you see a reliable way to improve the ant-ish variable detection, my opinion is
that definitely needs to be done, and I'm ready to jump in and test whatever I
can. Without that I would be left with the only choice of abandoning ant-ish
variables altogether in favour of something like a recursive cascading
resolver, which is like an old dirty hack
> Shorter ant-ish variables prevent longer ant-ish variables from being
> resolved properly
> ---
>
> Key: JEXL-259
> URL: https://issues.apache.org/jira/browse/JEXL-259
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Major
>
> The following script is evaluated successfully
> {code}
> a.b.c = 2; a.b = 1; return a.b
> {code}
> While the following scripts are terminated with error {{unsolvable property
> 'c'}}
> {code}
> a.b = 1; a.b.c = 2; return a.b
> {code}
> {code}
> a.b.c = 2; a.b = 1; return a.b.c
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (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:all-tabpanel
]
Veera updated FILEUPLOAD-262:
-
Attachment: fileupload_error_veera.txt
> 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 javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> [javax.servlet-api-3.1.0.jar:3.1.0]
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:738)
>
[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=16458361#comment-16458361 ] Veera commented on FILEUPLOAD-262: -- Hi All I am also facing the same exception with commons-fileupload-1.3.jar. However It is not occuring if the client location is close the server location. It is occuring if the server is located at USA and client is located at somewhere in ASIA region. I have attached the server logs for your reference. and for quick reference. 2018-04-21 09:34:45,936 DEBUG [ajp-nio-0.0.0.0-8009-exec-12] [com.mpi.mp.webutil.upload.ClusteredFileUploadJobRegistry] setErrorMessage ::: bytes uploaded = 1092188510 Percentage completed 62 2018-04-21 09:34:45,939 ERROR [ajp-nio-0.0.0.0-8009-exec-12] [com.mpi.mp.admin] Unhandled error [38c42d83-09ba-4eaa-8cb6-40f466183457] org.springframework.web.multipart.MultipartException: Could not parse multipart servlet request; nested exception is org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. null at com.mpi.mp.webutil.upload.ProgressTrackingMultipartResolver.resolveMultipart(ProgressTrackingMultipartResolver.java:132) ~[mpi-webutils.jar:na] at org.springframework.web.servlet.DispatcherServlet.checkMultipart(DispatcherServlet.java:1041) [spring-webmvc.jar:3.2.10.RELEASE] at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:887) [spring-webmvc.jar:3.2.10.RELEASE] at com.mpi.mp.webutil.spring.MPIDispatcherServlet.dispatchAfterFiltering(MPIDispatcherServlet.java:78) [mpi-webutils.jar:na] at com.mpi.mp.webutil.spring.MPIDispatcherServlet.doDispatch(MPIDispatcherServlet.java:61) [mpi-webutils.jar:na] at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:851) [spring-webmvc.jar:3.2.10.RELEASE] at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:953) [spring-webmvc.jar:3.2.10.RELEASE] at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:855) [spring-webmvc.jar:3.2.10.RELEASE] at javax.servlet.http.HttpServlet.service(HttpServlet.java:661) [servlet-api.jar:na] at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:829) [spring-webmvc.jar:3.2.10.RELEASE] at javax.servlet.http.HttpServlet.service(HttpServlet.java:742) [servlet-api.jar:na] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) [catalina.jar:8.5.23] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [catalina.jar:8.5.23] at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) [tomcat7-websocket.jar:8.5.23] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) [catalina.jar:8.5.23] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [catalina.jar:8.5.23] at com.mpi.mp.webutil.filter.RequestDumperFilter.doFilter(RequestDumperFilter.java:61) [mpi-webutils.jar:na] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) [catalina.jar:8.5.23] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [catalina.jar:8.5.23] at com.mpi.util.web.CompositeFilter$IteratingFilterChain.doFilter(CompositeFilter.java:114) [mpi-lodgepole.jar:na] at com.mpi.mp.webutil.filter.DBCachingDisableFilter.doFilter(DBCachingDisableFilter.java:53) [mpi-webutils.jar:na] at com.mpi.util.web.CompositeFilter$IteratingFilterChain.doFilter(CompositeFilter.java:112) [mpi-lodgepole.jar:na] at com.media3k.escene.util.pipeline.URLStopWordsServlet.doFilter(URLStopWordsServlet.java:48) [mpi-lodgepole.jar:na] at com.mpi.util.web.CompositeFilter$IteratingFilterChain.doFilter(CompositeFilter.java:112) [mpi-lodgepole.jar:na] at com.media3k.escene.util.pipeline.NoCachingServlet.doFilter(NoCachingServlet.java:63) [mpi-lodgepole.jar:na] at com.mpi.util.web.CompositeFilter$IteratingFilterChain.doFilter(CompositeFilter.java:112) [mpi-lodgepole.jar:na] at com.qumu.rest.filter.Oauth2Filter.doFilter(Oauth2Filter.java:77) [mpi-rest.jar:na] at com.mpi.util.web.CompositeFilter$IteratingFilterChain.doFilter(CompositeFilter.java:112) [mpi-lodgepole.jar:na] at com.qumu.rest.filter.HTTPCORSFilter.doFilter(HTTPCORSFilter.java:79) [mpi-rest.jar:na] at com.mpi.util.web.CompositeFilter$IteratingFilterChain.doFilter(CompositeFilter.java:112) [mpi-lodgepole.jar:na] at com.mpi.mp.webutil.filter.SharedSecretSSOFilter.doFilter(SharedSecretSSOFilter.java:103) [mpi-webutils.jar:na] at com.mpi.util.web.CompositeFilter$IteratingFilterChain.doFilter(CompositeFilter.java:112) [mpi-lodgepole.jar:na] at
