Man that was fast! I was just wondering if I could do it and here you
go and implement it that fast wow....
The one down fall I see is that you would have to make sure that the
HTTP headers have been wrote to the channel before making the call.
Need to figure out how to do that. (maybe just flush the output
stream?)
Any ways I have allot of work to do before I get to that point. What
I'm looking to do is a OSGi HttpService implementation using grizzly.
For that all I really need is a ServletAdapter and the httpServer (I
think at this point I would like to expose the commet stuff as well).
So I'm still reading at this point as what you have will not quite
work the way the spec has it. I'm thinking I will need to rewrite the
ServletAdapter (modify it really) to do what I need for the OSGi
HttpService. The differences mostly have to do with the way you handle
contexts and there is a very specific way you have to resolve URL's ->
servlet/resource. (Oh this is something I'm more than willing to
contribute to grizzly it would be the light weight alternative to gfv3
and jetty for those that don't need JSP's or war file deployments)
For some of the things I have in mind for using this for having that
interface will come in very handy. (WebDEV and large image content).
But in all reality if I understand the underlying call that the method
uses (at least on Linux that is) this will reduce memory usage
(application memory usage) and let the OS manage doing the cache
(which Linux will do BTW actually it will use most if not all unused
memory for file system read cache)
Any ways looks like I found the right project and should get to work
on implementing it.
Oh let me know if
1) Would would like to have an OSGi HTTPService implementation as part
of Grizzly
2) What I would need to do for you to be able to accept it (I assume I
would need to sign a Sun contributor agreement)
Either way I will let you know how it is going and also drop you a
line if I run into issues.
Thanks
Richard
On Thu, Nov 13, 2008 at 4:55 PM, Jeanfrancois Arcand
<Jeanfrancois.Arcand_at_sun.com> wrote:
> Salut,
>
> Jeanfrancois Arcand wrote:
>>
>> Salut,
>>
>> Richard Jackson wrote:
>>>
>>> I'm just starting to look at grizzly and trying to decide if I want to
>>> use it verses something else. So I've been looking at the api's and
>>> javadocs and samples. One thing I don't see covered is how you are
>>> actually serving static content. From browsing the javadoc it seems
>>> you are using the traditional approach (read the file in then write it
>>> out to the channel) as well as possibly caching the file data.
>>
>> Right. First request is serviced by reading the file, then the file is
>> mapped using native memory and the reference cached. Next all requests got
>> serviced from the cache. The class to look at are:
>>
>> StaticResourceAdapter
>>
>>>
>>> https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/tcp/StaticResourcesAdapter.html
>>
>> FileCache
>>
>>>
>>> https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/http/FileCache.html
>>
>>
>> Why not
>>>
>>> let the OS do that for you? Take a look at this article
>>> http://www.ibm.com/developerworks/linux/library/j-zerocopy/index.html
>>
>> That's look promising.
>>
>>
>>>
>>> I'm not sure if the approach described works on all platforms but the
>>> question I have is can I get at the channel and do it myself when
>>> using a GrizzlyWebServer?
>>
>> Yes you can probably do that by doing (this is ugly)
>>
>> ((SocketChannelOutputBuffer)response.getOutputBuffer()).getChannel();
>>
>>
>> https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/tcp/Response.html#178
>>
>> https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/http/SocketChannelOutputBuffer.html#123
>>
>> I've filled:
>>
>> https://grizzly.dev.java.net/issues/show_bug.cgi?id=319
>
> Fixed. That will be part of our next release (1.9.0) and available right now
> using the SNAPSHOT/uploaded build from here:
>
> http://download.java.net/maven/2/com/sun/grizzly/
>
> Make sure you read the API documentation. In short, if you manipulate the
> SocketChannel, you must make sure you either let Grizzly handle the http
> headers, or handle it by yourself.
>
> https://grizzly.dev.java.net/nonav/apidocs/com/sun/grizzly/tcp/Response.html
>
> (uploading the new html now so refresh in a couple of min)
>
> Let me know how it goes.
>
> A+
>
> -- Jeanfrancois
>
>
>>
>> And will add a new API on the Request/Response object called getChannel so
>> you can take advantages of it. I should have it later this week or Monday
>> for sure.
>>
>> Thanks
>>
>> -- Jeanfrancois
>>
>>
>>
>>>
>>> Thanks
>>> Richard
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>