users@grizzly.java.net

Re: Fwd: StandaloneProcessor

From: Dean Pehrsson-Chapman <dean_at_p14n.com>
Date: Tue, 6 Aug 2013 20:56:49 +0100

Sure, I'm just interacting with an echo server (which is working fine) in a
synchronous way.

     // Create TCP transport
        final TCPNIOTransport transport =
                TCPNIOTransportBuilder.newInstance().build();

        transport.setProcessor(FilterChainBuilder.stateless().build());
        transport.configureStandalone(true);
        transport.start();

            Connection c = transport.connect(HOST, PORT).get();
            c.write(HeapBuffer.wrap("hello".getBytes()));
            ReadResult r = (ReadResult) c.read().get();

FilterChainContext.read() would work fine, but that means my transport,
once started, can only do a particular set of things (the things defined in
the filter). I am trying to bridge a legacy communication system into
grizzly. The server part works fine, but I think I may be trying to push a
square peg into a round hole with the client.

Cheers,
Dean


On 6 August 2013 15:47, Oleksiy Stashok <oleksiy.stashok_at_oracle.com> wrote:

> Hi Dean,
>
> can you pls. share your code or attach a simple example of what you're
> trying to achieve.
> Did you try FilterChainContext.read()?
>
> Thanks.
>
> WBR,
> Alexey.
>
>
> On 06.08.13 06:42, Dean Pehrsson-Chapman wrote:
>
> I tend to get a lot of
>
> java.lang.NullPointerException
> at org.glassfish.grizzly.asyncqueue.AsyncReadQueueRecord.isFinished
>
> I see a previous user who hit this issue was advised to use the filter
> method. My particular use case is to use the shiny new connection pool -
> how can a client grab a connection and do some work with a filter? I don't
> understand the thinking behind the architecture here.
>
> Any help gratefully received.
>
> Cheers,
> Dean
>
>
> ---------- Forwarded message ----------
> From: Dean Pehrsson-Chapman <dean_at_p14n.com>
> Date: 6 August 2013 10:16
> Subject: StandaloneProcessor
> To: users_at_grizzly.java.net
>
>
> Hi,
>
> After some fiddling about I've realised that synchronously using
>
> connection.read()
>
> doesn't work with a filter chain - the message is handled by the filter
> chain and not reported to connection.read. Setting the processor to be a
> StandaloneProcessor works fine, but that seems odd to me as now you can't
> take advantage of the filterchain mechanism. Is it correct to say that
> there are incompatible ways of doing sync client (or even async - a
> completion handler will never be called either) and async server?
>
> Or am I just doing it wrong?
>
> Cheers,
> Dean
>
>
>