Re: ProtocolEncoder not getting used in the response path
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
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.
Give Range of port - when starting sftpserver
Is there possibility to give range of ports between which Mina SSHD library always try to establish port-binding else fails? This is to make sure that certain ports are never taken by Apache MINA SSHD? Regards, Arpit.
Re: ProtocolEncoder not getting used in the response path
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
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
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
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
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
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.
