All,
My requirement is following.
I have a Vaadin application running in Tomcat.
On the same tomcat there is another java server which is listening on some port (and blocked until some data arrives)
When the data arrives on this server, this is for one of the Vaadin Application instances running on this container.
So I have a requirement of storing all the servlet vaadin application instances somewhere so that this server can look them up to find the correct instance and hand-over the data for that instance.
I have tried to create a static Map of ID as key and Vaadin App as value and when the data arrives on server, look-up that instance. It works but when I recycle Vaadin application (servlet) after that time onwards I cannot find the instance of the new app instance which I put in MAP.
NOTE: Since this is a blocking server, I need to start it in a separate thread and listen for data.
This is related to some Class loader issue where, when the older app gets recycled, the static Map also changes and there becomes 2 different copies of that Map and from then onwards, the Vaadin App and the blocking server are looking at different copies of Map (I have confirmed this by debugging).
Any suggest, how to deal with such situation? Any other suggestions?
I did not fully understand what you are trying to do, but here are some ideas:
If you want to send some data directly an existing Vaadin application instance from outside. You could use
ParameterHandler .
Or if you must use another servlet and the data is coming from the users web browser and the servlet is part of the same web application, then you have both ApplicationServlet and YourCustomDataReceivalServlet accessing the same HttpSession. You could then just
access the application instance through the application context .
Otherwise you should be able to do what you already did: have your application instances to register themselves to a centralized data routing service. This might be discovered by a static or some more sophisticated discovery mechanism. Maybe even the message passing should be done with JMS…
Thanks a lot Joonas. All of these options work fine as long as my tomcat doesn’t get recycle.
By recycle I mean the following
When I do any text change in MyApp.java/web.xml etc then the eclipse causes the (Publishing to tomcat…) may be hot deployment to the tomcat and that intern cause the servlet container to restart the whole thing. This causes the filer destroy/init to be called.
We have the HTTP filter etc which gets called every time (init/destroy) when this recycling happens. so I assume after this step the new MyApp instances gets created and everything should start afresh.
I want to add few more imp points: S
ince this data receiver server gets the data using thrift server (Not from browser) and it listens (and blocked) to some port, I have to start it on different thread (otherwise app cant respond to anything until some data comes on this server). I tried to create that thread in servlet filter and everything works until this auto-recycling takes place.
However if I explicitly click stop/start or restart button in eclipse then things work fine.
Do you know the difference be behavior when I explicitly stop/start the container vs when it does automatically?
Is there anything I need to handle to have the exact same behavior in both the cases?
I think that there is no solution where you could expect the application instances (or any other java classes for that matter) to survive reliably over code changes and re-deploy.
Maybe you could do some of this with Jrebel or even normal hot code replacement, but not all. In any case - your development tool-chain should not affect the architecture of the application you are creating…