On Jan 8, 2009, at 19:28 , Survivant 00 wrote:
> thanks
>
> so just to resume. the Thread will loop until the terminating
> sequence is found, and if the terminating sequence is not found in
> the message, it will put in back in the context and wait for the
> next message .. right ? (just to be sure)
Well, thread will not loop.
It will reuse NIO possibility to be notified, when additional data
will come.
Here is an example how you can use it.
We have following message format:
public static class TerminatingStringMessage {
private byte a;
@CharSequence(terminate="<eos>")
private String b;
private int c;
}
Server part in that case will look like this:
// Create TCP NIO transport
TCPNIOTransport transport =
TransportFactory.getInstance().createTCPTransport();
// Initialize smart Codec
SmartCodec smartCodec = new
SmartCodec(TerminatingStringMessage.class);
// Add filters to the chain
transport.getFilterChain().add(new TransportFilter());
transport.getFilterChain().add(new SmartFilter(smartCodec));
// ProcessorFilter works with TerminatingStringMessage, not with
Buffers
transport.getFilterChain().add(new MyProcessorFilter());
try {
// Bind server socket and start transport
transport.bind(PORT);
transport.start();
System.out.println("Press <enter> to exit...");
System.in.read();
} finally {
transport.stop();
TransportFactory.getInstance().close();
}
}
So you'll need to implement MyProcessorFilter, which deals with
TerminatingStringMessage:
public class MyProcessorFilter extends FilterAdapter {
@Override
public NextAction handleRead(FilterChainContext ctx,
NextAction nextAction) throws IOException {
TerminatingStringMessage message =
(TerminatingStringMessage ) ctx.getMessage();
// Working with message
..............................
return nextAction;
}
}
Client will look following:
Connection connection = null;
// Create TCP NIO transport
TCPNIOTransport transport =
TransportFactory.getInstance().createTCPTransport();
// Initialize smart Codec
SmartCodec smartCodec = new
SmartCodec(TerminatingStringMessage.class);
try {
// start transport
transport.start();
// Connect client to the server
ConnectFuture future = transport.connect(HOST, PORT);
connection = future.get(10, TimeUnit.SECONDS);
// Enable standalone mode for this connection
// (don't use Filter chains or other I/O event processors)
connection.setPreferableProcessorSelector(new
NullProcessorSelector());
// Initialize sample message
TerminatingStringMessage message = new
TerminatingStringMessage((byte) -1, "Test string", 10);
// Write message
Future<WriteResult> writeFuture =
connection.write(message, smartCodec.getEncoder());
writeFuture.get(10, TimeUnit.SECONDS);
.....................................................................
// Receive result back
Future<ReadResult> readFuture = connection.read(null,
smartCodec.getDecoder());
ReadResult result = readFuture.get(10, TimeUnit.SECONDS);
TerminatingStringMessage reply =
(TerminatingStringMessage) result.getMessage();
.....................................
Let me know, if you have questions.
WBR,
Alexey.
>
>
> 2009/1/8 Oleksiy Stashok <Oleksiy.Stashok_at_sun.com>
> Hi Sebastien,
>
> I've added this possibility.
> So now it's possible to annotate String message member following way:
>
> public static class TerminatingStringMessage {
> private byte a;
>
> @CharSequence(terminate="<eos>")
> private String b;
> private int c;
> }
>
> So the String will be encoded and decoded using "<eos>" as
> terminating sequence.
>
> Hope this will help you.
>
> WBR,
> Alexey.
>
>
> On Dec 17, 2008, at 14:00 , Survivant 00 wrote:
>
>> yes that will be enough.
>>
>> 2008/12/17 Oleksiy Stashok <Oleksiy.Stashok_at_sun.com>
>> Hi Sebastien,
>>
>>> that's really nice.
>>>
>>> is it possible to do the same thing with a variable length message ?
>>>
>>> you could have a annotation for the start (probably not needed) or
>>> the end of query.
>>>
>>> a message is completed when you found the eoq. and if you reach
>>> the max buffer size(annotation) you throw a Exception ?
>>> (maxBuffersize..)
>>>
>>> that will save me 200 lines of code for the parser in 1.x .
>> Agree.
>> This could be useful to have such a feature.
>> Actually I was thinking about implementing special Codec for
>> Strings, which have termination symbol or seq. of symbols like '\0'
>> or "<eos>. I think this could be enough for your protocol, right?
>>
>> WBR,
>> Alexey.
>>
>>>
>>>
>>>
>>>
>>> 2008/12/16 Oleksiy Stashok <Oleksiy.Stashok_at_sun.com>
>>>
>>> Hi Emit,
>>>
>>> coming back to your question, if it's not late...
>>>
>>> What is the best "grizzly 2.0" way to cut up the incoming stream
>>> into these logical packets of data, hopefully without editting
>>> the grizzly internal classes? I guess I can just aggregate
>>> these getMessage Buffers myself after the handleReads but in that
>>> case I don't see a reason to use this framework with all the
>>> overhead involved.
>>> Yesterday we've added new feature in Grizzly 2.0, which may help
>>> you with message parsing.
>>> Please take a look here [1]
>>>
>>> Thanks.
>>>
>>> WBR,
>>> Alexey.
>>>
>>> [1] http://www.nabble.com/Grizzly-2.0%3A-Smart-codec-td21033363.html#a21033363
>>>
>>>
>>>
>>> I think it would be helpful if you could show how to build upon
>>> the example EchoFilter to only echo back lines of text. i.e.
>>> '\n' would mark end of message, and a string would be the logical
>>> unit. (so even from windows telnet it will only echo back on new
>>> line, instead of on each character typed)
>>>
>>> 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
>>>
>>>
>>
>>
>
>