activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <>
Subject Re: BlobMessage support for sending out-of-band BLOBs
Date Wed, 14 Mar 2007 15:59:16 GMT
On 3/14/07, Aleksi Kallio <> 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:


> 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




View raw message