On 3/14/07, Aleksi Kallio <[EMAIL PROTECTED]> wrote:
>> I had a bit of a look at the Jetty code and it doesn't seem to have a
>> simple 'file servlet' for supporting GET/PUT/DELETE of files in a
>> directory; so I was thinking we could contribute one to the Jetty6
>> tree and reuse that. e.g. maybe use the DefaultServlet in Jetty (which
>> does GET fine) then add PUT/DELETE support

I have this working (upload, download, remove) and have tested it with
files in the order of a couple of gigabytes.


wow great!

I'd have two questions, all input is appreciated...


1) I'm currently using standard Java URL / HttpURLConnection stuff to
connect to the web server. Unfortunately there is a bug or design issue
that makes HttpURLConnection to load everything into memory:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5026745
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4212479


bugger!

That is definitely not appropriate for our purposes. Currently you can
also use chunked transfer mode
(HttpUrlConnection.setChunkedStreamingMode()) and it works well with
Jetty. However not all HTTP servers support this mode, I don't know if
it is an issue. The bigger issue is that the method only exists in Java
1.5. In other words, it is not usable in the ActiveMQ context?


ActiveMQ 5.x will depend on java 5 anyways so I think you are safe!

I think the only solution would be to use some other HTTP package,
probably commons-http. Or do you see some other workarounds? Personally
I would have preferred if the thing would have not required anything but
standard JRE classes. Unfortunately it seems impossible, unless one
writes the HTTP code from scratch, which does not sound like a clever
thing to do.


I agree, lets just use HttpUrlConnection with chunking for now.  If we
need to backport to older jvm versions, then we could just detect that
chunking is not available and the down side would just be you have the
load everything into memory.


2) While storing files to an intermediary file server they are named
after their message ID's. Is that wise? Message ID's look a bit unfit
for filenames. Do you think in some environments/FS's these kind of
names might cause problems?


It can/will.  I would suggest that the servlet that creats/loads the
files do some sort of name encoding so that it is safe for the file
system.




--
Regards,
Hiram

Blog: http://hiramchirino.com

Reply via email to