[jira] [Created] (VFS-544) VirtualFileSystems leak
Bernd Eckenfels created VFS-544: --- Summary: VirtualFileSystems leak Key: VFS-544 URL: https://issues.apache.org/jira/browse/VFS-544 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: Bernd Eckenfels Assignee: Bernd Eckenfels Fix For: 2.1 When creating a org.apache.commons.vfs2.impl.VirtualFileSystem by org.apache.commons.vfs2.impl.VirtualFileProvider it is tracked as a component. But since VirtualFileProvider is not an AbstractFileProvider and not registered in providers it will never be closed by org.apache.commons.vfs2.impl.DefaultFileSystemManager._closeFileSystem(FileSystem). Also the final instance of VirtualFileProvider does not get closed when the DefaultFileSystemManager gets closed. VirtualFileSystem itself does not have critical resources, but its DelegatedFiles are cached so there should be a way to close them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (VFS-544) VirtualFileSystems leak
[
https://issues.apache.org/jira/browse/VFS-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14207803#comment-14207803
]
Bernd Eckenfels commented on VFS-544:
-
Given the fact we cannot register a VirtualFileProvider by scheme (and it does
not implement AbstractFileProvider), I guess it is best to hardcode the closing
of those objects in _closeFileSystem:
public void _closeFileSystem(final FileSystem filesystem)
{
if (filesystem instanceof VirtualFileSystem)
{
vfsProvider.closeFileSystem(filesystem);
return;
}
final FileProvider provider =
providers.get(filesystem.getRootName().getScheme());
if (provider != null)
{
((AbstractFileProvider) provider).closeFileSystem(filesystem);
}
}
And also making vfsProvider not final, so it can be constructed in init() and
destroyed in close(). Will append a patch.
> VirtualFileSystems leak
> ---
>
> Key: VFS-544
> URL: https://issues.apache.org/jira/browse/VFS-544
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Bernd Eckenfels
>Assignee: Bernd Eckenfels
> Labels: leak
> Fix For: 2.1
>
>
> When creating a org.apache.commons.vfs2.impl.VirtualFileSystem by
> org.apache.commons.vfs2.impl.VirtualFileProvider it is tracked as a
> component. But since VirtualFileProvider is not an AbstractFileProvider and
> not registered in providers it will never be closed by
> org.apache.commons.vfs2.impl.DefaultFileSystemManager._closeFileSystem(FileSystem).
> Also the final instance of VirtualFileProvider does not get closed when the
> DefaultFileSystemManager gets closed.
> VirtualFileSystem itself does not have critical resources, but its
> DelegatedFiles are cached so there should be a way to close them.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (VFS-544) VirtualFileSystems leak
[
https://issues.apache.org/jira/browse/VFS-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14207803#comment-14207803
]
Bernd Eckenfels edited comment on VFS-544 at 11/12/14 8:49 AM:
---
Given the fact we cannot register a VirtualFileProvider by scheme (and it does
not implement AbstractFileProvider), I guess it is best to hardcode the closing
of those objects in _closeFileSystem:
{code}
public void _closeFileSystem(final FileSystem filesystem)
{
final FileProvider provider =
providers.get(filesystem.getRootName().getScheme());
if (provider != null)
{
((AbstractFileProvider) provider).closeFileSystem(filesystem);
}
else if (filesystem instanceof VirtualFileSystem)
{
vfsProvider.closeFileSystem(filesystem);
}
}
{code}
And also making vfsProvider not final, so it can be constructed in init() and
destroyed in close(). Will append a patch.
was (Author: b.eckenfels):
Given the fact we cannot register a VirtualFileProvider by scheme (and it does
not implement AbstractFileProvider), I guess it is best to hardcode the closing
of those objects in _closeFileSystem:
public void _closeFileSystem(final FileSystem filesystem)
{
if (filesystem instanceof VirtualFileSystem)
{
vfsProvider.closeFileSystem(filesystem);
return;
}
final FileProvider provider =
providers.get(filesystem.getRootName().getScheme());
if (provider != null)
{
((AbstractFileProvider) provider).closeFileSystem(filesystem);
}
}
And also making vfsProvider not final, so it can be constructed in init() and
destroyed in close(). Will append a patch.
> VirtualFileSystems leak
> ---
>
> Key: VFS-544
> URL: https://issues.apache.org/jira/browse/VFS-544
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Bernd Eckenfels
>Assignee: Bernd Eckenfels
> Labels: leak
> Fix For: 2.1
>
>
> When creating a org.apache.commons.vfs2.impl.VirtualFileSystem by
> org.apache.commons.vfs2.impl.VirtualFileProvider it is tracked as a
> component. But since VirtualFileProvider is not an AbstractFileProvider and
> not registered in providers it will never be closed by
> org.apache.commons.vfs2.impl.DefaultFileSystemManager._closeFileSystem(FileSystem).
> Also the final instance of VirtualFileProvider does not get closed when the
> DefaultFileSystemManager gets closed.
> VirtualFileSystem itself does not have critical resources, but its
> DelegatedFiles are cached so there should be a way to close them.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (VFS-544) VirtualFileSystems leak
[ https://issues.apache.org/jira/browse/VFS-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Eckenfels updated VFS-544: Labels: leak patch (was: leak) > VirtualFileSystems leak > --- > > Key: VFS-544 > URL: https://issues.apache.org/jira/browse/VFS-544 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Bernd Eckenfels >Assignee: Bernd Eckenfels > Labels: leak, patch > Fix For: 2.1 > > Attachments: vfs-544-v1.patch > > > When creating a org.apache.commons.vfs2.impl.VirtualFileSystem by > org.apache.commons.vfs2.impl.VirtualFileProvider it is tracked as a > component. But since VirtualFileProvider is not an AbstractFileProvider and > not registered in providers it will never be closed by > org.apache.commons.vfs2.impl.DefaultFileSystemManager._closeFileSystem(FileSystem). > Also the final instance of VirtualFileProvider does not get closed when the > DefaultFileSystemManager gets closed. > VirtualFileSystem itself does not have critical resources, but its > DelegatedFiles are cached so there should be a way to close them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (VFS-544) VirtualFileSystems leak
[ https://issues.apache.org/jira/browse/VFS-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Eckenfels updated VFS-544: Attachment: vfs-544-v1.patch First version of the patch, it passes all tests (on Windows). > VirtualFileSystems leak > --- > > Key: VFS-544 > URL: https://issues.apache.org/jira/browse/VFS-544 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Bernd Eckenfels >Assignee: Bernd Eckenfels > Labels: leak, patch > Fix For: 2.1 > > Attachments: vfs-544-v1.patch > > > When creating a org.apache.commons.vfs2.impl.VirtualFileSystem by > org.apache.commons.vfs2.impl.VirtualFileProvider it is tracked as a > component. But since VirtualFileProvider is not an AbstractFileProvider and > not registered in providers it will never be closed by > org.apache.commons.vfs2.impl.DefaultFileSystemManager._closeFileSystem(FileSystem). > Also the final instance of VirtualFileProvider does not get closed when the > DefaultFileSystemManager gets closed. > VirtualFileSystem itself does not have critical resources, but its > DelegatedFiles are cached so there should be a way to close them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MATH-1167) OLSMultipleLinearRegression STILL needs a way to specify non-zero singularity threshold when instantiating QRDecomposition
Neil Ireson created MATH-1167: - Summary: OLSMultipleLinearRegression STILL needs a way to specify non-zero singularity threshold when instantiating QRDecomposition Key: MATH-1167 URL: https://issues.apache.org/jira/browse/MATH-1167 Project: Commons Math Issue Type: Bug Affects Versions: 3.3 Environment: jdk1.7_71, OSX 10.10 Reporter: Neil Ireson Priority: Critical A fix was made for this issue in MATH-1110 for the newSampleData method but not for the newXSampleData method. It's a simple change to propagate the threshold to QRDecomposition: 237c237 < qr = new QRDecomposition(getX()); --- > qr = new QRDecomposition(getX(), threshold); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1167) OLSMultipleLinearRegression STILL needs a way to specify non-zero singularity threshold when instantiating QRDecomposition
[ https://issues.apache.org/jira/browse/MATH-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-1167. -- Resolution: Fixed Fix Version/s: 3.4 Fixed in commit 301ad592142079d36f4d33f5309c103c7f4f5dfb Thanks for the report and patch. > OLSMultipleLinearRegression STILL needs a way to specify non-zero singularity > threshold when instantiating QRDecomposition > -- > > Key: MATH-1167 > URL: https://issues.apache.org/jira/browse/MATH-1167 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.3 > Environment: jdk1.7_71, OSX 10.10 >Reporter: Neil Ireson >Priority: Critical > Fix For: 3.4 > > > A fix was made for this issue in MATH-1110 for the newSampleData method but > not for the newXSampleData method. > It's a simple change to propagate the threshold to QRDecomposition: > 237c237 > < qr = new QRDecomposition(getX()); > --- > > qr = new QRDecomposition(getX(), threshold); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (FILEUPLOAD-235) FileItem.getName() does not conform to the Java File.getName behaviour and *returns* a full path when provided with one
[ https://issues.apache.org/jira/browse/FILEUPLOAD-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart reopened FILEUPLOAD-235: Hmm, the best way is to re-open the issue and assign it a fix version for 2.x, so that we do not lose track of it. > FileItem.getName() does not conform to the Java File.getName behaviour and > *returns* a full path when provided with one > --- > > Key: FILEUPLOAD-235 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-235 > Project: Commons FileUpload > Issue Type: Bug >Affects Versions: 1.3 >Reporter: David > > I understand that FileItem is simply following RFC 1867, but the > implementation of 'getName' > method on a file related class IMHO should follow the behaviour of the java > File class which > bq. Returns the name of the file or directory denoted by this abstract > pathname. This is just the last name in the pathname's name sequence. If the > pathname's name sequence is empty, then the empty string is returned. > http://docs.oracle.com/javase/7/docs/api/java/io/File.html#getName() > I propose that FileItem.getName() is changed to *match* the java File class > behaviour and that another method called something like 'getRawName' be added > to the FileItem class. The rational for this change is to make it less easy > to shoot oneself in the foot (in no modern web application is a 'full > filepath' useful, especially when most browsers do not send one!). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FILEUPLOAD-235) FileItem.getName() does not conform to the Java File.getName behaviour and *returns* a full path when provided with one
[ https://issues.apache.org/jira/browse/FILEUPLOAD-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated FILEUPLOAD-235: --- Priority: Minor (was: Major) > FileItem.getName() does not conform to the Java File.getName behaviour and > *returns* a full path when provided with one > --- > > Key: FILEUPLOAD-235 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-235 > Project: Commons FileUpload > Issue Type: Bug >Affects Versions: 1.3 >Reporter: David >Priority: Minor > > I understand that FileItem is simply following RFC 1867, but the > implementation of 'getName' > method on a file related class IMHO should follow the behaviour of the java > File class which > bq. Returns the name of the file or directory denoted by this abstract > pathname. This is just the last name in the pathname's name sequence. If the > pathname's name sequence is empty, then the empty string is returned. > http://docs.oracle.com/javase/7/docs/api/java/io/File.html#getName() > I propose that FileItem.getName() is changed to *match* the java File class > behaviour and that another method called something like 'getRawName' be added > to the FileItem class. The rational for this change is to make it less easy > to shoot oneself in the foot (in no modern web application is a 'full > filepath' useful, especially when most browsers do not send one!). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FILEUPLOAD-235) FileItem.getName() does not conform to the Java File.getName behaviour and *returns* a full path when provided with one
[ https://issues.apache.org/jira/browse/FILEUPLOAD-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated FILEUPLOAD-235: --- Fix Version/s: 2.x > FileItem.getName() does not conform to the Java File.getName behaviour and > *returns* a full path when provided with one > --- > > Key: FILEUPLOAD-235 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-235 > Project: Commons FileUpload > Issue Type: Bug >Affects Versions: 1.3 >Reporter: David >Priority: Minor > Fix For: 2.x > > > I understand that FileItem is simply following RFC 1867, but the > implementation of 'getName' > method on a file related class IMHO should follow the behaviour of the java > File class which > bq. Returns the name of the file or directory denoted by this abstract > pathname. This is just the last name in the pathname's name sequence. If the > pathname's name sequence is empty, then the empty string is returned. > http://docs.oracle.com/javase/7/docs/api/java/io/File.html#getName() > I propose that FileItem.getName() is changed to *match* the java File class > behaviour and that another method called something like 'getRawName' be added > to the FileItem class. The rational for this change is to make it less easy > to shoot oneself in the foot (in no modern web application is a 'full > filepath' useful, especially when most browsers do not send one!). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FILEUPLOAD-193) FileNotFoundException thrown by DiskFileItem.write
[
https://issues.apache.org/jira/browse/FILEUPLOAD-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14207969#comment-14207969
]
Thomas Neidhart commented on FILEUPLOAD-193:
One reason for this to happen could be that the file is stored in memory, thus
the temporary file location is non-existant.
Analyzing the code, I can not see how this could happen, but can you please
attach the source-code of your servlet handling the upload?
> FileNotFoundException thrown by DiskFileItem.write
> --
>
> Key: FILEUPLOAD-193
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-193
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.2.2
> Environment: Ubuntu 10.10
> java version "1.6.0_24"
> Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
> Java HotSpot(TM) Client VM (build 19.1-b02, mixed mode, sharing)
>Reporter: Dan Washusen
>Priority: Critical
>
> Under certain conditions the DiskFileItem.write throws a FileNotFound
> exception. It seems to be when outputFile.renameTo(file) fails.
> {code}java.io.FileNotFoundException:
> /tmp/UploadController/uploading/upload_69651d04_13000a31964__8000_1651.tmp
> (No such file or directory)
> at java.io.FileInputStream.open(Native Method)
> at java.io.FileInputStream.(FileInputStream.java:106)
> at
> org.apache.commons.fileupload.disk.DiskFileItem.write(DiskFileItem.java:447)
> at upload.UploadController.handle(UploadController.java:90)
> ...{code}
> I can't see any obvious reason why the source file (outputFile) wouldn't
> exist...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (VFS-545) DefaultFilesCache leaks closed filesystems
Bernd Eckenfels created VFS-545: --- Summary: DefaultFilesCache leaks closed filesystems Key: VFS-545 URL: https://issues.apache.org/jira/browse/VFS-545 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0, 2.1 Reporter: Bernd Eckenfels Assignee: Bernd Eckenfels Priority: Minor The org.apache.commons.vfs2.cache.DefaultFilesCache does not remove the filesystem specific cache if a filesystem gets cleared. This leads to the problem that instances if the FileSystem kept alive after the FileProvider has closed the filesystem. This is not so much a problem for a smaller number of filesystems configured for a prefix, but it is a problem for layered or virtual filesystems which get created and destroyed. (See also VFS-544). The more advanced filesystem caches support clearing the keys (but have other races I think). The behaviour is somewhat documented "lifetime of the FileSystemManager", but I don't think it is expected or required. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (VFS-545) DefaultFilesCache leaks closed filesystems
[
https://issues.apache.org/jira/browse/VFS-545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208387#comment-14208387
]
Bernd Eckenfels commented on VFS-545:
-
My idea would be to simply use
{code}
public void clear(FileSystem filesystem)
{
Map files = filesystemCache.remove(filesystem);
files.clear(); // help GC
}
{code}
> DefaultFilesCache leaks closed filesystems
> --
>
> Key: VFS-545
> URL: https://issues.apache.org/jira/browse/VFS-545
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0, 2.1
>Reporter: Bernd Eckenfels
>Assignee: Bernd Eckenfels
>Priority: Minor
> Labels: leak
>
> The org.apache.commons.vfs2.cache.DefaultFilesCache does not remove the
> filesystem specific cache if a filesystem gets cleared. This leads to the
> problem that instances if the FileSystem kept alive after the FileProvider
> has closed the filesystem. This is not so much a problem for a smaller number
> of filesystems configured for a prefix, but it is a problem for layered or
> virtual filesystems which get created and destroyed. (See also VFS-544). The
> more advanced filesystem caches support clearing the keys (but have other
> races I think).
> The behaviour is somewhat documented "lifetime of the FileSystemManager", but
> I don't think it is expected or required.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (VALIDATOR-336) CUSIPCheckDigit Thinks Invalid CUSIP is Valid
[
https://issues.apache.org/jira/browse/VALIDATOR-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208450#comment-14208450
]
Peter Lindberg commented on VALIDATOR-336:
--
Benedikt:
There is some weird behavior with CUSIPCheckDigitTest and/or
AbstractCheckDigitTest: Elements in CUSIPCheckDigitTest.invalid are passed to
both calculate and isValid, in separate tests.
If the string contains a non-alphanumeric character, BOTH methods will throw
the "invalid character" exception, which is actually coming from the toInt
method.
However, if the string represents a code with an invalid checkdigit (e.g.
{{DUS0421CW}}), only isValid throws an exception, which is expected, because
calculate only determines what the checkdigit should be -- it does not
determine correctness.
Because of this behavior, {{DUS0421CW}} will pass testIsValidFalse, but it will
generate a failure for testCalculateInvalid.
I believe this is a bug, and I'll submit an issue for it when I get a chance.
A work-around would be to put the whole method testCheckDigitIsLetter from the
CusipValidatorTest_v2.java into CUSIPCheckDigitTest, but that is a little
messy, because it breaks the pattern of all the tests being in
AbstractCheckDigitTest. Thanks.
Regards,
Peter
> CUSIPCheckDigit Thinks Invalid CUSIP is Valid
> -
>
> Key: VALIDATOR-336
> URL: https://issues.apache.org/jira/browse/VALIDATOR-336
> Project: Commons Validator
> Issue Type: Bug
>Reporter: Josh Meyer
> Attachments: CUSIPCheckDigit.java.patch, CusipValidatorTest.java,
> CusipValidatorTest_v2.java, VALIDATOR-336.patch
>
>
> When testing if a specific CUSIP is valid using
> org.apache.commons.validator.routines.checkdigit.CUSIPCheckDigit.CUSIP_CHECK_DIGIT.isValid,
> a call to this returns true when it should return false. A specific example
> is with the following invalid CUSIP: DUS0421CW.
> What seems to be happening is when toInt is called on W it turns it to an int
> value and then sends it to weightedValue. This is fine for the first 8
> characters of a CUSIP, but not the check digit. The expected result should be
> to return false because the check digit is a letter (on a CUSIP a check digit
> must be 0-9).
> With the current implementation, I believe each CUSIP can have up to 4 valid
> check digits.
> A test is attached.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MATH-1162) contains(Region region) method of AbstractRegion throws NullPointerException exception
[
https://issues.apache.org/jira/browse/MATH-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208655#comment-14208655
]
Luc Maisonobe commented on MATH-1162:
-
I've made some progress in the analysis. The error is not in the
chopOffPlus/chopOffMinus methods but it occurs earlier in the BSP tree merging
phase. Debugging this is unfortunately quite hard. I hope I'll understand what
happens in the nexxt few days.
I don't think the second problem is similar to the first one you reported.
Could you open a separate JIRA issue for it?
> contains(Region region) method of AbstractRegion throws
> NullPointerException exception
> --
>
> Key: MATH-1162
> URL: https://issues.apache.org/jira/browse/MATH-1162
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.3
> Environment: tested on windows 8 and heroku
>Reporter: gün alppay
>
> the contains call on
> org.apache.commons.math3.geometry.partitioning.AbstractRegion throws an
> exception in the sample below:
> {noformat}
> import org.apache.commons.math3.geometry.partitioning.Region;
> import org.apache.commons.math3.geometry.euclidean.twod.Vector2D;
> import org.apache.commons.math3.geometry.euclidean.twod.Euclidean2D;
> import org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet;
> class Test {
> public static void main(String[] args) {
> Region p = new PolygonsSet( 1.0e-10, new
> Vector2D(4.26719996532, -11.928637756014894),
> new
> Vector2D(4.26720026445, -14.12360595809307),
> new
> Vector2D(9.14400273694, -14.12360595809307),
> new
> Vector2D(9.14400233383, -11.928637756020067));
> Region w = new PolygonsSet( 1.0e-10, new
> Vector2D(2.56735636510452512E-9, -11.933116461089332),
> new
> Vector2D(2.56735636510452512E-9, -12.393225665247766),
> new
> Vector2D(2.56735636510452512E-9, -27.785625665247778),
> new
> Vector2D(4.26720030211, -27.785625665247778),
> new
> Vector2D(4.26720030211, -11.933116461089332));
> p.contains(w);
> }
> }
> {noformat}
> the exception thrown is:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException
> at
> org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:263)
> at
> org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:267)
> at
> org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:267)
> at
> org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:267)
> at
> org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:267)
> at
> org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:267)
> at
> org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:267)
> at
> org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:251)
> at
> org.apache.commons.math3.geometry.partitioning.AbstractRegion.contains(AbstractRegion.java:295)
> at Test.main(test.java:19)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FILEUPLOAD-261) Streaming API fails with file size < 8k
Luca Looz created FILEUPLOAD-261:
Summary: Streaming API fails with file size < 8k
Key: FILEUPLOAD-261
URL: https://issues.apache.org/jira/browse/FILEUPLOAD-261
Project: Commons FileUpload
Issue Type: Bug
Affects Versions: 1.3.1
Reporter: Luca Looz
Priority: Critical
I'm getting a SocketTimeoutException when using the Streaming API and uploading
a file with a size smaller than 8k.
{code}
java.net.SocketTimeoutException
at java.net.PlainSocketImpl.read(PlainSocketImpl.java:491)
at java.net.PlainSocketImpl.access$000(PlainSocketImpl.java:46)
at
java.net.PlainSocketImpl$PlainSocketInputStream.read(PlainSocketImpl.java:240)
at java.io.PushbackInputStream.read(PushbackInputStream.java:185)
at
org.apache.commons.fileupload.MultipartStream$ItemInputStream.makeAvailable(MultipartStream.java:999)
at
org.apache.commons.fileupload.MultipartStream$ItemInputStream.read(MultipartStream.java:903)
at java.io.InputStream.read(InputStream.java:162)
at org.apache.commons.fileupload.util.Streams.copy(Streams.java:100)
at org.apache.commons.fileupload.util.Streams.copy(Streams.java:70)
at
org.apache.commons.fileupload.MultipartStream.readBodyData(MultipartStream.java:593)
at
org.apache.commons.fileupload.MultipartStream.discardBodyData(MultipartStream.java:617)
at
org.apache.commons.fileupload.MultipartStream.skipPreamble(MultipartStream.java:634)
at
org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.findNextItem(FileUploadBase.java:1023)
at
org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.(FileUploadBase.java:1003)
at
org.apache.commons.fileupload.FileUploadBase.getItemIterator(FileUploadBase.java:310)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (VFS-545) DefaultFilesCache leaks closed filesystems
[ https://issues.apache.org/jira/browse/VFS-545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated VFS-545: - Affects Version/s: (was: 2.1) > DefaultFilesCache leaks closed filesystems > -- > > Key: VFS-545 > URL: https://issues.apache.org/jira/browse/VFS-545 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Bernd Eckenfels >Assignee: Bernd Eckenfels >Priority: Minor > Labels: leak > > The org.apache.commons.vfs2.cache.DefaultFilesCache does not remove the > filesystem specific cache if a filesystem gets cleared. This leads to the > problem that instances if the FileSystem kept alive after the FileProvider > has closed the filesystem. This is not so much a problem for a smaller number > of filesystems configured for a prefix, but it is a problem for layered or > virtual filesystems which get created and destroyed. (See also VFS-544). The > more advanced filesystem caches support clearing the keys (but have other > races I think). > The behaviour is somewhat documented "lifetime of the FileSystemManager", but > I don't think it is expected or required. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
