Thanks - this does make sense.
Coming full circle, I can make this approach work with the new connection
pool implementation if I use a Map (keyed on Connection) of BlockQueues,
does that sound right?
Cheers,
Dean
On 6 August 2013 22:18, Oleksiy Stashok <oleksiy.stashok_at_oracle.com> wrote:
> Hi Dean,
>
> I see what you mean.
> In general we suggest to not use standalone mode and it will be removed in
> Grizzly 3.
> We recommend to use FilterChain approach for the server- and the
> client-side code.
>
> With the server-side it's clear, right?
> But with the client-side code we used to have entire logic to be
> synchronous, like with Socket or HttpURLConnection, you send a request and
> want to read a response right away in the same thread. It's still possible
> to achieve this kind of behavior with Grizzly FilterChain.
>
> Here is a simple HTTP client example (not the real code):
>
> public class Client {
> private static final Object EOF_PACKET = new Object();
>
> private final TCPNIOTransport transport;
> private final BlockingQueue<Object> resultQueue = new
> LinkedTransferQueue<Object>();
>
> private final Object readSync = new Object();
>
> private boolean isClosed;
> private Connection connection;
>
> public Client() {
> final FilterChain clientFilterChain =
> FilterChainBuilder.stateless()
> .add(new TransportFilter())
> .add(new HttpClientFilter())
> .add(new BaseFilter() {
> @Override
> public NextAction handleRead(FilterChainContext
> ctx) throws IOException {
> resultQueue.add((HttpPacket) ctx.getMessage());
> return ctx.getStopAction();
> }
>
> @Override
> public NextAction handleClose(FilterChainContext
> ctx) throws IOException {
> resultQueue.add(EOF_PACKET);
> return ctx.getStopAction();
> }
> }).build();
>
> transport = TCPNIOTransportBuilder.newInstance()
> .setProcessor(clientFilterChain)
> .build();
> }
>
> public synchronized void connect(SocketAddress dstAddress)
> throws IOException {
> connection = transport.connect(dstAddress).get(10,
> TimeUnit.SECONDS);
> }
>
> public void write(HttpPacket httpPacket) {
> connection.write(httpPacket);
> }
>
> public HttpPacket read() throws IOException {
> synchronized (readSync) {
> if (!isClosed) {
> final Object packet = resultQueue.take();
> if (packet != EOF_PACKET) {
> return (HttpPacket) packet;
> }
>
> isClosed = true;
> }
>
> throw new EOFException("The connection is
> closed");
> }
> }
> }
>
> As I said it's not a complete code, but it can give you an idea how the
> FilterChain-based Client may look like.
>
> Hope that will help.
>
> WBR,
> Alexey.
>
>
> On 06.08.13 12:56, Dean Pehrsson-Chapman wrote:
>
> 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
>>
>>
>>
>
>