I'm not quite understand the detail. However, if you put a message into some queue after receiving a message, you can wrap the message along with the session into 1 object and put that obj in the queue.
-----Original Message----- From: Vanja Ozegovic [mailto:[email protected]] Sent: Thursday, September 08, 2011 10:37 AM To: [email protected] Subject: Re: Proxy HTTP-Serial Hello everyone, I worked out this problem so I will post my experience in case someone else has a similar issue. As I stated before, I thought first about using queues for incoming requests. This wouldn't solve my synchronization issues, because at the end, I needed to simulate synchronous communication through all the layers (the same request received on HTTP server side has to be forwarded to Serial port client and vice-versa with the response). That meant that if I put a message into some queue I wouldn't know to who to send the response (or at least it would be quite more complicated). The other approach of using semaphores/critical sections worked but not as I imagined in the beginning. To be able to provide a "real" synchronization on both events (messageReceived and sessionOpened), I needed to "group" these somehow. What I ended up using is customized approach. I took the idea from HTTP Server implementation example (streaming case) and created my own thread which will start every time a message is received on HTTP Server side. In this thread the connection to serial port is established and listener for "connect" method is created. Only when OperationComplete is invoked (connection is established), the message is sent from HTTP Server side to the Serial port side (serial port session). I tried using synchronizing run() method but this approach always blocked the second thread (second client) and didn't work well. In stead of that at the end, inside the run() method, I used semaphores (semaph.acquireUninterruptibly();) which solves the problem correctly. Semaphore is released on the serial port handler side when the response is sent back. The downside is that all the incoming requests for the HTTP server side are mapped to threads and these are maintained in the memory until their execution is finished (few seconds per thread in my testing environment). This is the only solution I found without denegating the service to the clients. Best Regards, Vanja Ozegovic Vanja Ozegovic wrote: > > Hello everyone, > > I'm new in this mailing list; my name is Vanja Ozegovic and I'm currently > getting to know Apache Mina. I have read the tutorials, documentation and > the code, and have been working with the framework for couple of months. > > The problem I am facing is as follows. I created a proxy server in Apache > Mina, following the logic in Proxy Example. On the server side I have an > HTTP server (also following modified HTTP server logic) and on the client > side I have a Serial Port Connector. > > The main requirement is to be able to process petitions from thousands > HTTP > clients simultaneously. I am aware that this is not possible on the serial > port side since the access to the serial port is exclusive (one client at > a > moment). My question is what would be the correct approach for > synchronization in this case? > > I was considering to create a request queue on the server side, to allow > only one petition to be forwarded to the Serial Port Connector at a given > moment but this doesn't seem quite correct. I also though about using > semaphores but this doesn't seem to be right neither since I need to > restrict access for obtaining the serial port session and also to restrict > the writing the messages to the serial port session (in sessionOpened and > messageReceived methods respectively). Is there any other approach? > > I haven't work that deeply with event driven approach, so if anyone can > provide my a hint on this problem, I would be very grateful. > > Best Regards, > V. Ozegovic > > -- View this message in context: http://old.nabble.com/Proxy-HTTP-Serial-tp32386348p32424100.html Sent from the Apache MINA User Forum mailing list archive at Nabble.com.
