Hi Matt, You could request a thread-dump to see where the handler is stalled. (or connect to your server with jconsole)
Maarten On 5/15/07, Matt Mehalso <[EMAIL PROTECTED]> wrote:
Actually, I turned off the ExecutorFilter and I'm still having the same problem, so scratch the last message. It looks like the handler is stalling in the sessionOpened event method when trying to load a new ClassPathXmlApplicationContext. I wonder if this is some sort of security issue with Server 2K3 and accessing the filesystem. On 5/15/07, Matt Mehalso <[EMAIL PROTECTED]> wrote: > > Hi All - > > We have developed a simple request - response server using Mina 1.0.3. > The server uses a logging filter, a custom codec, and an ExecutorFilter to > intercept incoming events/messages before hitting our custom > HandlerAdapter. The server has been fully tested on our development > machines. However, we have ported over to the production box this morning > (running Windows Server 2k3), and are running into an odd problem. I think > I've pinned it down to the ExecutorFilter. > > Basically, what happens on the new box is this: > > Upon a new connection, the ExecutorFilter fires off a new event. However, > the thread handling this event never exits (i.e. normally, the > ExecutorFilter logs "Exiting since queue is empty for /127.0.0.1:####"). We > never get this message when running on the new box. When receiving a > message, the protocol codec handles everything correctly (we get > ".....RECEIVED: 'msg'), but the ExecutorFilter never fires off a new thread > and therefore, the message is not handled. Basically, all we have now is a > log of incoming messages with no handling logic being performed and nothing > being sent back. > > Again, we've tested the server on several of our development machines and > everything works fine. Any ideas? Are there some security settings we need > to enable on our Win2K3 box? > > Thanks for your help! Our experience with MINA thus far has been > fantastic! > > -Matt >
