[jira] [Commented] (COMPRESS-449) IOUtils.skip throws an IOException sometimes
[
https://issues.apache.org/jira/browse/COMPRESS-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16443408#comment-16443408
]
Dennis New commented on COMPRESS-449:
-
Woops, this bug still exists with openjdk 1.8.0_161, except with a slightly
different stacktrace.
{quote}java.io.FileInputStream.skip0(Native Method)
java.io.FileInputStream.skip(FileInputStream.java:283)
java.io.BufferedInputStream.skip(BufferedInputStream.java:377)
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.skip(TarArchiveInputStream.java:211)
org.apache.commons.compress.utils.IOUtils.skip(IOUtils.java:103)
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:263)
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:558)
HelloWorld.main(HelloWorld.java:11)
{quote}
> IOUtils.skip throws an IOException sometimes
>
>
> Key: COMPRESS-449
> URL: https://issues.apache.org/jira/browse/COMPRESS-449
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Dennis New
>Priority: Major
>
> commons-compress > 1.5 introduced some weird IOUtils.skip bug (it introduced
> that function in 1.6 in 2013 I think). It exists with all the versions of
> commons-compress that I tested after 1.5, including 1.6, 1.10. java -version
> says I'm using openjdk version "1.8.0_151" (IcedTea 3.6.0), and I'm using gnu
> tar 1.30.
> Basically, is.skip() and IOUtils.skip() are throwing an IOException somewhere
> somehow. Replacing those functions with is.read(bytearraybufferbla) "fixes"
> the bug for me.
> I can reproduce the bug by creating a tar file even with a single file in it.
> Oddly enough, this bug only appears if the file in the tar is greater than
> 7680 bytes!?. For every possible file size less than or equal to that, it
> works. For every file size greater than that, (I only tested up to 50,000
> bytes :p), it fails. For example:
> dd if=/dev/zero of=testfile2 bs=1 count=7681
> tar cf moo.tar testfile2
> Then with the following java test code:
> import java.io.IOException;
> import org.apache.commons.compress.archivers.tar.TarArchiveEntry;
> import org.apache.commons.compress.archivers.tar.TarArchiveInputStream;
> import org.apache.commons.compress.archivers.ArchiveEntry;
> public class HelloWorld {
> public static void main(String[] args) {
> try {
> TarArchiveInputStream tis = new TarArchiveInputStream
> (System.in);
> ArchiveEntry entry;
> while ( (entry=tis.getNextEntry()) != null) {
> System.out.println(entry.getName());
> }
> } catch (IOException e) {
> for (StackTraceElement ste : e.getStackTrace()) {
> System.out.println(ste);
> }
> }
> }
> }
> Although this works (inputting using that "<" redirection),
> java -Xbootclasspath/a:commons-compress.jar HelloWorld < moo.tar
> This doesn't work (piping it out of a cat call),
> cat moo.tar | java -Xbootclasspath/a:commons-compress.jar HelloWorld
> testfile2
> java.io.FileInputStream.skip(Native Method)
> java.io.BufferedInputStream.skip(BufferedInputStream.java:377)
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.skip(TarArchiveInputStream.java:211)
> org.apache.commons.compress.utils.IOUtils.skip(IOUtils.java:103)
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:263)
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:562)
> HelloWorld.main(HelloWorld.java:11)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-449) IOUtils.skip throws an IOException sometimes
[
https://issues.apache.org/jira/browse/COMPRESS-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16443395#comment-16443395
]
Dennis New commented on COMPRESS-449:
-
Hmm, I think this might be a lower-level bug with my java-vm. It seems to be
fixed in openjdk version "1.8.0_161"
> IOUtils.skip throws an IOException sometimes
>
>
> Key: COMPRESS-449
> URL: https://issues.apache.org/jira/browse/COMPRESS-449
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Dennis New
>Priority: Major
>
> commons-compress > 1.5 introduced some weird IOUtils.skip bug (it introduced
> that function in 1.6 in 2013 I think). It exists with all the versions of
> commons-compress that I tested after 1.5, including 1.6, 1.10. java -version
> says I'm using openjdk version "1.8.0_151" (IcedTea 3.6.0), and I'm using gnu
> tar 1.30.
> Basically, is.skip() and IOUtils.skip() are throwing an IOException somewhere
> somehow. Replacing those functions with is.read(bytearraybufferbla) "fixes"
> the bug for me.
> I can reproduce the bug by creating a tar file even with a single file in it.
> Oddly enough, this bug only appears if the file in the tar is greater than
> 7680 bytes!?. For every possible file size less than or equal to that, it
> works. For every file size greater than that, (I only tested up to 50,000
> bytes :p), it fails. For example:
> dd if=/dev/zero of=testfile2 bs=1 count=7681
> tar cf moo.tar testfile2
> Then with the following java test code:
> import java.io.IOException;
> import org.apache.commons.compress.archivers.tar.TarArchiveEntry;
> import org.apache.commons.compress.archivers.tar.TarArchiveInputStream;
> import org.apache.commons.compress.archivers.ArchiveEntry;
> public class HelloWorld {
> public static void main(String[] args) {
> try {
> TarArchiveInputStream tis = new TarArchiveInputStream
> (System.in);
> ArchiveEntry entry;
> while ( (entry=tis.getNextEntry()) != null) {
> System.out.println(entry.getName());
> }
> } catch (IOException e) {
> for (StackTraceElement ste : e.getStackTrace()) {
> System.out.println(ste);
> }
> }
> }
> }
> Although this works (inputting using that "<" redirection),
> java -Xbootclasspath/a:commons-compress.jar HelloWorld < moo.tar
> This doesn't work (piping it out of a cat call),
> cat moo.tar | java -Xbootclasspath/a:commons-compress.jar HelloWorld
> testfile2
> java.io.FileInputStream.skip(Native Method)
> java.io.BufferedInputStream.skip(BufferedInputStream.java:377)
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.skip(TarArchiveInputStream.java:211)
> org.apache.commons.compress.utils.IOUtils.skip(IOUtils.java:103)
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:263)
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:562)
> HelloWorld.main(HelloWorld.java:11)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-661) Ability to get "real"/"native"/"physical" file name
[ https://issues.apache.org/jira/browse/VFS-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16443380#comment-16443380 ] Bernd Eckenfels commented on VFS-661: - It hink it is a good idea to add FileObject#resolveCanonical() returning the canonical FileName. For local files this would map to File#getCanonicalPath() However I am not sure if the Cifs API does Support that anyway. But for your usecase you could either use a case insensitive comparator or store the URL in lowercase. FileName resolveCanonical() instead of getCanonicalFile to make it clear it’s a slow IO intensive method (not the missleading getter from java.io) > Ability to get "real"/"native"/"physical" file name > --- > > Key: VFS-661 > URL: https://issues.apache.org/jira/browse/VFS-661 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Boris Petrov >Priority: Major > > On case-insensitive file systems (local FS on Windows; Samba; etc) resolving > a file ignores the case that is used. For example, if there is a folder like: > *smb://localhost/share/folder* and is resolved with > *smb://localhost/share/FOLDER* it would work and return the same folder. > However, there is no method in the *FileObject* interface that allows us to > get the "real"/"physical" name of the folder - i.e. *folder*. All of the > methods would return *FOLDER* in this case. > We have a major usecase where we need that. The only solution I can think of > is getting the parent folder, going through its children and thus finding the > correct case but the performance of that would be horrible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (DBCP-487) Add API org.apache.commons.dbcp2.datasources.PerUserPoolDataSource.clear()
[
https://issues.apache.org/jira/browse/DBCP-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed DBCP-487.
-
Resolution: Fixed
Fix Version/s: 2.3.0
In git master.
> Add API org.apache.commons.dbcp2.datasources.PerUserPoolDataSource.clear()
> --
>
> Key: DBCP-487
> URL: https://issues.apache.org/jira/browse/DBCP-487
> Project: Commons DBCP
> Issue Type: Improvement
>Reporter: Gary Gregory
>Priority: Major
> Fix For: 2.3.0
>
>
> Add API
> {{org.apache.commons.dbcp2.datasources.PerUserPoolDataSource.clear()}}:
> {code:java}
> /**
> * Clears pool(s) being maintained by this data source.
> *
> * @see org.apache.commons.pool2.ObjectPool#clear()
> */
> public void clear()
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (DBCP-487) Add API org.apache.commons.dbcp2.datasources.PerUserPoolDataSource.clear()
Gary Gregory created DBCP-487:
-
Summary: Add API
org.apache.commons.dbcp2.datasources.PerUserPoolDataSource.clear()
Key: DBCP-487
URL: https://issues.apache.org/jira/browse/DBCP-487
Project: Commons DBCP
Issue Type: Improvement
Reporter: Gary Gregory
Add API {{org.apache.commons.dbcp2.datasources.PerUserPoolDataSource.clear()}}:
{code:java}
/**
* Clears pool(s) being maintained by this data source.
*
* @see org.apache.commons.pool2.ObjectPool#clear()
*/
public void clear()
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (DBCP-486) DriverAdapterCPDS.setUser(), setPassword(), and getPooledConnection() with null arguments throw NullPointerExceptions when connection properties are set
[
https://issues.apache.org/jira/browse/DBCP-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed DBCP-486.
-
Resolution: Fixed
> DriverAdapterCPDS.setUser(), setPassword(), and getPooledConnection() with
> null arguments throw NullPointerExceptions when connection properties are set
>
>
> Key: DBCP-486
> URL: https://issues.apache.org/jira/browse/DBCP-486
> Project: Commons DBCP
> Issue Type: Improvement
>Affects Versions: 2.2.0
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.2.1
>
>
> The following method calls throw a {{NullPointerException}} when connection
> properties are set:
> - {{org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.setUser(null)}},
> -
> {{org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.setPassword(null)}}
> -
> {{org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.getPooledConnection(null,
> null)}}
> -
> {{org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.getPooledConnection("not
> null", null)}}
> -
> {{org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.getPooledConnection(null,
> "not null")}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DBCP-486) DriverAdapterCPDS.setUser(), setPassword(), and getPooledConnection() with null arguments throw NullPointerExceptions when connection properties are set
[
https://issues.apache.org/jira/browse/DBCP-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated DBCP-486:
--
Summary: DriverAdapterCPDS.setUser(), setPassword(), and
getPooledConnection() with null arguments throw NullPointerExceptions when
connection properties are set (was: DriverAdapterCPDS.setUser(null) and
setPassword(null) throw NullPointerExceptions when connection properties are
set)
> DriverAdapterCPDS.setUser(), setPassword(), and getPooledConnection() with
> null arguments throw NullPointerExceptions when connection properties are set
>
>
> Key: DBCP-486
> URL: https://issues.apache.org/jira/browse/DBCP-486
> Project: Commons DBCP
> Issue Type: Improvement
>Affects Versions: 2.2.0
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.2.1
>
>
> The following method calls throw a {{NullPointerException}} when connection
> properties are set:
> - {{org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.setUser(null)}},
> -
> {{org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.setPassword(null)}}
> -
> {{org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.getPooledConnection(null,
> null)}}
> -
> {{org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.getPooledConnection("not
> null", null)}}
> -
> {{org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.getPooledConnection(null,
> "not null")}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DBCP-486) DriverAdapterCPDS.setUser(null) and setPassword(null) throw NullPointerExceptions when connection properties are set
[
https://issues.apache.org/jira/browse/DBCP-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated DBCP-486:
--
Description:
The following method calls throw a {{NullPointerException}} when connection
properties are set:
- {{org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.setUser(null)}},
- {{org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.setPassword(null)}}
-
{{org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.getPooledConnection(null,
null)}}
-
{{org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.getPooledConnection("not
null", null)}}
-
{{org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.getPooledConnection(null,
"not null")}}
was:
The method calls
{{org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.setUser(null)}},
{{setPassword(null)}} throw {{NullPointerException}} when connection properties
are set:
getPooledConnection
> DriverAdapterCPDS.setUser(null) and setPassword(null) throw
> NullPointerExceptions when connection properties are set
>
>
> Key: DBCP-486
> URL: https://issues.apache.org/jira/browse/DBCP-486
> Project: Commons DBCP
> Issue Type: Improvement
>Affects Versions: 2.2.0
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.2.1
>
>
> The following method calls throw a {{NullPointerException}} when connection
> properties are set:
> - {{org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.setUser(null)}},
> -
> {{org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.setPassword(null)}}
> -
> {{org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.getPooledConnection(null,
> null)}}
> -
> {{org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.getPooledConnection("not
> null", null)}}
> -
> {{org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.getPooledConnection(null,
> "not null")}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DBCP-486) DriverAdapterCPDS.setUser(null) and setPassword(null) throw NullPointerExceptions when connection properties are set
[
https://issues.apache.org/jira/browse/DBCP-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated DBCP-486:
--
Description:
The method calls
{{org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.setUser(null)}},
{{setPassword(null)}} throw {{NullPointerException}} when connection properties
are set:
getPooledConnection
was:The method calls
{{org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.setUser(null)}} and
{{setPassword(null)}} throw {{NullPointerException}} when connection properties
are set.
> DriverAdapterCPDS.setUser(null) and setPassword(null) throw
> NullPointerExceptions when connection properties are set
>
>
> Key: DBCP-486
> URL: https://issues.apache.org/jira/browse/DBCP-486
> Project: Commons DBCP
> Issue Type: Improvement
>Affects Versions: 2.2.0
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.2.1
>
>
> The method calls
> {{org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.setUser(null)}},
> {{setPassword(null)}} throw {{NullPointerException}} when connection
> properties are set:
> getPooledConnection
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (DBCP-486) DriverAdapterCPDS.setUser(null) and setPassword(null) throw NullPointerExceptions when connection properties are set
[
https://issues.apache.org/jira/browse/DBCP-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory reopened DBCP-486:
---
> DriverAdapterCPDS.setUser(null) and setPassword(null) throw
> NullPointerExceptions when connection properties are set
>
>
> Key: DBCP-486
> URL: https://issues.apache.org/jira/browse/DBCP-486
> Project: Commons DBCP
> Issue Type: Improvement
>Affects Versions: 2.2.0
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.2.1
>
>
> The method calls
> {{org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.setUser(null)}} and
> {{setPassword(null)}} throw {{NullPointerException}} when connection
> properties are set.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (DBCP-486) DriverAdapterCPDS.setUser(null) and setPassword(null) throw NullPointerExceptions when connection properties are set
[
https://issues.apache.org/jira/browse/DBCP-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed DBCP-486.
-
Resolution: Fixed
Fix Version/s: 2.2.1
In git master.
> DriverAdapterCPDS.setUser(null) and setPassword(null) throw
> NullPointerExceptions when connection properties are set
>
>
> Key: DBCP-486
> URL: https://issues.apache.org/jira/browse/DBCP-486
> Project: Commons Dbcp
> Issue Type: Improvement
>Affects Versions: 2.2.0
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.2.1
>
>
> The method calls
> {{org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.setUser(null)}} and
> {{setPassword(null)}} throw {{NullPointerException}} when connection
> properties are set.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DBCP-486) DriverAdapterCPDS.setUser(null) and setPassword(null) throw NullPointerExceptions when connection properties are set
[
https://issues.apache.org/jira/browse/DBCP-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated DBCP-486:
--
Description: The method calls
{{org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.setUser(null)}} and
{{setPassword(null)}} throw {{NullPointerException}} when connection properties
are set. (was: The method calls
{{org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.setUser(null)}} and
{{setPassword(null)}} throw {{NullPointerException}}s when connection
properties are set.)
> DriverAdapterCPDS.setUser(null) and setPassword(null) throw
> NullPointerExceptions when connection properties are set
>
>
> Key: DBCP-486
> URL: https://issues.apache.org/jira/browse/DBCP-486
> Project: Commons Dbcp
> Issue Type: Improvement
>Affects Versions: 2.2.0
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
>
> The method calls
> {{org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.setUser(null)}} and
> {{setPassword(null)}} throw {{NullPointerException}} when connection
> properties are set.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (DBCP-486) DriverAdapterCPDS.setUser(null) and setPassword(null) throw NullPointerExceptions when connection properties are set
Gary Gregory created DBCP-486:
-
Summary: DriverAdapterCPDS.setUser(null) and setPassword(null)
throw NullPointerExceptions when connection properties are set
Key: DBCP-486
URL: https://issues.apache.org/jira/browse/DBCP-486
Project: Commons Dbcp
Issue Type: Improvement
Affects Versions: 2.2.0
Reporter: Gary Gregory
Assignee: Gary Gregory
The method calls
{{org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS.setUser(null)}} and
{{setPassword(null)}} throw {{NullPointerException}}s when connection
properties are set.
--
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=16443116#comment-16443116
]
Phil Steitz commented on POOL-340:
--
If I understand what is being reported here, my recommendation would be don't
try to fix (i.e. WONT_FIX). IIUC, what is going on is
# thread enters borrowObject
# No objects are available in the pool and the factory is "down"
# Create fails, so thread waits on the idle instance queue
# Factory comes back up
# Desired behavior is that the pool figures out that the factory works again
and serves the waiting thread
I would say it is not the responsibility of the pool to monitor the factory.
As a workaround, client code can monitor the factory and when it comes back up,
use addObject to push new instances onto the pool to serve waiting threads.
> 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] [Resolved] (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
]
Gary Gregory resolved LANG-1391.
Resolution: Fixed
Fix Version/s: 3.8
I updated the Javadoc in git master. Please verify and close.
If anyone of you would like to participate and volunteer to improve the Javadoc
for the other methods in this class, please provide a PR on GitHub at
[https://github.com/apache/commons-lang]
Thank you!
Gary
> 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: Major
> 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] [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
]
Gary Gregory updated LANG-1391:
---
Summary: Improve Javadoc for StringUtils.isAnyEmpty(null) (was:
StringUtils.isAnyEmpty(null) returns incorrect value)
> 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: Major
>
>
> 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=16442961#comment-16442961
]
Gary Gregory commented on POOL-340:
---
[~pavelk]:
Thank you for your report.
Can you provide a unit test that demonstrates the problem? You can provide a PR
on GitHub: [https://github.com/apache/commons-pool]
Gary
> 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] [Resolved] (VALIDATOR-438) IBANValidator fails for El Salvador
[
https://issues.apache.org/jira/browse/VALIDATOR-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved VALIDATOR-438.
Resolution: Fixed
URL: http://svn.apache.org/viewvc?rev=1829465=rev
Log:
IBANValidator fails for El Salvador
Modified:
commons/proper/validator/trunk/src/changes/changes.xml
commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/IBANValidator.java
commons/proper/validator/trunk/src/test/java/org/apache/commons/validator/routines/IBANValidatorTest.java
> IBANValidator fails for El Salvador
> ---
>
> Key: VALIDATOR-438
> URL: https://issues.apache.org/jira/browse/VALIDATOR-438
> Project: Commons Validator
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Simon Marti
>Priority: Major
>
> The {{IBANValidator}} does not validate the IBANs from El Salvador, even
> though they are part of the IBAN registry.
> E.g. {{SV62CENR00700025}} fails but should pass.
> See https://www.iban.com/structure.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VALIDATOR-438) IBANValidator fails for El Salvador
[
https://issues.apache.org/jira/browse/VALIDATOR-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16442855#comment-16442855
]
Sebb commented on VALIDATOR-438:
The format was missed when the country list was updated. It will be added in
due course.
Unfortunately SWIFT don't include a proper change list in new versions of the
document so manual checking is needed.
Note that one can create one's own validator.
> IBANValidator fails for El Salvador
> ---
>
> Key: VALIDATOR-438
> URL: https://issues.apache.org/jira/browse/VALIDATOR-438
> Project: Commons Validator
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Simon Marti
>Priority: Major
>
> The {{IBANValidator}} does not validate the IBANs from El Salvador, even
> though they are part of the IBAN registry.
> E.g. {{SV62CENR00700025}} fails but should pass.
> See https://www.iban.com/structure.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-661) Ability to get "real"/"native"/"physical" file name
[
https://issues.apache.org/jira/browse/VFS-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16442609#comment-16442609
]
Boris Petrov commented on VFS-661:
--
Well, I just do a:
{code:java}
...
fileSystemManager = (DefaultFileSystemManager) VFS.getManager();
...
FileSystemOptions fileSystemOptions = new FileSystemOptions();
...
FileObject file = fileSystemManager.resolveFile(filePath, fileSystemOptions);
{code}
I use the same *filePath* as an ID in the DB. So when *filePath* is
*smb://localhost/share/folder* all works fine - the file AND the metadata are
found. When *filePath* is *smb://localhost/share/FOLDER* - the file is found
(the *resolveFile* from the code above returns the same file) but the DB finds
nothing.
> Ability to get "real"/"native"/"physical" file name
> ---
>
> Key: VFS-661
> URL: https://issues.apache.org/jira/browse/VFS-661
> Project: Commons VFS
> Issue Type: New Feature
>Affects Versions: 2.2
>Reporter: Boris Petrov
>Priority: Major
>
> On case-insensitive file systems (local FS on Windows; Samba; etc) resolving
> a file ignores the case that is used. For example, if there is a folder like:
> *smb://localhost/share/folder* and is resolved with
> *smb://localhost/share/FOLDER* it would work and return the same folder.
> However, there is no method in the *FileObject* interface that allows us to
> get the "real"/"physical" name of the folder - i.e. *folder*. All of the
> methods would return *FOLDER* in this case.
> We have a major usecase where we need that. The only solution I can think of
> is getting the parent folder, going through its children and thus finding the
> correct case but the performance of that would be horrible.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-661) Ability to get "real"/"native"/"physical" file name
[ https://issues.apache.org/jira/browse/VFS-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16442600#comment-16442600 ] Otto Fowler commented on VFS-661: - I want to be sure I'm correct in the way you are finding and resolving the file. > Ability to get "real"/"native"/"physical" file name > --- > > Key: VFS-661 > URL: https://issues.apache.org/jira/browse/VFS-661 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Boris Petrov >Priority: Major > > On case-insensitive file systems (local FS on Windows; Samba; etc) resolving > a file ignores the case that is used. For example, if there is a folder like: > *smb://localhost/share/folder* and is resolved with > *smb://localhost/share/FOLDER* it would work and return the same folder. > However, there is no method in the *FileObject* interface that allows us to > get the "real"/"physical" name of the folder - i.e. *folder*. All of the > methods would return *FOLDER* in this case. > We have a major usecase where we need that. The only solution I can think of > is getting the parent folder, going through its children and thus finding the > correct case but the performance of that would be horrible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (VFS-661) Ability to get "real"/"native"/"physical" file name
[ https://issues.apache.org/jira/browse/VFS-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16442584#comment-16442584 ] Boris Petrov edited comment on VFS-661 at 4/18/18 2:26 PM: --- I'm not sure what code sample you need. I can explain our use case - we are saving additional metadata for each file in a file system in a database. We walk the file system, get each file and use that as an ID in the DB. So in the DB we're going to have *smb://localhost/share/folder* as an ID. Then, when someone requests a file, we get it from the filesystem and return the metadata associated with it from the DB. However, you can imagine that when someone requests *smb://localhost/share/FOLDER*, we do find the file (on a case-insensitive file system) but the DB doesn't return the metadata as the ID is wrong and hence we return a wrong result to the user - we've found the correct file but haven't found the correct metadata. And, as I said, there is nothing we can do about it as VFS doesn't give us the "real" name so we have no way of finding the metadata associated with it. was (Author: boris-petrov): I'm not sure what code sample you need. I can explain our use case - we are saving additional metadata for each file in a file system in a database. We walk the file system, get each file and use that as an ID in the DB. So in the DB we're going to have *smb://localhost/share/folder* as an ID. Then, when someone requests a file, we get it from the filesystem and return the metadata associated with it from the DB. However, you can imagine that when someone requests *smb://localhost/share/FOLDER*, we do find the file but the DB doesn't return the metadata as the ID is wrong and hence we return a wrong result to the user - we've found the correct file but haven't found the correct metadata. And, as I said, there is nothing we can do about it as VFS doesn't give us the "real" name so we have no way of finding the metadata associated with it. > Ability to get "real"/"native"/"physical" file name > --- > > Key: VFS-661 > URL: https://issues.apache.org/jira/browse/VFS-661 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Boris Petrov >Priority: Major > > On case-insensitive file systems (local FS on Windows; Samba; etc) resolving > a file ignores the case that is used. For example, if there is a folder like: > *smb://localhost/share/folder* and is resolved with > *smb://localhost/share/FOLDER* it would work and return the same folder. > However, there is no method in the *FileObject* interface that allows us to > get the "real"/"physical" name of the folder - i.e. *folder*. All of the > methods would return *FOLDER* in this case. > We have a major usecase where we need that. The only solution I can think of > is getting the parent folder, going through its children and thus finding the > correct case but the performance of that would be horrible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-661) Ability to get "real"/"native"/"physical" file name
[ https://issues.apache.org/jira/browse/VFS-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16442584#comment-16442584 ] Boris Petrov commented on VFS-661: -- I'm not sure what code sample you need. I can explain our use case - we are saving additional metadata for each file in a file system in a database. We walk the file system, get each file and use that as an ID in the DB. So in the DB we're going to have *smb://localhost/share/folder* as an ID. Then, when someone requests a file, we get it from the filesystem and return the metadata associated with it from the DB. However, you can imagine that when someone requests *smb://localhost/share/FOLDER*, we do find the file but the DB doesn't return the metadata as the ID is wrong and hence we return a wrong result to the user - we've found the correct file but haven't found the correct metadata. And, as I said, there is nothing we can do about it as VFS doesn't give us the "real" name so we have no way of finding the metadata associated with it. > Ability to get "real"/"native"/"physical" file name > --- > > Key: VFS-661 > URL: https://issues.apache.org/jira/browse/VFS-661 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Boris Petrov >Priority: Major > > On case-insensitive file systems (local FS on Windows; Samba; etc) resolving > a file ignores the case that is used. For example, if there is a folder like: > *smb://localhost/share/folder* and is resolved with > *smb://localhost/share/FOLDER* it would work and return the same folder. > However, there is no method in the *FileObject* interface that allows us to > get the "real"/"physical" name of the folder - i.e. *folder*. All of the > methods would return *FOLDER* in this case. > We have a major usecase where we need that. The only solution I can think of > is getting the parent folder, going through its children and thus finding the > correct case but the performance of that would be horrible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-661) Ability to get "real"/"native"/"physical" file name
[ https://issues.apache.org/jira/browse/VFS-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16442517#comment-16442517 ] Otto Fowler commented on VFS-661: - Can you post a small code sample? I want to be sure that I understand. > Ability to get "real"/"native"/"physical" file name > --- > > Key: VFS-661 > URL: https://issues.apache.org/jira/browse/VFS-661 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Boris Petrov >Priority: Major > > On case-insensitive file systems (local FS on Windows; Samba; etc) resolving > a file ignores the case that is used. For example, if there is a folder like: > *smb://localhost/share/folder* and is resolved with > *smb://localhost/share/FOLDER* it would work and return the same folder. > However, there is no method in the *FileObject* interface that allows us to > get the "real"/"physical" name of the folder - i.e. *folder*. All of the > methods would return *FOLDER* in this case. > We have a major usecase where we need that. The only solution I can think of > is getting the parent folder, going through its children and thus finding the > correct case but the performance of that would be horrible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (VALIDATOR-438) IBANValidator fails for El Salvador
Simon Marti created VALIDATOR-438:
-
Summary: IBANValidator fails for El Salvador
Key: VALIDATOR-438
URL: https://issues.apache.org/jira/browse/VALIDATOR-438
Project: Commons Validator
Issue Type: Bug
Affects Versions: 1.6
Reporter: Simon Marti
The {{IBANValidator}} does not validate the IBANs from El Salvador, even though
they are part of the IBAN registry.
E.g. {{SV62CENR00700025}} fails but should pass.
See https://www.iban.com/structure.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (POOL-340) borrowObject is stuck, if create fails
[
https://issues.apache.org/jira/browse/POOL-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kolesov updated POOL-340:
---
Affects Version/s: 2.4
2.4.1
2.4.2
> 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=16442200#comment-16442200
]
Pavel Kolesov commented on POOL-340:
Tried the same scenario on 2.4.2 - the same result. We used to have 1.5.5
before, which doesn't seem to suffer from this problem.
The objection "if factory can't create, so why borrow should return something"
is also checked - if pool is not exhausted and factory throws exception,
borrowObject does return (the exception is propagated).
> 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.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] [Resolved] (COMPRESS-448) IOUtils.skip is throwing an IOException somewhere sometimes
[
https://issues.apache.org/jira/browse/COMPRESS-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved COMPRESS-448.
---
Resolution: Duplicate
> IOUtils.skip is throwing an IOException somewhere sometimes
> ---
>
> Key: COMPRESS-448
> URL: https://issues.apache.org/jira/browse/COMPRESS-448
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Dennis New
>Priority: Major
>
> commons-compress > 1.5 introduced some weird IOUtils.skip bug (it introduced
> that function in 1.6 in 2013 I think). It exists with all the versions of
> commons-compress that I tested after 1.5, including 1.6, 1.10. java -version
> says I'm using openjdk version "1.8.0_151" (IcedTea 3.6.0), and I'm using gnu
> tar 1.30.
> Basically, is.skip() and IOUtils.skip() are throwing an IOException somewhere
> somehow. Replacing those functions with is.read(bytearraybufferbla) "fixes"
> the bug for me.
> I can reproduce the bug by creating a tar file even with a single file in it.
> Oddly enough, this bug only appears if the file in the tar is greater than
> 7680 bytes!?. For every possible file size less than or equal to that, it
> works. For every file size greater than that, (I only tested up to 50,000
> bytes :p), it fails. For example:
> dd if=/dev/zero of=testfile2 bs=1 count=7681
> tar cf moo.tar testfile2
> Then with the following java test code:
> import java.io.IOException;
> import org.apache.commons.compress.archivers.tar.TarArchiveEntry;
> import org.apache.commons.compress.archivers.tar.TarArchiveInputStream;
> import org.apache.commons.compress.archivers.ArchiveEntry;
> public class HelloWorld {
> public static void main(String[] args) {
> try {
> TarArchiveInputStream tis = new TarArchiveInputStream
> (System.in);
> ArchiveEntry entry;
> while ( (entry=tis.getNextEntry()) != null) {
> System.out.println(entry.getName());
> }
> } catch (IOException e) {
> for (StackTraceElement ste : e.getStackTrace()) {
> System.out.println(ste);
> }
> }
> }
> }
> Although this works (inputting using that "<" redirection),
> java -Xbootclasspath/a:commons-compress.jar HelloWorld < moo.tar
> This doesn't work (piping it out of a cat call),
> cat moo.tar | java -Xbootclasspath/a:commons-compress.jar HelloWorld
> testfile2
> java.io.FileInputStream.skip(Native Method)
> java.io.BufferedInputStream.skip(BufferedInputStream.java:377)
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.skip(TarArchiveInputStream.java:211)
> org.apache.commons.compress.utils.IOUtils.skip(IOUtils.java:103)
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:263)
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:562)
> HelloWorld.main(HelloWorld.java:11)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (POOL-340) borrowObject is stuck, if create fails
Pavel Kolesov created POOL-340:
--
Summary: 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.5.0, 2.4.3
Reporter: Pavel Kolesov
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] [Updated] (POOL-340) borrowObject is stuck, if create fails
[
https://issues.apache.org/jira/browse/POOL-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kolesov updated POOL-340:
---
Description:
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.
was:
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.
> 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.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-661) Ability to get "real"/"native"/"physical" file name
[ https://issues.apache.org/jira/browse/VFS-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16442086#comment-16442086 ] Boris Petrov commented on VFS-661: -- The issue is that I can't get the real name. I guess it is correct to resolve the "wrong" name as the file system is case-insensitive but in that case I need also to be able to get the real name. Yes, having a per provider setting is even better, but that is going to be way more difficult to implement (if at all possible - how do you do case-sensitivity on Windows?). > Ability to get "real"/"native"/"physical" file name > --- > > Key: VFS-661 > URL: https://issues.apache.org/jira/browse/VFS-661 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Boris Petrov >Priority: Major > > On case-insensitive file systems (local FS on Windows; Samba; etc) resolving > a file ignores the case that is used. For example, if there is a folder like: > *smb://localhost/share/folder* and is resolved with > *smb://localhost/share/FOLDER* it would work and return the same folder. > However, there is no method in the *FileObject* interface that allows us to > get the "real"/"physical" name of the folder - i.e. *folder*. All of the > methods would return *FOLDER* in this case. > We have a major usecase where we need that. The only solution I can think of > is getting the parent folder, going through its children and thus finding the > correct case but the performance of that would be horrible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
