Hi all, what is your recommended way to deal with a UDP-based server facing heavy load (like some 75000 packets per minute)?
Our setup look like this (using MINA 1.1.7): - No explicit Executor provided with the DatagramAcceptor - Usage of the following IoFilters: 1. Codec 2. MINA's built-in LoggingFilter 3. Filter compressing answers if necessary/appropriate 4. MINA's built-in ExecutorFilter We are facing some weird problems, but let me explain some of the thoughts/issues we have tried to address: We're using an ExecutorFilter (element 4 within the list of IoFilters) cause business logic includes synchronous remote communication. Here we follow recommendations found on the MINA web page: http://mina.apache.org/configuring-thread-model.html But the default implementation available via java.util.concurrent.Executors.newCachedThreadPool() uses an *unbounded* queue to deposit tasks not available to immediate execution by an idle worker thread. We think this may lead to a huge heap memory consumption if the rate of packets incomming is larger than the rate of task processing by worker threads. So we tried to use a *bounded* queue accompanied by a java.util.concurrent.RejectedExecutionHandler like DiscardPolicy (applying org.apache.mina.integration.spring.ThreadPoolExecutorFactoryBean). But this may lead to other problems caused by the fact that the task (java.lang.Runnable) to execute is discarded but the IoSession the task is bound to remains open (logging entries show that 60 seconds later some thread closes the IoSession still open). Are we missing some key point to get the VM more stable and our service more responsive? Currently JVM consumes as much memory as you like (up to some GBs until operating system is swapping all the time) despite configuring it to use a maximum of 256MB heap for example (using command line parameter "-Xmx256M"). JConsole shows us that the configured amount of Java Heap is NOT completely used by the VM anyway! So what the hell makes the VM consume so much memory? Maybe we are facing some special kind of "NIO memory leak" by not cleaning up something important? Recommendations appreciated. Regards Christian -- Dr. Christian Möller [email protected] Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01
