>>>>> 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.
>>>
>>> So i suppose for me it's better to step back to 1.9 branch and use
>>> comet extension from there ?
>>> What do you think ?
>> Yes, currently it is the only way if you want to use comet.
>
> Well, my only purpose now is to simplify my server :)
> And according to docs comet extension allows me to create server
> with mimumal amount of coding.
> Maybe i'm too cnocentrated on comet and i'm wrong doing my job
> basing on comet extension?
Nono, you could be right. Comet just has more features, that could be
used with higher level API.
>>> Also i was able to implement prototype app on top of 2.0.0-m3, but
>>> expirienced following problems
>>>
>>> 1. using ab2 tool im fetching content from my PC and unable to run
>>> more than 50 simultaneuos clients. i was launchign ab2 on another PC
>>> 2. i was playing around with thread pools usign code below but had
>>> no luck :)
>>>
>>> final GrizzlyWebServer gws = new GrizzlyWebServer(4343);
>>> ((TCPNIOTransport)
>>> gws.getTransport()).setSelectorRunnersCount(10);
>>> gws.getTransport().setInternalThreadPool(new
>>> DefaultThreadPool(10, 100, Integer.MAX_VALUE, 30,
>>> TimeUnit.SECONDS));
>>> gws.getTransport().setWorkerThreadPool(new DefaultThreadPool(10,
>>> 200, Integer.MAX_VALUE, 30, TimeUnit.SECONDS));
>>
>> Can you pls. share your code?
>
> Yes sure. I'm attachin it to my response. Its single class that each
> second pushes current date to client's stream.
> I'm usign Grissly 2.0.0-m3
Ok, I'll give it a try a little bit later.
> There's another issue i forgot to mention With my current code i was
> unable to detect client disconnection and streaming
> was lasting forever regardless of actual client connected or not.
It's because PrintWriter.flush() doesn't throw any IOException,
according to what I see in PrintWriter sources you might need to call
PrintWriter.checkError() to see if any error occurred during flushing.
WBR,
Alexey.
>
>> Thanks.
>>
>> WBR,
>> Alexey.
>>
>>>
>>> Thnx for datails and your explanation.
>>>
>>>>
>>>>>
>>>>> 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
>>>>>
>>>
>>>
>>>
>>> --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
> <
> Main
> .java
> >---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net