Hello Alexey,
Thank you very much for the super quick response. Regarding ...
1) I think I should have given you a bit more info on this, this is what
happens on the server ...
--> Grizzly's SSLReadFilter provides my server Handler with a ByteBuffer
--> Server handler parses the ByteBuffer and hands it over to a business
processing tier (using custom server threads).
--> Meanwhile, Grizzly context is recycled
--> A thread from the Business processing tier (BPT) digests the message
asynchronously and produces a response
--> The BPT turns to Grizzly for handing over the response bytebuffer in an
async write.
--> The processes of parsing messages on read byte buffers, processing
parsed messages and writing them back to the network framework are
independent of each other. Eg. the server could be parsing a message M2 in
one BPT while writing M1 in another BPT.
Rephrasing the question, can I use the solution mentioned in
http://www.nabble.com/Asynchronous-Request-Processing-with-TCPIP-td18234121.html
while preserving my server's luxury of writing back to grizzly using a
context.getAsyncQueueWriter.write(byteBuffer) at its own time without
suspending the reads and other business processing?
2) Yes, I did mean the re-handshaking. It is done for every chunk of the
bytearray written synchronously using SSLOutputWriter.flushChannel() but,
the same is not done if I try to write asynchronously using an
AsyncQueueWriter.write() with SSL as the final write is handled by
TCPAsyncQueueWriter which passes the bytebuffer through the
WritePreprocessor and tries writing the resultant bytebuffer contents
directly to the channel without any checks for re-handshaking. I wanted to
know if it is left to the user to implement it in his/her own code for now?
Thanks & Regards,
Phani
Oleksiy Stashok wrote:
>
> Hello Phani,
>
>> I am working on using Grizzly for our server application which uses
>> SSLv3
>> and a custom binary application level protocol for client-server
>> talk. My
>> server side implementation of Grizzly and the problems I am facing are
>> similar to the ones in the thread below ...
>>
>> http://www.nabble.com/Asynchronous-Request-Processing-with-TCPIP-td18234121.html
>>
>> However I have some doubts before I implement the solution
>> recommended in
>> the thread ...
>>
>> I am going to implement both Async reads and writes on the server
>> side and
>> the problem with adopting the solution for this is that once I
>> suspend
>> execution of a ProtocolChain using the SuspendableFilter a call to
>> ctx.setKeyRegistrationState(KeyRegistrationState.NONE) is made,
>> correct me
>> if I am wrong but, as a result of this reads won't happen on the
>> channel. Is
>> there a way out for this? I do not want reads to be waiting on writes
>> caused by the previous read. I want reads and writes to be
>> independent of
>> each other.
> You're right. In your case you don't need to have
> ctx.setKeyRegistrationState(KeyRegistrationState.NONE), but just let
> channel to be re-registered for OP_READ.
>
>
>> Also, I see that in case of Async writes for SSL / TLS the final
>> channel
>> write happens in TCPAsyncQueueWriter.doWrite() using
>> channel.write(byteBuffer) call. I am supplying a write pre processor
>> to wrap
>> my bytes before sending them out but, the part to redo the broken
>> handshakes
>> before sending every chunk of bytes out to the channel as in
>> SSLOutputWriter.flushChannel() will be missing in TCPAsyncQueueWriter.
>> Please advice on how to work around this problem without drifting
>> away from
>> the framework code and classes. For now, I am thinking of
>> implementing a new
>> SSLAsyncQueueWriter.
> Can you pls. provide details what part, you think, is missed in
> AsyncWrite SSL preprocessor? You meant re-handshaking?
> If it's some common problem, we have to implement that in default
> Grizzly implementation and your help will be very appreciated!
>
> Thank you.
>
> WBR,
> Alexey.
>
>>
>>
>> Any help would be very much appreciated.
>>
>> Thanks & Regards,
>> Phani
>> --
>> View this message in context:
>> http://www.nabble.com/SSL-ARP-tp18381476p18381476.html
>> Sent from the Grizzly - Users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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/SSL-ARP-tp18381476p18382989.html
Sent from the Grizzly - Users mailing list archive at Nabble.com.