Hi Evgeny,
> Thanks for your responses. Unfortunately link goes to wrong test but
> i was able to find correct one.
> I will try to buidl my prototype basing on those examples. Alhtough
> i still has some questions
Oups, sorry :)
>
> 1. Is comet extension available at 2.0.0-m3 version ? If not - why ?
Not. Just because we didn't have time to port it :(
> 2. The purpose of my projecet has nothing to do with AsyncFilter and
> ARP ? I mean it can be imolemented without usign that technique ?
Well, it could use comet, which is working on top of ARP :)
I think ARP is really what you need for the usecase you described.
> 3. Where i can read more information about suspending / resuming
> request processing?
javadocs.
> What the physical sense both thosу operations have ?
if you want run some long/complex task and will do that in the current
thread servlet thread - it will mean, that your web server simult.
will be able to process N requests, where N equals to thread-pool
size, which is common limitation for sure, but for long tasks it will
mean that N requests will make web server non-responsible for long
time and no other requests will be able to be processed.
So for long/complex tasks you may want to run them in separate custom
threads to not occupy web server processing thread. But at this point
you need to say web server that you don't complete servlet processing,
but suspending it, so after returning from doGet or doPost method, web
server must not commit response or recycle ServletRequest/
ServletResponse and related context artifacts. Once long/complex task
will be completed in separate thread - you may use stored
ServletRequest/ServletResponse objects to continue servlet processing
and by calling resume() you allow next HTTP request to be processed on
this HTTP connection.
Hope this will help.
WBR,
Alexey.
>
> Thnx
>
>> Hi Evgeny,
>>
>> documentation is not our strong side, unfortunately :(
>> You can take a look to this unit test [1] specifically test name
>> testSuspendNoArgs();
>>
>> You can find there how we suspend a HTTP connection and then, after
>> some time send bytes and resume it.
>> So, in your case you can just not resume HTTP connection, so it
>> will stay suspended forever.
>>
>> In the example you may see, that we use StreamWriter to send a
>> response back:
>> res.getStreamWriter().writeXXX(...);
>>
>> the StreamWriter could be set to work either in blocking or non-
>> blocking mode. When working in non-blocking mode, Grizzly uses
>> async queue, which could be useful for you, though you've to be
>> careful with memory consumption in this case :)
>>
>> If you'll have any other questions - please ask.
>>
>> WBR,
>> Alexey.
>>
>> [1] https://grizzly.dev.java.net/source/browse/grizzly/branches/2dot0/code/modules/http/src/test/java/com/sun/grizzly/web/ArpSSLTest.java?view=markup
>>
>>> I have questions regarding implementation of my project.
>>> Recently i decided to use Grizzly as a base for my HTTP server.
>>> But after quite long looking into docs I can't understand how i can
>>> resolve my problem.
>>>
>>> Let me describe my project requrements.
>>>
>>>
>>> The idea is to buld application that serves media to relative big
>>> number
>>> clients (more >500).
>>> The specific features of clients' request are HTTP long-living
>>> nature.
>>> So once connected client permanently fetches content from server.
>>> Because simultaneous number of clients is high the blocking
>>> thread-per-request model is not appropriate.
>>>
>>> Our current approach consist of following steps and based on SRP.
>>> It's working OK but can't hold many connections.
>>>
>>> 1. client connects to endpoint, it has access to client's output
>>> stream
>>> 2. endpoint has blocking queue inside it and registers that queue
>>> in media
>>> manager
>>> to be notified about media events that should be streamed to
>>> underlying
>>> client.
>>> 3. HTTP connection should not break and be permanent -> client
>>> should
>>> never disconnect after it got connected to server.
>>> 4. inside endpoint in a loop look i'm performing blocking get from
>>> blocking queue to receive event from media manager
>>> that should be written to client's stream.
>>>
>>> So i've downloaded Grizzly 2.0.0-M3 and trying to write my NIO
>>> project.
>>> I was able to build simple HTTP server using GrizzlyWebServer
>>> class, and
>>> creating simple GrizzlyAdapter to server dummu content.
>>> But i'm unable to figure out how to build asynchronous HTTP write.
>>>
>>> Should i somehow use package com.sun.grizzly.asyncqueue ?
>>> Or maybe comet extension but comet is not available for 2.0.0-M3
>>> Or my task can be impleneted by leveraging AsyncFilter but i can't
>>> understand from tutorials how to implement pereodical asynchronous
>>> write
>>> to client
>>> without blocking thread.
>>>
>>> Can anyone give me advice on solving my problem.
>>>
>>>
>>> --Regards,
>>> Evgeny Shepelyuk
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>
>
>
>
> --
> Regards,
> Evgeny Shepelyuk
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>