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.
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
>
>
>
--
View this message in context: http://www.nabble.com/sending-data-to-arbitrary-client-from-separate-thread-tp20820931p21552783.html
Sent from the Grizzly - Users mailing list archive at Nabble.com.