Re: My Mina server got hung!
Sure, will remember to make a thread dump next time it hangs... Thanks On 6/7/07, Trustin Lee <[EMAIL PROTECTED]> wrote: On 6/7/07, peter royal <[EMAIL PROTECTED]> wrote: > On Jun 6, 2007, at 6:44 PM, Paul Chen wrote: > > [2] When the traffic ramped up sharply lately, I begin to see it > > hung and I > > had to bounce > > it to revive it. > > Do a thread dump next time this happens. We can see what's going on > from that. http://mina.apache.org/reporting-a-bug.html Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
My Mina server got hung!
Hi, folks, It took me by surprise that one of our production Mina-based server running on Solaris10 hung, here is the story: [1] The Mina-based server was good in production for few months with light traffic, taking requests from all over the Internet. [2] When the traffic ramped up sharply lately, I begin to see it hung and I had to bounce it to revive it. [3] When it is hung, from the log I saw: Only sessionCreated() event was triggered, no other events were triggered at all, it stopped processing any new requests. Yes I do handle sessionIdle() event in my Mina handler. But even that Idle event was never tiggered. I just keep getting sessionCreated() event all the time, will try to bounce it to see if the threads are dead in the thread pool? Thanks for comments
Re: Permanent solution for OOM errors
Hi, folks,
Here is what I did to solve the OOM problem caused by writeRequest Queues
piling up
when many SocketConnector sessions bombard a service provider thus making
it very slow in responding.
It is the sum of all writeRequest queues that blows up the memory.
The idea is simple, but, alas, it is not that generic. But you get the idea
when reading
the code comments.
Not sure what's the best way/place to modify the Mina src to create global
views
across sessions?
Thanks for comments
package
import org.apache.mina.common.IoFilterAdapter;
import org.apache.mina.common.IoSession;
/**
* Prevent out of memory caused by output write queue piling up
*
* This filter is attached on a Mina SocketConnector session to:
*
* - Check outputQ quota of a service provider, the quota implicitly
indicates the max capacity of the
* service provider
*
* This filter complements the Mina ReadThrottleFilter which I attach to
each acceptor opened by my
* Mina-based server, and assign a max quota to each. I preconfigure them to
make sure the
* total of all acceptor quota values don't exceed my system memory limit.
*/
public class WriteThrottleFilter extends IoFilterAdapter {
/** Write a request to a service provider via a SocketConnector */
@Override
public void filterWrite(NextFilter nextFilter, IoSession session,
WriteRequest writeRequest) throws Exception {
// A codec turned it to my Request obj already
Request req = (Request) message;
int reqSize = req.size();
String svc = req.getServiceName();
// Check outputQ quota for the svc
//
// Make sure we don't exceed max capacity pre-configured for this
service provider
// There can be many SocketConnectors sending reqs to the service
provider. When
// it is slow, all write queues connected to this service pile up in
Mina. Thus I
// need a global view instead of a single
session.getScheduledWriteBytes()
if (reqSize + svcProviders.outQueueSize(svc) >
svcProviders.outQueueQuota(svc)) {
// Mark the service as busy, reply an error response to the
client
return;
}
svcProviders.incrOutQueue(svc, reqSize);
nextFilter.filterWrite(session, writeRequest);
}
} // End of class
On 5/3/07, Martin Ritchie <[EMAIL PROTECTED]> wrote:
That is great. I look forward to using the new filter as we have been
having a lot more OOM problems on our clients under load testing
(although that is as much a fault of the test app).
On 03/05/07, Vinod Panicker <[EMAIL PROTECTED]> wrote:
> I've already done that. It's being tested right now. We'll be
> contributing that as soon as we are happy about the performance under
> high load.
>
> On 5/2/07, Martin Ritchie <[EMAIL PROTECTED]> wrote:
> > On 30/04/07, Paul Chen <[EMAIL PROTECTED]> wrote:
> > > I'm refining that to make it more presentable and generic, will
publish
> > that
> > > in 1 week or 2.
> > >
> > > On 4/30/07, Gaston Dombiak <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hey Paul,
> > > >
> > > > That is exactly what I was planning to implement for our case. Can
you
> > > > send me your modified version? I would like to include it in
Openfire.
> > > >
> > > > Thanks,
> > > >
> > > > -- Gato
> > > >
> > > > -Original Message-
> > > > From: Paul Chen [mailto:[EMAIL PROTECTED]
> > > > Sent: Monday, April 30, 2007 1:07 PM
> > > > To: dev@mina.apache.org
> > > > Subject: Re: Permanent solution for OOM errors
> > > >
> > > > I actually *tweaked* the read throttle to take the output Queue
size
> > > > into account to avoid the slow write syndrome. Maybe I should call
> > > > it traffic control throttle instead.
> > > >
> > > > Cheers
> > > >
> > > > On 4/29/07, Vinod Panicker <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > On 4/29/07, Paul Chen <[EMAIL PROTECTED]> wrote:
> > > > > > After curbing the read rate (one quota per acceptor) at a
> > > > conservative
> > > > > rate,
> > > > > > the write problem is automatically gone.
> > > > >
> > > > > Not really. The read quota can be applied per acceptor, but the
> > > > > server might have connectors that could be writing to slower
clients,
> > > > > leading to another OOM.
> >
> > Hi,
> >
> > I've been watching this thread grow but not had time to contribute
> > (Sorry about that).
> >
> > The Qpid project is hoping to move the latest released version of mina
> > and so I would be happy to take another look at the
> > WriteThrottleFilter (on DIRMINA-302) to see how it can be tidied up.
> > Specifically the filter currently limits by number of requests whereas
> > the number of bytes on the queue would be far better solution.
> >
> > --
> > Martin Ritchie
> >
>
--
Martin Ritchie
Re: Permanent solution for OOM errors
I'm refining that to make it more presentable and generic, will publish that in 1 week or 2. On 4/30/07, Gaston Dombiak <[EMAIL PROTECTED]> wrote: Hey Paul, That is exactly what I was planning to implement for our case. Can you send me your modified version? I would like to include it in Openfire. Thanks, -- Gato -Original Message- From: Paul Chen [mailto:[EMAIL PROTECTED] Sent: Monday, April 30, 2007 1:07 PM To: dev@mina.apache.org Subject: Re: Permanent solution for OOM errors I actually *tweaked* the read throttle to take the output Queue size into account to avoid the slow write syndrome. Maybe I should call it traffic control throttle instead. Cheers On 4/29/07, Vinod Panicker <[EMAIL PROTECTED]> wrote: > > On 4/29/07, Paul Chen <[EMAIL PROTECTED]> wrote: > > After curbing the read rate (one quota per acceptor) at a conservative > rate, > > the write problem is automatically gone. > > Not really. The read quota can be applied per acceptor, but the > server might have connectors that could be writing to slower clients, > leading to another OOM. > >
Re: Permanent solution for OOM errors
I actually *tweaked* the read throttle to take the output Queue size into account to avoid the slow write syndrome. Maybe I should call it traffic control throttle instead. Cheers On 4/29/07, Vinod Panicker <[EMAIL PROTECTED]> wrote: On 4/29/07, Paul Chen <[EMAIL PROTECTED]> wrote: > After curbing the read rate (one quota per acceptor) at a conservative rate, > the write problem is automatically gone. Not really. The read quota can be applied per acceptor, but the server might have connectors that could be writing to slower clients, leading to another OOM.
Re: Permanent solution for OOM errors
After curbing the read rate (one quota per acceptor) at a conservative rate, the write problem is automatically gone. This is not an approach that leads to optimal performance, but just a way to protect our Mina-based server not run into OOM. Cheers On 4/28/07, mat <[EMAIL PROTECTED]> wrote: Does ReadThrottle filter only solve the "Read" problem? What about "Write"? BTW, what is the max concurrent users you can reach? 2007/4/29, Paul Chen <[EMAIL PROTECTED]>: > > No matter how we tune JVM, there's still a certain threshold that when it > is > reached, a server should stop taking new requests or even close the > session > to free up resources, depends on the logic in the server. > > I observed and categorized 2 OOM scenarios in our Mina-based server: > > [1] Incoming reqs from SocketAcceptors are too fast and too many. Input > queue blows up. Particularly when the Mina-based server has persistent or > long-lived connections w/ the clients which just keep pumping in reqs w/o > even needing time to establish a connection. > > [2] Outgoing reqs from SocketConnectors to a service provider are too > fast/too many, much faster > than the service provider can handle. Then the output queue > (writeRequestQueue) blows up. > > I reported this problem earlier but I can live with this now by tweaking > the > ReadThrottle filter, though > it is very hard to determine the threshold, especially when the > mina-based > server has multiple > Acceptors. I end up assigning a "quota" per Acceptor. > > Regards > > On 4/28/07, Mark Webb <[EMAIL PROTECTED]> wrote: > > > > have you looked into tweaking your JVM? > > > > http://java.sun.com/performance/reference/whitepapers/tuning.html > > > > On 4/28/07, mat <[EMAIL PROTECTED]> wrote: > > > I also observed that the memory increaed way too fast when heavy > > loading. > > > > > > 2007/4/26, Gaston Dombiak <[EMAIL PROTECTED]>: > > > > > > > > Hey Mark, > > > > > > > > Based on the statistics I've been collecting from MINA I can tell > that > > > > our OOM problems happen when: > > > > > > > > 1) the eventQueue instance variable inside of ExecutorFilter fills > up > > > > (that would be the case for incoming traffic) or > > > > 2) the SocketSessionImpl#getScheduledWriteRequests() queue starts to > > > > fill up (that would be the case for outgoing traffic) > > > > > > > > Regards, > > > > > > > > -- Gato > > > > > > > > -Original Message- > > > > From: Mark Webb [mailto:[EMAIL PROTECTED] > > > > Sent: Wednesday, April 25, 2007 1:53 PM > > > > To: dev@mina.apache.org > > > > Subject: Re: Permanent solution for OOM errors > > > > > > > > Maybe one approach would be to categorize the ways in which people > > > > reach OOM conditions. Do these conditions happen only when the > input > > > > and/or output queues get really large, or are there other reasons. > > > > Once we can start to categorize the OOM conditions that users are > > > > experiencing, we can properly move forward with solutions. > > > > > > > > Basically what I mean is, if the OOM happens when queues fill up, > then > > > > throttle filters would be best. If the OOM happen for other > reasons, > > > > people could look at other areas of MINA. Just not sure there is > one > > > > solution that will fix all the problems. > > > > > > > > ...just my 2 cents. > > > > > > > > -- > > > > ..Cheers > > > > Mark > > > > > > > > > > > > On 4/25/07, Gaston Dombiak <[EMAIL PROTECTED]> wrote: > > > > > Hey Marcin, > > > > > > > > > > I see what you mean. I'm really fine with either option as long as > > > > MINA > > > > > handles the OOM problem. As I posted a month or so ago the > > throttling > > > > > per connection is not enough. We (Openfire and probably others) > also > > > > > need a global throttling. > > > > > > > > > > Thanks, > > > > > > > > > > -- Gato > > > > > > > > > > -Original Message- > > > > > From: Marcin Waldowski [mailto:[EMAIL PROTECTED] > > > > > Sent: Wednesday, April 25, 2007 1:36 PM > > > > > To: dev@mina.apache.o
Re: Permanent solution for OOM errors
No matter how we tune JVM, there's still a certain threshold that when it is reached, a server should stop taking new requests or even close the session to free up resources, depends on the logic in the server. I observed and categorized 2 OOM scenarios in our Mina-based server: [1] Incoming reqs from SocketAcceptors are too fast and too many. Input queue blows up. Particularly when the Mina-based server has persistent or long-lived connections w/ the clients which just keep pumping in reqs w/o even needing time to establish a connection. [2] Outgoing reqs from SocketConnectors to a service provider are too fast/too many, much faster than the service provider can handle. Then the output queue (writeRequestQueue) blows up. I reported this problem earlier but I can live with this now by tweaking the ReadThrottle filter, though it is very hard to determine the threshold, especially when the mina-based server has multiple Acceptors. I end up assigning a "quota" per Acceptor. Regards On 4/28/07, Mark Webb <[EMAIL PROTECTED]> wrote: have you looked into tweaking your JVM? http://java.sun.com/performance/reference/whitepapers/tuning.html On 4/28/07, mat <[EMAIL PROTECTED]> wrote: > I also observed that the memory increaed way too fast when heavy loading. > > 2007/4/26, Gaston Dombiak <[EMAIL PROTECTED]>: > > > > Hey Mark, > > > > Based on the statistics I've been collecting from MINA I can tell that > > our OOM problems happen when: > > > > 1) the eventQueue instance variable inside of ExecutorFilter fills up > > (that would be the case for incoming traffic) or > > 2) the SocketSessionImpl#getScheduledWriteRequests() queue starts to > > fill up (that would be the case for outgoing traffic) > > > > Regards, > > > > -- Gato > > > > -Original Message- > > From: Mark Webb [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, April 25, 2007 1:53 PM > > To: dev@mina.apache.org > > Subject: Re: Permanent solution for OOM errors > > > > Maybe one approach would be to categorize the ways in which people > > reach OOM conditions. Do these conditions happen only when the input > > and/or output queues get really large, or are there other reasons. > > Once we can start to categorize the OOM conditions that users are > > experiencing, we can properly move forward with solutions. > > > > Basically what I mean is, if the OOM happens when queues fill up, then > > throttle filters would be best. If the OOM happen for other reasons, > > people could look at other areas of MINA. Just not sure there is one > > solution that will fix all the problems. > > > > ...just my 2 cents. > > > > -- > > ..Cheers > > Mark > > > > > > On 4/25/07, Gaston Dombiak <[EMAIL PROTECTED]> wrote: > > > Hey Marcin, > > > > > > I see what you mean. I'm really fine with either option as long as > > MINA > > > handles the OOM problem. As I posted a month or so ago the throttling > > > per connection is not enough. We (Openfire and probably others) also > > > need a global throttling. > > > > > > Thanks, > > > > > > -- Gato > > > > > > -Original Message- > > > From: Marcin Waldowski [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, April 25, 2007 1:36 PM > > > To: dev@mina.apache.org > > > Subject: Re: Permanent solution for OOM errors > > > > > > Hej Gaston, > > > > > > Gaston Dombiak wrote: > > > > Hey Marcin, > > > > > > > > I'm curious to hear from you why do you think so? I absolutely agree > > > > that MINA has to provide easy ways to handle OOM problems due to > > heavy > > > > incoming or outgoing traffic. > > > > > > > > This is by far the more common problem people are reporting with > > > > Openfire now that we moved to MINA (when under heavy load). > > > > > > > > > > Hmm, my first thought was that it introduce the complexity of > > > configuration like ThreadModel. But probably I'm wrong. > > > > > > I agree definitely that MINA need solution for OOM, but it could be > > also > > > > > > ReadThrottleFilterBuilder and WriteThrottleFilter. They are easy way > > to > > > handle OOM and (what is important) users are aware that they use it. > > > > > > But I'm not agains integrate it as default to Acceptor/Connector, > > really > > > > > > :) Meybe I even souldn't post my doubts to this subject because I > > > haven't contributed to MINA so far... > > > > > > Regards, Marcin > > > > > > > > > > > > -- ..Cheers Mark
Re: OutOfMemory when the output queue piles up
Trustin, Yes that does work for me to some extent. But on my multi-CPU box there are several output queues and it is the sum of them causes OutOfMemory. It looks like I need to put a "quota" on each queue in order to cap the total. Or, an alternative is to take a snapshot across all in/out queues to get the sum-up. Thanks for comments On 4/17/07, Trustin Lee <[EMAIL PROTECTED]> wrote: Hi Paul, On 4/18/07, Paul Chen <[EMAIL PROTECTED]> wrote: > Hi, folks, > > I got this error often when my Mina-based proxy server is under get lots of > requests > from clients. And the service my Mina proxy forwards the client to becomes > very slow. > So I added probes in Mina code and saw this queue.size() grew significantly > to > 200K. > BTW I use SocketSessionImpl.writeRequestQueue.size() to get the queue size. > > Add more computing power solves this problem but something it is not within > my > control. > > In general, this kind of problem should happen when the other side Mina is > talking > to is either too slow or too fast, either the input queue or output queue > piles up, > right? > > On the reading side, I put some read throttle filter and it works just fine. > > On the writing side, I'm trying to do something similar. Not sure if you > experienced > such issues ever and how you dealt w/ them. You can check the number of bytes in the write queue using IoSession.getScheduledWriteBytes() before you write a message. If the number of bytes exceeds certain threshold, you can write the message later when messageSent() event is invoked. Another alternative is to use the following user contribution. http://issues.apache.org/jira/browse/DIRMINA-302 I didn't review the code yet though. HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
OutOfMemory when the output queue piles up
Hi, folks, I got this error often when my Mina-based proxy server is under get lots of requests from clients. And the service my Mina proxy forwards the client to becomes very slow. So I added probes in Mina code and saw this queue.size() grew significantly to > 200K. BTW I use SocketSessionImpl.writeRequestQueue.size() to get the queue size. Add more computing power solves this problem but something it is not within my control. In general, this kind of problem should happen when the other side Mina is talking to is either too slow or too fast, either the input queue or output queue piles up, right? On the reading side, I put some read throttle filter and it works just fine. On the writing side, I'm trying to do something similar. Not sure if you experienced such issues ever and how you dealt w/ them. Thanks for comments Paul
Re: MINA dependencies
Deepak, We just download them separately. 3.0 works pretty well w/ Mina. http://dcl.mathcs.emory.edu/util/backport-util-concurrent/ Cheers On 4/12/07, Deepak Nadig <[EMAIL PROTECTED]> wrote: Is the expectation that the dependent libraries (backport-util-concurrent-2.2.jar, easymock-1.2_Java1.3.jar, etc.) for the build should be separately downloaded? Or is there a central place to download all these libraries. Thanks, Deepak
Re: [OT] My wedding photos
Trustin, The human touch you added to the Mina community makes it like a real community. Wish you a wonderful honey moon... and come back fully recharged. Best On 4/10/07, Trustin Lee <[EMAIL PROTECTED]> wrote: Hi folks, Some of you might already have seen these pictures from my blog, but I'm posting the following link for those who didn't enjoy them. :) http://www.flickr.com/photos/trustin/sets/72157600058719850/show/ I am not sure people in different countries take this kind of photos, which is taken in a studio before the actual wedding ceremony to remember the good old days. Cheers, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Question about a server that opens multiple SocketAcceptors
Hi, folks, I have a server with multiple SocketAcceptors listening on 5 different socket ports. And I create 5 acceptors the following way. - int NUMBER_CPU = Runtime.getRuntime().availableProcessors(); Executor ioExecutor = Executors.newFixedThreadPool(NUMBER_POOL_THREADS); SocketAcceptor acceptor = new SocketAcceptor(NUMBER_CPU, ioExecutor); ... acceptor.bind(...); - Repeating the above statement 5 times. But my machine has only 2 CPUs (NUMBER_CPU=2). Before I dive into serious performance experiments, I'd love to learn from you guys what's the best or recommended parameters to new the SocketAcceptors in this situation? Thanks a bunch Paul
Re: OutOfMemory when using ReadThrottleFilter
The root cause of this problem is running out of Java heap memory, when
don't
we use a more direct approach by checking the real remaining heap in the
filter?
Runtime.getRuntime().freeMemory();
It is hard to prevent the problem completely by tracking byte buffers.
Best Regards
On 1/30/07, Swen Moczarski <[EMAIL PROTECTED]> wrote:
Hi Trustin,
thanks a lot for your response.
Trustin Lee wrote:
> Hi Swen,
>
> On 1/4/07, Swen Moczarski <[EMAIL PROTECTED]> wrote:
>>
>> Hi, I have done some performance tests. A client is sending a lot of
>> small
>> messages over a connection to a server. In
>> spite of the read-throttle-filter (
>> org.apache.mina.filter.ReadThrottleFilterBuilder) the server will be
>> overloaded and I
>> get out-of-memory exceptions.
>>
>> Before the message will be forwarded to the ExecutionFilter, the
>> ReadThrottleFilter makes use of ByteBuffer.remaining()
>> for increasing the calculated size of the connection buffer. But after
>> passing the ExecutionFilter the method
>> ByteBuffer.capacity() is used to decrease the size. Is that behaviour
>> intended?
>>
>> When I'm patching the ReadThrottleFilterBuilder to use
>> ByteBuffer.capacity()
>> for both cases the performance test works
>> absolutely fine, there are no longer out-of-memory exceptions. BTW, in
>> the
>> SVN-history I have seen that the first
>> version uses ByteBuffer.capacity() for both cases.
>
>
> It seems like there was a mistake. Could you try to change both
capacity()
> calls to remaining()? I think it's a correct fix than using capacity().
>
When I'm using the remaining() calls, I still get an out-of-memory error.
But when I'm using capacity() it looks ok.
Maybe, this becomes only a problem when a lot of small messages are stored
in bigger ByteBuffers. But I think it would
be safer to prevent overloading when the ReadThrottleFilter tracks the
memory allocated by the ByteBuffers (capacity())
instead of the received bytes. WDYT?
Here is my simple stess-test:
public class Test {
private final static int PORT = 8056;
public static void main(String[] args) throws Exception {
IoHandler handler = new IoHandlerAdapter() {
public void exceptionCaught(IoSession session, Throwable cause)
throws Exception {
cause.printStackTrace();
}
public void sessionCreated(IoSession session) throws Exception {
ReadThrottleFilterBuilder throttleFilter = new
ReadThrottleFilterBuilder();
throttleFilter.attach(session.getFilterChain());
}
};
SocketAcceptor acceptor = new SocketAcceptor();
acceptor.bind(new InetSocketAddress(PORT), handler);
Socket socket = new Socket("localhost", PORT);
Writer writer = new OutputStreamWriter(socket.getOutputStream());
while (true) {
writer.write("test");
writer.flush();
}
}
}
I have tried the test with version 1.0.1 and the current trunk (with the
current trunk it takes longer until the memory
error occures).
Should I attach the test to
https://issues.apache.org/jira/browse/DIRMINA-338 and reopen the issue?
Regards,
Swen
How to check out the source of Mina 1.0.1?
Hi, folks, It looks like I can only use svn to check out Mina 1.0 or 1.1 % svn ls https://svn.apache.org/repos/asf/mina/branches/ 1.0/ 1.1/ Is there a way to check out the source of 1.0.1? Thanks for comments Paul
SSL filter deadlocks
Yes, I have a similar problem. It seems caused by simultaneous read/write on an ssl session, or because of abrupt closing when other threads still using it. I'll also try to reproduce and narrow down... On 1/3/07, janardhanan vembunarayanan (JIRA) <[EMAIL PROTECTED]> wrote: [ https://issues.apache.org/jira/browse/DIRMINA-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462084] janardhanan vembunarayanan commented on DIRMINA-329: Please can someone look into this issue > ProtocolEncoderOutputImpl and SSLHandler deadlocks > -- > > Key: DIRMINA-329 > URL: https://issues.apache.org/jira/browse/DIRMINA-329 > Project: MINA > Issue Type: Bug >Affects Versions: 0.9.4 > Environment: Windows 2000, Java 5.0 and Eclipse IDE >Reporter: janardhanan vembunarayanan >Priority: Blocker > > I am using MINA in my project for developing a routing server. The server accepts TCP + SSL connection from 1 client. The data sent by the client will be parsed by the server and does the following > 1. The Acceptor handler receives the message from the client and sends the data to a webserivice using a Socket connector > 2. The response from the web service will be received by the ConnectHandler which will send the response to the client that is connected to SGW > 3. If the data sent by the client has some errors then the Acceptor handler sends an error response to the client. > Client <--> MINA Server <---> Web Service > aysnchronous synchronous > (1 connection) (for each command there will be one connection) > When the 2 different handlers tries to write to the client they dead lock with each other. The dead lock message is given below. > Is there a fix for this available already? > Name: MOPClientAcceptord-sjc-jvembunar.corp.ebay.com/10.254.34.93-2 > State: BLOCKED on [EMAIL PROTECTED] by: ServiceConnector:pp_mops at D-SJC-JVEMBUNAR/10.254.34.93:7000-3 > Total blocked: 20 Total waited: 12 > Stack trace: > org.apache.mina.filter.codec.support.SimpleProtocolEncoderOutput.write( SimpleProtocolEncoderOutput.java:32) > com.ebay.trinity.servicegateway.codec.mop.MOPResponseEncoder.writeData( MOPResponseEncoder.java:109) > com.ebay.trinity.servicegateway.codec.mop.MOPResponseEncoder.encode( MOPResponseEncoder.java:89) > org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite( ProtocolCodecFilter.java:226) > org.apache.mina.common.support.AbstractIoFilterChain.callPreviousFilterWrite (AbstractIoFilterChain.java:583) > org.apache.mina.common.support.AbstractIoFilterChain.access$1200( AbstractIoFilterChain.java:51) > org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.filterWrite (AbstractIoFilterChain.java:799) > org.apache.mina.common.IoFilterAdapter.filterWrite(IoFilterAdapter.java :92) > org.apache.mina.common.support.AbstractIoFilterChain.callPreviousFilterWrite (AbstractIoFilterChain.java:583) > org.apache.mina.common.support.AbstractIoFilterChain.access$1200( AbstractIoFilterChain.java:51) > org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.filterWrite (AbstractIoFilterChain.java:799) > org.apache.mina.common.support.AbstractIoFilterChain$2.filterWrite( AbstractIoFilterChain.java:212) > org.apache.mina.common.support.AbstractIoFilterChain.callPreviousFilterWrite (AbstractIoFilterChain.java:583) > org.apache.mina.common.support.AbstractIoFilterChain.filterWrite( AbstractIoFilterChain.java:574) > org.apache.mina.transport.socket.nio.SocketSessionImpl.write0( SocketSessionImpl.java:176) > org.apache.mina.common.support.BaseIoSession.write(BaseIoSession.java :136) > com.ebay.trinity.servicegateway.router.mop.MOPClientRequestHandler.replyErrorToClient (MOPClientRequestHandler.java:373) > com.ebay.trinity.servicegateway.router.mop.MOPClientRequestHandler.messageReceived (MOPClientRequestHandler.java:106) > org.apache.mina.common.support.AbstractIoFilterChain$2.messageReceived( AbstractIoFilterChain.java:188) > org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived (AbstractIoFilterChain.java:501) > org.apache.mina.common.support.AbstractIoFilterChain.access$1000( AbstractIoFilterChain.java:51) > org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived (AbstractIoFilterChain.java:787) > com.ebay.trinity.servicegateway.router.mop.MOPHeartBeatFilter.messageReceived (MOPHeartBeatFilter.java:30) > org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived (AbstractIoFilterChain.java:501) > org.apache.mina.common.support.AbstractIoFilterChain.access$1000( AbstractIoFilterChain.java:51) > org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived (AbstractIoFilterChain.java:
Dependent libs of Mina 1.0
Hi, folks, Just like to double check with you about the right versions to use for Mina's dependent libs for Mina 1.0: slf4j 1.0.2 commons-logging 1.1 backport Java5.0-3.0 Are they all right? Thanks for comments
