Thanks for the quick response,
I am looking at both custom protocol and http. I need support J2SE apps
running in the same LAN, planning to use "Bayeux/Comet" for it. I also need
to support J2ME apps using custom protocol on top of tcp.
Thanks
Arun
Jeanfrancois Arcand-2 wrote:
>
> 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
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>
>
--
View this message in context: http://www.nabble.com/sending-data-to-arbitrary-client-from-separate-thread-tp20820931p21554644.html
Sent from the Grizzly - Users mailing list archive at Nabble.com.