Re: ProtocolEncoder not getting used in the response path

2016-10-25 Thread Murty Devarakonda

Thank you so much for accepting my suggestion and hope that helps the future
developers.  And thanks for your support over the past few days too!!!



--
View this message in context: 
http://apache-mina.10907.n7.nabble.com/ProtocolEncoder-not-getting-used-in-the-response-path-tp51558p51620.html
Sent from the Apache MINA User Forum mailing list archive at Nabble.com.


Re: ProtocolEncoder not getting used in the response path

2016-10-25 Thread Emmanuel Lécharny


Le 25/10/16 à 16:54, Murty Devarakonda a écrit :
> We could identify what the problem is at last.  While sending the response
> back to the client, we created a IoBuffer and added the bytes to the same
> and did a session.write().  And we identified that if the response is of
> type IoBuffer, Mina filter chain won't act on invoke the filters based on
> this line:
>
> ProtocolCodecFilter:filterWrite():
>
> // Bypass the encoding if the message is contained in a IoBuffer,
> // as it has already been encoded before
> if ((message instanceof IoBuffer) || (message instanceof
> FileRegion)) {
> nextFilter.filterWrite(session, writeRequest);
> return;
> }
>
> Somehow I missed that check and was scrambling why the filter is not getting
> used.  May be it might be helpful for future developers if this is
> documented properly.

Glad to see that you have found the origin of your trouble :-)

Yes, we can add some documentation that says that using an IoBuffer or a
FileRehion will result in the encoder to not been call. That would be
teh smart thing to do...


Thanks for the feedback !



Re: ProtocolEncoder not getting used in the response path

2016-10-25 Thread Murty Devarakonda
We could identify what the problem is at last.  While sending the response
back to the client, we created a IoBuffer and added the bytes to the same
and did a session.write().  And we identified that if the response is of
type IoBuffer, Mina filter chain won't act on invoke the filters based on
this line:

ProtocolCodecFilter:filterWrite():

// Bypass the encoding if the message is contained in a IoBuffer,
// as it has already been encoded before
if ((message instanceof IoBuffer) || (message instanceof
FileRegion)) {
nextFilter.filterWrite(session, writeRequest);
return;
}

Somehow I missed that check and was scrambling why the filter is not getting
used.  May be it might be helpful for future developers if this is
documented properly.



--
View this message in context: 
http://apache-mina.10907.n7.nabble.com/ProtocolEncoder-not-getting-used-in-the-response-path-tp51558p51618.html
Sent from the Apache MINA User Forum mailing list archive at Nabble.com.


Re: ProtocolEncoder not getting used in the response path

2016-10-24 Thread Murty Devarakonda
And not only that.  I am seeing that the filter for my ProtocolCodecFilter
also was not hit in the entry.getNextFilter() call.



--
View this message in context: 
http://apache-mina.10907.n7.nabble.com/ProtocolEncoder-not-getting-used-in-the-response-path-tp51558p51605.html
Sent from the Apache MINA User Forum mailing list archive at Nabble.com.


Re: ProtocolEncoder not getting used in the response path

2016-10-24 Thread Murty Devarakonda
O.K.  Some more progress.  While going through the debugger in the file
DefaultIoFilterChain.java and in the filterWrite method (line 734 and
remember I am in MINA version 2.0.5), I tried to inspect the nextFilter
argument and I got an exception in my eclipse:

com.sun.jdi.InvocationException occurred invoking method. 

I am looking into where this one popped out from.



--
View this message in context: 
http://apache-mina.10907.n7.nabble.com/ProtocolEncoder-not-getting-used-in-the-response-path-tp51558p51604.html
Sent from the Apache MINA User Forum mailing list archive at Nabble.com.


Re: ProtocolEncoder not getting used in the response path

2016-10-24 Thread Emmanuel Lécharny


