I think it works if all threads read/write commands queues in a synchronized environment, as you suggest.
If I understood your approach basically you have a server thread that pool all active clients queue, process each command, and send a response throw client connection.
The only thing to take care in such solution is to synchronize queues (both clients and server), well... it not soo difficult, but debugging can be a nightmare if something do not work as expected (there are something wrong in client threads? in server thread? in queues synchronization?).
When I developed a mud server I choose to do it in a different way.
Each player is an object that "speak" with the clinet throw a connection (so one player one thread as in your solution, but only for I/O), a player receive a command string and pass the command to a command manager with a reference to itself. No queue in the "client side", only a command queue in the "server side" (server thread).
When the command manager receive this instruction process it and, if there are some feedback for player, use the payer reference to perform back comunications.
It's a quite similar approach, but I have only one command queue and I don't have a thread that "pool" each active connection; my server thread waits command from players and process it in a First In First Out way.
I don't know if this is the "best way to do this"^(TM), just an idea.
I think develop a mud environment is an interesting exercise, there are a lot of possibilities to do the same things 

Have a good job 

I also use MINA in some little project.
It's an interesting library if you would like to build a custom protocol layer over TCP/IP.
Actually I can say it have some limits due to the fact that isn't so stable; documentations isn't clear (sometimes is simply too old) and there isn't a "state framework" that help to build a statefull client/server interaction (not a problem if you don't need it... and nothing soo difficult to write).
Do not seems to have speed issue (of course, I use it only in little environments).
I think is a good idea to take a look about it.

Try  with jar -xvf some_file.jar

Maybe you have to call  getVel() in your keyPressed method.

In your code when you press a key  (e.g. up key) you set  upkey to true, but nobody know that happend; on release you set it to false, and again nobody "see" this change. 

I don't know what exactly you want to do in your servlet; I think you use it like a door for some kind of service call.
So, if this is your environment, maybe you can use a service locator.
You may use Spring like service locator in your web app (service class is singleton by default in Spring).
Your servlets get the service instance from Spring, and it serve to you a shared instance.
It is not important that your servlet is a singleton instance, isn't his nature; move logic in external class, outside the J2EE behavior, and maybe you get the point.