Hi,
Ron Monzillo wrote:
>
> Jeanfrancois,
>
> I have been reading through some of the references, which seem quite
> interesting. I am mostly trying to understand web 2.0 and new
> opportunities for additional security mechanisms. so if you don't mind,
> I would like to ask questions every now and then, to help me understand
> things.
>
> so I was wondering, in your example of a gmail servlet filter, it says
>
>> Fortunately we can use JavaMail for (1), and Grizzly default ARP
>> implementation for (2) and (3), and by adding a new AsyncFilter
>> implementation. Then, we just have to:
>>
>> 1. Starts Grizzly using ARP mode.
>> 2. Create a JavaMail Session for Gmail to be used by the AsyncFilter.
>> 2. Deploy the Gmail war file. All the account information (username,
>> password, server url, port, etc.) are included inside web.xml (I agree
>> the password shouldn't be there).
>> 3. Use a browser to invoke the Servlet. The browser will keep the
>> connection openned until you receive a new email.
>> 4. When new emails are read, the Servlet will be executed and your
>> email information (headers, text) will be displayed.
>>
>> The implementation just consist of:
>
> on step 3, what is the cost of the open connection (on the server side)?
> is the connection bound to a thread, would it scale if multiple browsers
> were doing this at the same time?
The connection is not bound to a thread, thanks to NIO. GlassFish can
server a lot of connections with only 5 threads (this is the out of the
box configuration). The connection is bound to a SelectionKey. See:
http://weblogs.java.net/blog/jfarcand/archive/2006/06/tricks_and_tips.html
to a related explanation. The SelectionKey is the central piece when
working with NIO, where the Thread was the central piece with BIO
(blocking IO).
I honstly don't know the answers, and
> I am not trying to be critical, I am jut trying to understand how such
> an approach can deliver an async notification to a browser, if the
> browser is not holding a connection. Must there be a separate browser
> window for this to work?
Most probably it is not the browser that hold the connection, but
JavaScript (let's say in AJAX). Your AJAX component opens an http
connection and wait for even on it. If your AJAX component connect to a
server that support continuation (or Comet style request), then it will
open a single and gets notified when something changes. If the server is
not supporting continuation, then the AJAX component will have ping the
server every time it wants to update the content.
-- Jeanfrancois
>
> Ron
>
>
> Jeanfrancois Arcand wrote:
>> Hi,
>>
>> Tom Vaughan wrote:
>>
>>> Hi,
>>>
>>> If I wanted to add BEEP as a supported protocol in glassfish, where
>>> would people suggest I start to look to learn how to?
>>
>>
>> Cool....You should start looking at the Grizzly Comet implementation
>> described here:
>>
>> http://weblogs.java.net/blog/jfarcand/archive/2006/07/the_grizzly_com.html
>>
>>
>> Or you may want to start from scratch by extending the Grizzly
>> Asynchronous Request Processing mechanism (Grizzly Comet is build on
>> top of it):
>>
>> http://weblogs.java.net/blog/jfarcand/archive/2006/02/grizzly_part_ii.html
>>
>>
>> Under the hood, the BEEP protocol can be implemented in a similar way.
>> If you want to look at a simple extension of Grizzly ARP, look here:
>>
>> http://kasparov.skife.org/blog/src/java/grizzly-arp-basic.html
>>
>> Let me know if I can be of any help....
>>
>> Thanks
>>
>> -- Jeanfrancois
>>
>>
>> Thanks.
>>
>>>
>>> -Tom
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
>