Le 24/10/16 à 19:24, Murty Devarakonda a écrit :
> I did read that section to see where things may be going wrong and didn't see
> anything that's different than what we are doing.
>
> Now, to explain a bit about our project, so far the MINA server is listening
> on one port and protocol encoder and decoder seems to be working fine.
>
> Recently we changed this model so that our MINA server will start listening
> on two ports one for the old way or reading client requests and the new one
> for parsing the client data (using the protocol decoder and storing the same
> in the MINA session) before the client request is handed over to the MINA
> server.  
>
> In this new flow, I see that the ProtocolDecoder where I introduced the
> parsing of the client request to store few pieces of data in the MINA
> session is working fine.  And I could see that the request is successfully
> being processed and required response being generated. 
>
> The problem is, I don't see that the data that's getting written into the
> MINA write queue is being handed over to the ProtocolEncoder and the
> response reached the client successfully.
>
> One question to you is, is starting MINA to accept client connections on two
> ports wrong?  
No, it should work fine.

> So I don't think that's anything wrong after going through the
> MINA documentation.  So currently I have two of the independent:
>
> 1)  NioSocketAcceptors binding to two different ports
> 2) Two independent filter chains to support rules on the two different
> accepting ports
> 3) As part of the filters, two independent ProtocolCodecFactories that have
> their own ProtocolEncoder and ProtocolDecoder implementations.
>
> Do you think MINA server will not be able to process sessions that are bound
> to two different ports?

A session is created when a new client connect to the server. It's
unrelated to the fact they are bound to different port.

What is puzling is that the decoder is bing called, but not the encoder.
You should go through the codec filter when doing asession.write, but
again, I don't have yoru code under my eyes, so I can't teel you what
you are doing wrong...

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org



Re: ProtocolEncoder not getting used in the response path

2016-10-24 Thread Emmanuel Lécharny


Le 24/10/16 à 20:59, Murty Devarakonda a écrit :
> Thank you for the tip.  I looked into the NioSocketSession.filterChain and I
> could see my protocolcodecfactory object there.  Here is how I am adding the
> filters:
>
> protected static void addFilters(Properties props, NioSocketAcceptor
> acceptor, ProtocolCodecFactory factory)
> {
> DefaultIoFilterChainBuilder chain = acceptor.getFilterChain();
> String threadCountStr = props.getProperty("threads");
> int threadCount = threadCountStr == null ? s_threadCount :
> Integer.parseInt(threadCountStr.trim());
> chain.addLast("protocol", new ProtocolCodecFilter(factory));
> if (threadCount > 0) {
> ExecutorFilter filter = new ExecutorFilter(0, threadCount,
> s_timeout, TimeUnit.SECONDS);
> chain.addLast("limiter", filter);
> }
> }
>
> The above method is being shared to create filter chains for the old port as
> well as new port.  Do you think the name "protocol" is causing some
> conflicts?  As the same name "protocol" is being used to add the code filter
> factory for both instances of the acceptors?

The 'protocol' name is not a problem at all.



Re: ProtocolEncoder not getting used in the response path

2016-10-24 Thread Murty Devarakonda
Thank you for the tip.  I looked into the NioSocketSession.filterChain and I
could see my protocolcodecfactory object there.  Here is how I am adding the
filters:

protected static void addFilters(Properties props, NioSocketAcceptor
acceptor, ProtocolCodecFactory factory)
{
DefaultIoFilterChainBuilder chain = acceptor.getFilterChain();
String threadCountStr = props.getProperty("threads");
int threadCount = threadCountStr == null ? s_threadCount :
Integer.parseInt(threadCountStr.trim());
chain.addLast("protocol", new ProtocolCodecFilter(factory));
if (threadCount > 0) {
ExecutorFilter filter = new ExecutorFilter(0, threadCount,
s_timeout, TimeUnit.SECONDS);
chain.addLast("limiter", filter);
}
}

The above method is being shared to create filter chains for the old port as
well as new port.  Do you think the name "protocol" is causing some
conflicts?  As the same name "protocol" is being used to add the code filter
factory for both instances of the acceptors?



