Hello Phani,
I've just tried to create own stress client to stress the server
similar to yours.
Didn't see any problem. Though my client doesn't simulate rehandshake...
Just wanted to ask some additional things:
1) Does the server work fine in non-AsyncWrite mode?
2) ClosedChannelException you see... does it have any influence on
client processing? I mean, if you see this exception happened on
server, does the client also considered this as error? Because it
could be just situation, when client silently closed the connection at
the time, when server tried to sent something? So on server you may
see the exception, but it doesn't have any impact on a client.
Also I can propose several changes to your impl.
1) Split SSLReadFilter and your custom Filter. IMHO there is no reason
for your Filter to extend SSLReadFilter, as it basically doesn't
extend any of it functionality, it's just different filter :)
2) remove synchronized (lockObject). I understand, that you probably
thought it could be the reason of exception you see... but, IMHO, it's
not.
3) don't use SSLSession to hold the attribute. IMHO, it's not possible
to rely on that. Use following instead:
AttributeHolder holder = (AttributeHolder)
selectionKey.attachment();
Object obj =
holder.getAttribute(ServerConnectionHandler.class.getName());
if (obj == null || !(obj instanceof
ServerConnectionHandler)) {
SSLSelectorHandler selectorHandler =
(SSLSelectorHandler) context.getSelectorHandler();
conHandler = new
ServerConnectionHandler(selectorHandler, selectionKey, (SocketChannel)
selectionKey.channel(), engine);
server.addConHandler(conHandler);
holder.setAttribute(ServerConnectionHandler.class.getName(),
conHandler);
} else {
conHandler = (ServerConnectionHandler) obj;
}
4) AsyncQueueWriter you implemented, is not really async, as it uses:
SSLOutputWriter.flushChannel((SelectableChannel) channel,
byteBuffer, ByteBuffer.allocate(Math.max(GRIZZLY_DEFAULT_OUTPUT_BB_SIZE,
sslEngine.getSession().getPacketBufferSize())), sslEngine);
But seems it makes sense to work on improvement, just after the
main issue will be fixed.
Thanks.
WBR,
Alexey.
On Jul 24, 2008, at 11:52 , PhaKuDi wrote:
>
> Hi Alexey,
>
> For you to be able to run the stress client you will need the complete
> server. Since both are Java Applications I am forbidden from giving
> you the
> full sources or the binary. Also, it is going to be a tedious task
> to strip
> down the stress client to provide you a sample.
>
> Broadly, the architecture of the stress setup is - a (multi-
> threaded) stress
> manager holds several instances of the stress client (threads) which
> connect
> to the target server and keep pumping requests and sometimes even
> construct
> their future requests based on the response they receive i.e., the
> stress
> clients are stateful and not just dummies.
>
> I would appreciate it if you could provide your valuable comments on
> the
> server side Grizzly (only) code I have provided.
>
> Thanks & Regards,
> Phani
>
>
> Oleksiy Stashok wrote:
>>
>> Hi,
>> basically I don't need client source code.
>> If stress client is some binary app. - it's even better, I'll not
>> need
>> to bother with the sources.
>> Just want to have the same stress environment as you have and see
>> what
>> could cause the problems.
>>
>> Thanks.
>>
>> WBR,
>> Alexey.
>>
>>
>> On Jul 23, 2008, at 15:07 , PhaKuDi wrote:
>>
>>>
>>> Hello Alexey,
>>>
>>> We are working on changing only the server side network IO part of
>>> our
>>> product and are letting the client remain untouched. We are
>>> evaluating other
>>> NIO frameworks in parallel and have been able to run the stress
>>> clients
>>> successfully without any changes on "Apache Mina" and "NIO
>>> Framework" server
>>> implementations apart from the existing custom SSL Socket
>>> implementation.
>>> This is why I concluded that issue is with my server code rather
>>> than the
>>> stress clients. Please do let me know if you absolutely need the
>>> stress
>>> client code.
>>>
>>> Thanks & Regards,
>>> Phani
>>>
>>>
>>> Oleksiy Stashok wrote:
>>>>
>>>> Hello Phani,
>>>>
>>>> I'll take a look, could you also share the stress tester code?
>>>>
>>>> Thanks.
>>>>
>>>> WBR,
>>>> Alexey.
>>>>
>>>> On Jul 22, 2008, at 14:42 , PhaKuDi wrote:
>>>>
>>>>>
>>>>> Hi Alexey,
>>>>>
>>>>> I have made the ProtocolFilter thread safe. Yet the connection
>>>>> failures
>>>>> persist. It is probably something I am missing. Please find the
>>>>> latest
>>>>> source code of my Grizzly related classes in the attached zip
>>>>> file.
>>>>> All help
>>>>> will be appreciated.
>>>>>
>>>>> http://www.nabble.com/file/p18587446/src.zip src.zip
>>>>>
>>>>> Thanks & Regards,
>>>>> Phani
>>>>>
>>>>>
>>>>> Oleksiy Stashok wrote:
>>>>>>
>>>>>> Ok, Phani,
>>>>>>
>>>>>> just let us know, once you'll have any results.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> WBR,
>>>>>> Alexey.
>>>>>>
>>>>>> On Jul 17, 2008, at 12:11 , PhaKuDi wrote:
>>>>>>
>>>>>>>
>>>>>>> Hi Alexey,
>>>>>>>
>>>>>>> Looking back at MySSLReadFilter I think I have found the
>>>>>>> problem -
>>>>>>> it is not
>>>>>>> exactly thread safe.
>>>>>>>
>>>>>>> I will fix it and get back to you in case I have some real
>>>>>>> issues.
>>>>>>> Sorry
>>>>>>> about the false alarm.
>>>>>>>
>>>>>>> Thanks!
>>>>>>> Phani
>>>>>>>
>>>>>>>
>>>>>>> PhaKuDi wrote:
>>>>>>>>
>>>>>>>> Hi Alexey,
>>>>>>>>
>>>>>>>> Please find the source files in the zip file attached.
>>>>>>>>
>>>>>>>> http://www.nabble.com/file/p18503031/src.zip src.zip
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Phani
>>>>>>>>
>>>>>>>>
>>>>>>>> Oleksiy Stashok wrote:
>>>>>>>>>
>>>>>>>>> Hello Phani,
>>>>>>>>>
>>>>>>>>> can you pls. send the complete java sources of Grizzly related
>>>>>>>>> classes, it could be easier to read the code.
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> WBR,
>>>>>>>>> Alexey.
>>>>>>>>>
>>>>>>>>> On Jul 16, 2008, at 8:55 , PhaKuDi wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hello Alexey,
>>>>>>>>>>
>>>>>>>>>> My apologies for the delay in responding. Regarding ...
>>>>>>>>>>
>>>>>>>>>> 1) Thanks for the confirmation. Getting hold of async writer
>>>>>>>>>> from
>>>>>>>>>> the
>>>>>>>>>> selector handler is the right way to go for me.
>>>>>>>>>> 2) Just using a SSLWritePreprocessor isn't helping me. Have
>>>>>>>>>> tested
>>>>>>>>>> with the
>>>>>>>>>> re-handshaking code and it works for me.
>>>>>>>>>>
>>>>>>>>>> Also, now that I am stress testing the server I am running
>>>>>>>>>> into a
>>>>>>>>>> few
>>>>>>>>>> problems. I would very much appreciate your suggestions/
>>>>>>>>>> comments on
>>>>>>>>>> these
>>>>>>>>>> issues. The server in question currently is capable of
>>>>>>>>>> catering
>>>>>>>>>> to
>>>>>>>>>> about
>>>>>>>>>> 4000 clients during peak times and uses a C library for SSL
>>>>>>>>>> communication
>>>>>>>>>> with the clients. We are in the process of moving it to an
>>>>>>>>>> NIO
>>>>>>>>>> based
>>>>>>>>>> framework with minimal impact on existing design. My
>>>>>>>>>> implementation of
>>>>>>>>>> Grizzly is as below ...
>>>>>>>>>>
>>>>>>>>>> --> Server initalizes the controller as follows ...
>>>>>>>>>>
>>>>>>>>>> SSLReadFilter sslReadFilter = new
>>>>>>>>>> MySSLReadFilter(gameServer,
>>>>>>>>>> USE_GRIZZLY_ASYNC_READS);
>>>>>>>>>> sslReadFilter.setSSLContext(context);
>>>>>>>>>> final ProtocolChain protocolChain = new
>>>>>>>>>> DefaultProtocolChain();
>>>>>>>>>> protocolChain.addFilter(sslReadFilter);
>>>>>>>>>> ProtocolChainInstanceHandler chainInstanceHandler =
>>>>>>>>>> new
>>>>>>>>>> DefaultProtocolChainInstanceHandler() {
>>>>>>>>>> public ProtocolChain poll() {
>>>>>>>>>> return protocolChain;
>>>>>>>>>> }
>>>>>>>>>> };
>>>>>>>>>> Controller controller = new Controller();
>>>>>>>>>> controller.setHandleReadWriteConcurrently(true);
>>>>>>>>>> SSLSelectorHandler selectorHandler = new
>>>>>>>>>> MySSLSelectorHandler();
>>>>>>>>>> selectorHandler.setPort(port);
>>>>>>>>>> controller.setSelectorHandler(selectorHandler);
>>>>>>>>>>
>>>>>>>>>> controller
>>>>>>>>>> .setProtocolChainInstanceHandler(chainInstanceHandler);
>>>>>>>>>>
>>>>>>>>>> controller
>>>>>>>>>> .setReadThreadsCount(GRIZZLY_READ_THREADS_COUNT); //
>>>>>>>>>> Currently set to 0
>>>>>>>>>> OutputWriter.setDefaultWriteTimeout(5000);
>>>>>>>>>> controller.start();
>>>>>>>>>>
>>>>>>>>>> --> MySSLReadFilter.execute() method does ...
>>>>>>>>>>
>>>>>>>>>> super.execute(context);
>>>>>>>>>> engine = workerThread.getSSLEngine();
>>>>>>>>>> session = engine.getSession();
>>>>>>>>>> Object obj =
>>>>>>>>>> session.getValue(ServerConHandler.class.getName());
>>>>>>>>>> ServerConHandler conHandler;
>>>>>>>>>> if (obj == null || !(obj instanceof ServerConHandler)) {
>>>>>>>>>> SSLSelectorHandler selectorHandler =
>>>>>>>>>> (SSLSelectorHandler)
>>>>>>>>>> context.getSelectorHandler();
>>>>>>>>>> conHandler = new ServerConHandler(selectorHandler,
>>>>>>>>>> selectionKey,
>>>>>>>>>> (SocketChannel) selectionKey.channel(), engine, user);
>>>>>>>>>> session.putValue(ServerConHandler.class.getName(),
>>>>>>>>>> conHandler);
>>>>>>>>>> } else {
>>>>>>>>>> conHandler = (ServerConHandler) obj;
>>>>>>>>>> }
>>>>>>>>>> conHandler.read(workerThread.getByteBuffer());
>>>>>>>>>>
>>>>>>>>>> --> MySSLSelectorHandler does ...
>>>>>>>>>>
>>>>>>>>>> public void preSelect(Context ctx) throws IOException {
>>>>>>>>>> if (asyncQueueWriter == null) {
>>>>>>>>>> asyncQueueWriter = new MySSLAsyncQueueWriter(this);
>>>>>>>>>> }
>>>>>>>>>> super.preSelect(ctx);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> --> ServerConHandler on receiving a write request does ...
>>>>>>>>>>
>>>>>>>>>> try {
>>>>>>>>>> MySSLAsyncQueueWriter writer =
>>>>>>>>>> (MySSLAsyncQueueWriter)
>>>>>>>>>> selectorHandler.getAsyncQueueWriter();
>>>>>>>>>> writer.write(selectionKey,
>>>>>>>>>> ByteBuffer.wrap(b1),
>>>>>>>>>> sslEngine);
>>>>>>>>>> } catch (ClosedChannelException e) {
>>>>>>>>>> logger.error(e.getMessage());
>>>>>>>>>> } catch (IOException e) {
>>>>>>>>>> logger.error(e.getMessage());
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> --> MySSLAsyncQueueWriter does ...
>>>>>>>>>>
>>>>>>>>>> public void write(SelectionKey key, ByteBuffer buffer,
>>>>>>>>>> SSLEngine
>>>>>>>>>> sslEngine) throws IOException {
>>>>>>>>>> ChannelRegistrationRecord record =
>>>>>>>>>> channelRegistrationMap.putIfAbsent(key.channel(), new
>>>>>>>>>> ChannelRegistrationRecord(sslEngine));
>>>>>>>>>> if (record != null) {
>>>>>>>>>> record.writeCount.incrementAndGet();
>>>>>>>>>> }
>>>>>>>>>> super.write(key, buffer);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> protected void doWrite(WritableByteChannel channel,
>>>>>>>>>> SocketAddress
>>>>>>>>>> dstAddress, ByteBuffer byteBuffer) throws IOException {
>>>>>>>>>> SSLEngine sslEngine;
>>>>>>>>>> ChannelRegistrationRecord record =
>>>>>>>>>> channelRegistrationMap.get(channel);
>>>>>>>>>> if (record == null) {
>>>>>>>>>> logger.error("Channel is not registered for an async
>>>>>>>>>> write");
>>>>>>>>>> return;
>>>>>>>>>> }
>>>>>>>>>> sslEngine = record.sslEngine;
>>>>>>>>>> if (sslEngine == null) {
>>>>>>>>>> logger.error("SSLEngine is null.");
>>>>>>>>>> return;
>>>>>>>>>> }
>>>>>>>>>> if (record.writeCount.intValue() > 200) {
>>>>>>>>>> ((SocketChannel)channel).socket().close();
>>>>>>>>>> channel.close();
>>>>>>>>>> channelRegistrationMap.remove(channel);
>>>>>>>>>> return;
>>>>>>>>>> }
>>>>>>>>>> if (record.writeCount.decrementAndGet() == 0) {
>>>>>>>>>> channelRegistrationMap.remove(channel);
>>>>>>>>>> }
>>>>>>>>>> SSLOutputWriter.flushChannel((SelectableChannel) channel,
>>>>>>>>>> byteBuffer,
>>>>>>>>>> ByteBuffer.allocate(Math.max(GRIZZLY_DEFAULT_OUTPUT_BB_SIZE,
>>>>>>>>>> sslEngine.getSession().getPacketBufferSize())), sslEngine);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The issues we are observing are ...
>>>>>>>>>>
>>>>>>>>>> --> As the number of concurrent connections shoots up to a
>>>>>>>>>> number
>>>>>>>>>> above 200
>>>>>>>>>> the stress clients start facing disconnections and following
>>>>>>>>>> exceptions are
>>>>>>>>>> seen on the server side.
>>>>>>>>>>
>>>>>>>>>> java.nio.channels.ClosedChannelException
>>>>>>>>>> at
>>>>>>>>>> sun
>>>>>>>>>> .nio
>>>>>>>>>> .ch.SocketChannelImpl.ensureWriteOpen(SocketChannelImpl.java:
>>>>>>>>>> 125)
>>>>>>>>>> at
>>>>>>>>>> sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:
>>>>>>>>>> 294)
>>>>>>>>>> at
>>>>>>>>>> com
>>>>>>>>>> .sun
>>>>>>>>>> .grizzly.util.OutputWriter.flushChannel(OutputWriter.java:
>>>>>>>>>> 105)
>>>>>>>>>> at
>>>>>>>>>> com
>>>>>>>>>> .sun
>>>>>>>>>> .grizzly.util.OutputWriter.flushChannel(OutputWriter.java:
>>>>>>>>>> 73)
>>>>>>>>>> at
>>>>>>>>>> com
>>>>>>>>>> .sun
>>>>>>>>>> .grizzly
>>>>>>>>>> .util.SSLOutputWriter.flushChannel(SSLOutputWriter.java:
>>>>>>>>>> 100)
>>>>>>>>>> at
>>>>>>>>>> com
>>>>>>>>>> .my
>>>>>>>>>> .server
>>>>>>>>>> .grizzly
>>>>>>>>>> .MySSLAsyncQueueWriter.doWrite(MySSLAsyncQueueWriter.java:
>>>>>>>>>> 70)
>>>>>>>>>> at
>>>>>>>>>> com
>>>>>>>>>> .sun
>>>>>>>>>> .grizzly
>>>>>>>>>> .async
>>>>>>>>>> .AbstractAsyncQueueWriter
>>>>>>>>>> .doWrite(AbstractAsyncQueueWriter.java:
>>>>>>>>>> 374)
>>>>>>>>>> at
>>>>>>>>>> com
>>>>>>>>>> .sun
>>>>>>>>>> .grizzly
>>>>>>>>>> .async
>>>>>>>>>> .AbstractAsyncQueueWriter
>>>>>>>>>> .onWrite(AbstractAsyncQueueWriter.java:
>>>>>>>>>> 291)
>>>>>>>>>> at
>>>>>>>>>> com
>>>>>>>>>> .sun
>>>>>>>>>> .grizzly
>>>>>>>>>> .async
>>>>>>>>>> .AsyncQueueWriterContextTask
>>>>>>>>>> .doCall(AsyncQueueWriterContextTask.java:
>>>>>>>>>> 86)
>>>>>>>>>> at
>>>>>>>>>> com
>>>>>>>>>> .sun
>>>>>>>>>> .grizzly
>>>>>>>>>> .SelectionKeyContextTask.call(SelectionKeyContextTask.java:
>>>>>>>>>> 56)
>>>>>>>>>> at
>>>>>>>>>> com
>>>>>>>>>> .sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:
>>>>>>>>>> 169)
>>>>>>>>>>
>>>>>>>>>> --> The CPU load on the 4 CPU machine shoots up to a 100%
>>>>>>>>>> consistently.
>>>>>>>>>> --> The memory graph shows no decline.
>>>>>>>>>>
>>>>>>>>>> I think it must be something that I am doing wrong. Also, I
>>>>>>>>>> wanted
>>>>>>>>>> to know
>>>>>>>>>> if Grizzly has been tested to scale up to 4000 ssl
>>>>>>>>>> connections
>>>>>>>>>> and
>>>>>>>>>> beyond if
>>>>>>>>>> required.
>>>>>>>>>>
>>>>>>>>>> Please feel free to revert in case you need some more
>>>>>>>>>> information.
>>>>>>>>>>
>>>>>>>>>> Thanks & Regards,
>>>>>>>>>> Phani
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Oleksiy Stashok wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> 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?
>>>>>>>>>>> Absolutely. Then, in your case I'm not sure you need to use
>>>>>>>>>>> SuspendFilter, as basically you don't want to suspend the
>>>>>>>>>>> connection -
>>>>>>>>>>> but keep it process other requests.
>>>>>>>>>>> Once your custom thread will complete the task execution -
>>>>>>>>>>> context
>>>>>>>>>>> will not be accessible anymore, as it was recycled by
>>>>>>>>>>> Grizzly
>>>>>>>>>>> worker
>>>>>>>>>>> thread, so you'll need to access async queue writer
>>>>>>>>>>> different
>>>>>>>>>>> way
>>>>>>>>>>> like:
>>>>>>>>>>> tcpSelectorHandler.getAsyncQueueWriter().write(SelectionKey,
>>>>>>>>>>> byteBuffer);
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> 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?
>>>>>>>>>>> you mean this part of SSLOutputWriter.flushChannel()?
>>>>>>>>>>> //--------------- Cut --------------------------
>>>>>>>>>>> case OK:
>>>>>>>>>>> if (result.getHandshakeStatus() ==
>>>>>>>>>>> HandshakeStatus.NEED_TASK) {
>>>>>>>>>>>
>>>>>>>>>>> SSLUtils.executeDelegatedTask(sslEngine);
>>>>>>>>>>> }
>>>>>>>>>>> break;
>>>>>>>>>>> //----------------------------------------------
>>>>>>>>>>> If yes, can I ask you to add the same lines to your SSL
>>>>>>>>>>> preprocessor
>>>>>>>>>>> to check whether it works for you - if yes - we'll fix
>>>>>>>>>>> that in
>>>>>>>>>>> Grizzly
>>>>>>>>>>> examples.
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>> WBR,
>>>>>>>>>>> Alexey.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> 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-tp18381476p18481339.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-tp18381476p18505329.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-tp18381476p18587446.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-tp18381476p18610365.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-tp18381476p18628607.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
>