I'm using the FileUpload library and running into a very odd issue that I can't
seem to track down. I stepped through some of the FileUpload code and had to
abandon that for a while as it looked like it would take a considerable amount
of time to figure it out that way.
Here's what I'm doing. I
;ll try a few others though to see if it
happens the same way with those.
-bp
On Oct 4, 2010, at 2:53 PM, Christopher Schultz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Brian,
>
> On 10/4/2010 11:43 AM, Brian Pontarelli wrote:
>> I figured that the o
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Brian,
>
> On 10/4/2010 11:43 AM, Brian Pontarelli wrote:
>> I figured that the original File and the File written out by the
>> FileUpload would have different bytes at the start or end and it was
>> my mo
At first I thought the lengths were different, but that was actually in a much
more complex set of tests. I wrote the test code below after my first post to
the list.
Here's what that code is doing:
The lengths are the same, but the byte at position 305 is -1 rather than -66.
The answers to yo
I wanted to close this thread out. I figured out the issue. My stream wasn't
correctly converting the bytes to ints. It needed to shift the bits so that if
the byte FF was encountered it wasn't returned as -1, but as 255. In fact, all
negative bytes were probably causing issues. The fix was to c
The code and HTML look good. I've gotten that message a number of times and
what it generally means is that the request body isn't properly formatted. More
specifically, when the MultipartStream is asking the underlying stream (in this
case the ServletInputStream) for more bytes it returns -1 si
I would assume once you get out of the autoboxing caches the performance will
get even worse. It really depends on the application, but I've found a number
of spots where primitive collections work much better than autoboxing and JDK
collections.
-bp
On Nov 2, 2010, at 11:25 AM, James Carman
The autoboxing process mostly. When ints are autoboxed and unboxed, there is a
performance hit because it does method invocations and instantiation.
Autoboxing for some values will hit a cache to reduce instantiation overhead,
but I think that is only for numbers < 256.
I've found that Lists,
I probably wouldn't use these collections in a factory context. If I'm
concerned about speed and size, I'm going to create the primitive collection
using the constructor and then use it directly. Adding in any factories, AOP,
etc. is just going to add overhead.
The original issue is really whe