--
View this message in context: 
http://apache-mina.10907.n7.nabble.com/ProtocolEncoder-not-getting-used-in-the-response-path-tp51558p51601.html
Sent from the Apache MINA User Forum mailing list archive at Nabble.com.


Re: ProtocolEncoder not getting used in the response path

2016-10-24 Thread Murty Devarakonda
I did read that section to see where things may be going wrong and didn't see
anything that's different than what we are doing.

Now, to explain a bit about our project, so far the MINA server is listening
on one port and protocol encoder and decoder seems to be working fine.

Recently we changed this model so that our MINA server will start listening
on two ports one for the old way or reading client requests and the new one
for parsing the client data (using the protocol decoder and storing the same
in the MINA session) before the client request is handed over to the MINA
server.  

In this new flow, I see that the ProtocolDecoder where I introduced the
parsing of the client request to store few pieces of data in the MINA
session is working fine.  And I could see that the request is successfully
being processed and required response being generated. 

The problem is, I don't see that the data that's getting written into the
MINA write queue is being handed over to the ProtocolEncoder and the
response reached the client successfully.

One question to you is, is starting MINA to accept client connections on two
ports wrong?  So I don't think that's anything wrong after going through the
MINA documentation.  So currently I have two of the independent:

1)  NioSocketAcceptors binding to two different ports
2) Two independent filter chains to support rules on the two different
accepting ports
3) As part of the filters, two independent ProtocolCodecFactories that have
their own ProtocolEncoder and ProtocolDecoder implementations.

Do you think MINA server will not be able to process sessions that are bound
to two different ports?

Please let me know if you need further info/code snippets.



--
View this message in context: 
http://apache-mina.10907.n7.nabble.com/ProtocolEncoder-not-getting-used-in-the-response-path-tp51558p51597.html
Sent from the Apache MINA User Forum mailing list archive at Nabble.com.


Re: ProtocolEncoder not getting used in the response path

2016-10-24 Thread Emmanuel Lécharny


Le 24/10/16 à 19:12, Murty Devarakonda a écrit :
> Thanks for the reply.  I set the logging at the debug level for all the code
> in org.apache and didn't see any exceptions being thrown or any error
> messages.  I tried to debug the MINA code, but didn't get much clues from it
> in terms of any eye popping error flows.
The simplest way to debug MINA is, as suggested by Qingsong, is to put a
breakpoint in your IoHandler messageReceived() method, and step in where
you have a session.write(). You are going to step through some classes
that are just wrappers, but at some point, you should jump into your
encoder. If not, then that means your filter chain is not constructed
correctly.

You can check the session filterChain field, that contains the filter
list, to see if the codec filter is present.

Otherwise, without your code, it's hard to tell what is wrong...


Re: ProtocolEncoder not getting used in the response path

2016-10-24 Thread Murty Devarakonda
Thanks for the reply.  I set the logging at the debug level for all the code
in org.apache and didn't see any exceptions being thrown or any error
messages.  I tried to debug the MINA code, but didn't get much clues from it
in terms of any eye popping error flows.



--
View this message in context: 
http://apache-mina.10907.n7.nabble.com/ProtocolEncoder-not-getting-used-in-the-response-path-tp51558p51595.html
Sent from the Apache MINA User Forum mailing list archive at Nabble.com.


Re: ProtocolEncoder not getting used in the response path

2016-10-23 Thread Emmanuel Lécharny


