I have a situation here .. maybe someone can help me with this.
I'm trying to provide a service where clients can "analyze" a specific URL. So I use a web service in Tomcat to work with the clients. The user accesses the web service webpage, inputs a URL and presses analyze. I now have to receive the URL in the web service, send it to a process that is running on the same server as Tomcat ( I do this through a pipe right now ).
The process adds the URL's in a queue, starts consuming it and analyzes every URL.
After the processing is done, I want to post a message from this process to the same session ID that sent me that URL ( lets' say I send the session ID through the pipe, together with the URL ).The URL after analyze, has to get to the client that pressed Analyze in the end.
Will what I want be possible?
I tried to find a solution where I would use only pipe communication between the web service and the local process, but a lot of complications appear when we are taking about multiple users connecting on the same time.
Related
I have an Application in Spring Boot, when i load a webpage it hits a service and gets the result from it. Response takes some time about (10-15) seconds because of searching in database. So if i close that webpage and open another instance of same page the Spring Boot puts that request in a queue and waits for 1st request to finish even if i have closed that webpage. Also if so many requests are in Queue tomcat server is crashed.
What i have done so far is i have modified tomcat threads in application.properties as
server.tomcat.max-threads=20
So is there anyway i can make it multi threaded ?
Note : The number of requests can be more than 20 also
I am using Spring Boot 1.5.2 for this application
EDIT :
I also have One similar application running in Spring boot 2 and that application does not have this type of issue. Application Logic is almost same for both but Second Application Queries take a bit less time.
A better design would mean a service with two endpoints:
A POST URL that allows the user to send a request to the server and get a key token back. The server puts the message on the queue and returns the token.
A GET URL that allows the user to send the token and either get the response back or nothing if it's not back from the queue.
You should register a pool of listeners that take the requests off the queue and put them in a database (key token/value pair). When the user sends a GET request for their token, the server side looks it up in the database and returns the result.
If your database search takes 10-15 seconds you should think about speeding that up. Do you have appropriate indexes? Partitions? Is this a relational database?
Node server is applied by our front-end to deal with request from user's browser, and then get data from API served by jetty. It has been validated that all works well when client call API directly. However, we need node server to precess some front end logic. But APIs depended on session will failed when all requests are from node server.
To be clear, the request tracing would be:
client(browser) <==> node server <==> API (jetty web server)
For example, one of our APIs captcha service (based on Kaptcha) needs to set generated image into HttpSession in HttpServletRequest. and all requests would be considered from the same point with the same sessionId caused by the forwarding of node server.
The business logic is, when captcha is required, javascript in browser will call node server and then call API server to get captcha.
Jetty would think all requests from the same client(node server) and the sessionId will be always same, service would keep the last captcha associated with sessionId, however the original requests are from different users. When more than one users access our website, some of them will fail.
Thanks a lot for your time reading this, so is there any way to distinguish the different source from my API without removing the node server?
Thanks again.
I am trying to implement a web socket session manager and I have just encountered a road block that I hope someone can assist me with.
Basically a client will initiate a web socket session with my websocket server endpoint and I will take the HTTP request parameters, parse it and subscribe to web service producer endpoint. The Web service will return a response containing a subscription identifier of which will use as a key mapping (along with the HTTP session ID) to add to a java map cache with the session object. The proceed to send data to my published webservice consumer endpoint. My application will then take the data received from the producer, use the subscription id that comes with each packet and find the right session in the map caches to send the data back to.
Here is my problem..
I noticed that if the client opens another tab in the browser and sends a second subscription request, it would still be sent with the same HTTP Session ID yet tomcat will still be able to stream the data to the correct tab. This implies that the tomcat websocket implementation has a built in multiplex handling mechanism.
To exclude some unnecessary details unless asked, I want to to also be able identify all the channels that were multiplexed under the same session id. But I can't find any way in the API to identify it. As I need to be able to look up my map caches and remove sessions for tabs that have been closed (which triggers a close method in my web socket endpoint), but I'm not going to be able to do that as there could be many sockets/channels associated with the same HTTP Session ID.
The websocket framework does not provide any such implementation. Every tab opens a new socket. You can maintain a session info through adding a key in the request while initiating the websocket and on message check for that key(eg JSESSION id value) in the server and serve the request accordingly.
Is there any way to locate a previous HttpRequest, for a given session?
Web client sends request to a long running web service. While this service is running the client sends another request. I want to locate the first request and send it a stop signal.
Background:
I have a web service that requires 2-4 seconds to process. The servlet is hosted in a Tomcat container and is using OSGi to access the main processor in another plugin.
The requests come from another web site that allows users to make 10 or so requests at a time. While the user is waiting they may make another page change that will start another 10 web requests. I need a way to locate the previous requests. Then I'll find a way to send a stop signal to the long running process which will allow the original HttpRequest to finish with some suitable error code.
Perhaps another way to look at this problem is to say: if a client makes a series of requests that overlap then we only want to service the last request and cancel the previous requests as soon as possible.
I don't think HttpSession gives you what you are looking for, but I would recommend making some kind of object that your requests can periodically check to see if they are the "newest" request. If they are no longer the newest request then they can stop themselves and return immediately.
You can keep the previous request job task in the session. And on next parallel request, you can get the earlier request job and take the action you want.
I am using GWT for my client side application. I am not using GWT/Java for the server. However, I am not sure how I can handle session management. The GWT application resides on one page, all server calls are done via AJAX. If a session expires on the server... let's assume the user didn't close the browser, but left the application open, how could my server notify the application that the session has expired and that the client side portion should show the login screen again?
What is meant by client side session management? That seems inherently insecure.
I'm not looking for code. I'm looking for ideas, techniques, potential solutions etc. I've considered Comet http://en.wikipedia.org/wiki/Comet_(programming), but that doesn't seem like that will work very well without using Java on the server side. Maybe, I'm wrong? I don't want to poll the server either.
Any thoughts or insight?
Without knowing how you're doing your RPC is working, its hard to give good advice.
If your AJAX service requires a user to be authenticated (IE have a valid session), it is ok to just send a 401 error saying that the user is invalid. Client-side can interpret the 401 error as a message that it should set the user up for re-authentication.
We handled this in our application, by detecting when the server sent back a redirect to the login screen (it would come through the response to the Ajax call), and popped up a dialog asking the user for their password again, but pre-filled their username. We then posted that to the same place the login page does, as if it was the login page, and so the user was logged into this new session automatically. Finally we just re-submitted the ajax call again, so it was a seamless process to the user (eg: they didn't have to click the action again).
Since we stored all the state on the client, and not in session variables we didn't have any problems trying to persist data across sessions.
What should happen if the session expired on the server-side, then the next time the client sends a request to the server, it will either create a new session, or, more likely, send back a message to the client that it is trying to access a page without a session, and send them to the login screen. However, you will still need to wait until the client sends a message to the server.