Salut,
k_arun_in wrote:
> Hi,
>
> I am interested in a similar technique in Grizzly 1.x. i.e keep
> persistent connections and stream updates from another thread at later point
> in time. The example below explains how to do it in 2.0. It would be very
> helpful to get an example in 1.x. I am currently trying to understand
> SuspendableFitler and try to hack a solution from it.
Are you using a custom protocol or you are using http? If you are using
http, take a look at:
http://www.nabble.com/-ANN--New-HTTP-API-for-Resuming-Suspending-Request-Response-td20573149.html#a20573149
and some test case from here:
https://grizzly.dev.java.net/nonav/xref-test/com/sun/grizzly/http/SuspendTest.html
It makes it quite simple.
A+
-- Jeanfrancois
>
> Thanks in advance
> Arun
>
>
> Oleksiy Stashok wrote:
>> Hi Emit,
>>
>> I know Grizzly 2.0 is still under development, but think it will be
>> easier to do what you need with 2.0.
>> I'll try to give you some hints regarding 2.0, but if you prefer
>> Grizzly 1.x, let me know.
>>
>>> Hi, I'm evaluating grizzly for the first time by attempting
>>> to port over a small and simple TCP based server project
>>> that manages persistent client sessions which share a dynamic
>>> "world" state.
>>> I guess sort of like a simple sub/pub MQ, or perhaps a MUD server :P
>> ok.
>>
>>> The world's state changes fairly rapidly (= order of 10ms, maybe
>>> less..)
>>> but these updates need to be broadcast to only <50 clients on a very
>>> fast LAN...
>>> not a big deal, and straightforward to do in regular Java or C
>>> (actually I also
>>> did a prototype in erlang for kicks) --- but I am intrigued by both
>>> grizzly
>>> and mina(?) and like to experiment. :D
>> :)
>>
>>> Anyway, I'm just tracing through the sample standalone app and would
>>> like to know if it's possible to somehow have a designated thread
>>> outside of the whole workerthread/callback hierarchy
>>> push data to arbitrary clients/sockets?
>> You mean, you'll push some data from time to time from some custom
>> channel?
>>
>>> Right now in the sample program, it's basically pinging req/acks...
>>> now,
>>> if I wanted to send out some random message from the main thread, to
>>> for example, the second client while it's doing its own thing, what
>>> is the best
>>> way to get a handle to its outputstream?
>> Think this could be done following way:
>> 1) You can implement own LifeCycleFilter similar to [1], which will
>> track client connections, and keep the collection of active clients.
>> 2) In any other thread you can retrieve client Connection, from
>> LifeCycleFilter and call Connection.write(...). It's really easy. If
>> client is in non-blocking mode (default) - the message will be added
>> to asynchronous write queue, so you don't need to care about possible
>> simultaneous writes.
>>
>>
>>> Can I hold on to Context references outside the scope of execute's
>>> and other
>>> callback methods if I do incrementRefCount? Is this the proper way
>>> to keep
>>> a global directory of client sessions?
>> You can use Connections in Grizzly 2.0 to reference client connection.
>>
>>
>>> While the server will constantly stream new data to the clients,
>>> it's possible
>>> that the clients will at times make requests that the server needs to
>>> acknowledge. My concern is, if I maintain this ref to Context
>>> outside its
>>> initial point of reference, what is the proper thread safe way to
>>> use it so
>>> that writing a binary chunk won't interfere with the existing event
>>> handlers?
>> As I told Connections will use async write queue, so you dont need to
>> care.
>>
>>
>>> Also, at which point is it recommended that I grab hold of the
>>> client's IP
>>> address? I see the info is buried somewhere down from Context... I
>>> forget
>>> right now, but somewhere around SelectionKeyImpl.
>> I just added support for:
>> Connection.getRemoteAddress();
>> You can use it like:
>> SocketAddress address = ((TCPNIOConnection)
>> connection).getRemoteAddress();
>>
>> Thanks.
>> And let me know if you have questions.
>>
>> WBR,
>> Alexey.
>>
>> [1]
>> https://grizzly.dev.java.net/source/browse/grizzly/branches/2dot0/samples/framework-samples/src/main/java/org/glassfish/grizzly/samples/lifecycle/
>>>
>>>
>>> Regards,
>>> -Emit
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>>
>