Le 23/10/16 à 19:45, Murty Devarakonda a écrit :
> I wrote a custom Protocol Encoder implementing the ProtocolEncoder interface
> and I am using MINA 2.0.5 version.
Mina 2.0.5 is 4 years old. 2.0.16 is currently being release, I strongly
suggest you switch to this version taht will be out next week.
>
> But during testing, I am observing that the IoSession.write() call is not
> hitting the ProtocolEncoder at all.  What could be the reason for this?  I
> followed the creation of the ProtocolCodecFactory class correctly and my
> ProtocolDecoder is working correctly on the request path.  I am able to
> store some attributes in the IoSession and am able to make use of them in my
> request processing code.  
>
> While sending back the response, I would like to see my breakpoint in the
> debug session reaching the ProtocolEncoder and make the appropriate changes
> to the response before writing out the response.  
>
> Here is how my filter chain code is looking like:
>
> protected static void addFilters(Properties props, NioSocketAcceptor
> acceptor, ProtocolCodecFactory factory)
> {
> DefaultIoFilterChainBuilder chain = acceptor.getFilterChain();
> String threadCountStr = props.getProperty("threads");
> int threadCount = threadCountStr == null ? s_threadCount :
> Integer.parseInt(threadCountStr.trim());
> chain.addLast("protocol", new ProtocolCodecFilter(factory));
> if (threadCount > 0) {
> ExecutorFilter filter = new ExecutorFilter(0, threadCount,
> s_timeout, TimeUnit.SECONDS);
> chain.addLast("limiter", filter);
> }
> }
>
> Any help with this would be greatly appreciated.  I even tried logging the
> MINA related log lines at the debug level to see if there is an exception
> during response flow within MINA.  But there is no exceptions too.
The piece of code that you show does not tell a lot.

Hav you followed the
http://mina.apache.org/mina-project/userguide/ch9-codec-filter/ch9-codec-filter.html
page ?
>
>
>
> --
> View this message in context: 
> http://apache-mina.10907.n7.nabble.com/ProtocolEncoder-not-getting-used-in-the-response-path-tp51558.html
> Sent from the Apache MINA User Forum mailing list archive at Nabble.com.

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org



Re: ProtocolEncoder not getting used in the response path

2016-10-23 Thread 李庆松1
If you can't debug the filter, that means some exception is probably thrown 
before entering into the filter. So you can debug the process from the handler 
to the filter to check the point where exception happens.



> On 24 Oct 2016, at 3:11 AM, Murty Devarakonda  
> wrote:
> 
> I wrote a custom Protocol Encoder implementing the ProtocolEncoder interface
> and I am using MINA 2.0.5 version.
> 
> But during testing, I am observing that the IoSession.write() call is not
> hitting the ProtocolEncoder at all.  What could be the reason for this?  I
> followed the creation of the ProtocolCodecFactory class correctly and my
> ProtocolDecoder is working correctly on the request path.  I am able to
> store some attributes in the IoSession and am able to make use of them in my
> request processing code.  
> 
> While sending back the response, I would like to see my breakpoint in the
> debug session reaching the ProtocolEncoder and make the appropriate changes
> to the response before writing out the response.  
> 
> Here is how my filter chain code is looking like:
> 
> protected static void addFilters(Properties props, NioSocketAcceptor
> acceptor, ProtocolCodecFactory factory)
>{
>DefaultIoFilterChainBuilder chain = acceptor.getFilterChain();
>String threadCountStr = props.getProperty("threads");
>int threadCount = threadCountStr == null ? s_threadCount :
> Integer.parseInt(threadCountStr.trim());
>chain.addLast("protocol", new ProtocolCodecFilter(factory));
>if (threadCount > 0) {
>ExecutorFilter filter = new ExecutorFilter(0, threadCount,
> s_timeout, TimeUnit.SECONDS);
>chain.addLast("limiter", filter);
>}
>}
> 
> Any help with this would be greatly appreciated.  I even tried logging the
> MINA related log lines at the debug level to see if there is an exception
> during response flow within MINA.  But there is no exceptions too.
> 
> 
> 
> --
> View this message in context: 
> http://apache-mina.10907.n7.nabble.com/ProtocolEncoder-not-getting-used-in-the-response-path-tp51558.html
> Sent from the Apache MINA User Forum mailing list archive at Nabble.com.