I face a scenario where everything works fine with keeping session.setMaxInactiveInterval(15*60) //15 minutes
Now, there is one request in application where number of users are getting saved, which takes more then 15 minutes at server side as internally many operations are involved while saving each user.
When saveUser operation is performed from browser, request received at server, starts processing, after 15 minutes client see "Session Time out" but user saving operation still going on.
I want to avoid this scenario, and need is when request is received by server at that time till the time it responds back to client don't considered in-between time as inactive time.
I can very well do it by making setMaxInactiveInterval(-1) as first line of my method saveUser and just before giving response as setMaxInactiveInterval(15*60).
I am looking for standard approach or this is the standard approach to follow?
Is there any inbuilt Tomcat configuration provided for such scenario?
The standard Java EE approach for this would be as follows:
Instead of doing all the processing in the web-layer, put all the details on a JMS queue and return the request straight away.
The data would be taken off the JMS queue by a worker (possibly on a different server, as you wouldn't want to have the load of creating something for 15 minutes on your web layer)
Once the data is create for the user a notification would be generated (e.g. the browser could query every 30 seconds whether the user generation has finished).
N.B. blocking a thread in a server for 15 minutes is a very bad idea, because essentially it means that your servlet container wouldn't be able to do anything else with that thread. Imagine if a large number of those requests came in at the same time, your web layer would probably buckle under the pressure...
N.B.2: 15*50 does not make 15 minutes
Related
Our project consists of multiple microservices. These microservices form a boundary to which the entry point is not strictly defined meaning each of microservices can be requested and can request other services.
The situation we need to handle in this bounded microservice context is following:
client (other application) makes the request to perform some logic and change the data (PATCH),
request times out,
while request is being processed client fires the same request to repeat the operation,
operation successfully completes,
second request is being processed the same way and completes within it's time and client gets response.
Now what happened is that the same was processed two times because of first timeout.
We need to make sure the same request won't get processed and application will respond with former response and status code.
The subsequent request is identified by the same uuid.
Now, I understand it's the client that should do requesting more precisely or we should have a single request entry point in out micorservices bounded context, but in enterprise projects the team doesn't own the whole system therefore we are a bit constrained with the solutions we propose for the problem. with this in mind while trying to not reinvent the wheel this comes to my mind:
The microservices should utilize some kind of session sharing (spring-session?) with the ability to look up the request by it's id before it gets processed and in described case, when first is being processed and second arrives, wait for the completion of the 1st and respond to the second with data of the first that has timed out for a client.
What I am struggling with is imagining handling the asynchronicity of replying to the second one and how to listen for session state of the first request.
If spring-session would be used (for example with hazelcast) I'm lacking some kind of concrete session state handler which would get fired when request ends. Is there something like this to listen for?
No code written yet. It's an architectural thought experiment that I want to discuss.
If unsure of understanding, read second time please, then I'm happy to expand.
EDIT: first idea:
process would be as follows (with numbering on the image):
(1) first request fired
(3) processing started; (2) request timed out meanwhile;
(4) client repeats the same request; program knows it has received the same request before because it knows the req. id.
program checks the cache and the state of that request id 'pending' so it WAITS (async).
computed result of first request is saved into the cache - orange square
(5) program responds to the first request with the data that was meant to be for the first one
idea is that result checking and responding to the repeated request would be done in the filter chain so it won't actually hit the controller when the second request is asynchronously waiting for the operation triggered by the first request to be done (I see hazelcast has some events when rows are added/updated/evicted from the cache - dunno if it's working yet) and when complete just respond (somehow write to the HttpServletResponse). result would be saved into the cache in postHandling filter.
Thanks for insights.
I'd consider this more of a caching paradigm. Stick your request/responses into an external cache provider (REDIS or similar), indexed by uuid. Having a TTL will allow your responses to automatically get cleaned up for requests that are never coming back, and the high-speed implementation (o1) should allow this to scale nicely. It will also out-of-the-box give you an asynchronous model (not a stated goal, but always a nice option).
I have integration with video stream provider. The flow is following: user requests a stream url, next we on behalf of user, request it from stream provider and return to the user. Next, we should prolong the stream id (session) every 10 secs. To minimize interaction with the client and because of slow network, we want to do this session prolongation on behalf of the user. So let's say, user will trigger one request per 2-5 mins, at the same time server will trigger session prolongation requests every 10 secs.
The question is in possible design of such service. I have not found better solution other than just simply iterate over all available session keys periodically and call prolongation service.
But this approach has disadvantages when user count will be really big it could slow down processing. Also, it is hard to scale with such an approach.
Maybe you have ideas about how to overcome this? Or please propose a better solution
I would write the keep alive as a single self contained piece of code, that will call the keep alive every x number for seconds for y amount of time before ending itself, where x, y and the keep alive endpoint are startup parameters.
Each time the user triggers a request - kick one of these off in the background. How you package that is determined on your deployment environment and how you intend to manage scaling out (background thread, new process, server-less function, etc.).
You may need to maintain some state info in a cache for management purposes (don't start a new one if one is already running, hung process states, etc.).
In my application, there are roughly 15 threads that each send an http request to an api endpoint once every 15 seconds; meaning about 1 request a second. These threads should be running indefinitely and only need to be created once. I am unsure how to continuously receive the responses on the main thread so that they can be parsed and dealt with. In trying to research this problem I found several frameworks that look like they could help; ScheduledExecutorService, NIO, Grizzly, AHC. But, I'm paralyzed by the amount of options and am unsure of what to implement.
My main goal is, for each of the 15 requests, to have the request sent off on its own every 15 seconds and receive the response on the main thread as it comes in.
No special frameworks are required for such a simple task. Just create an instance of BlockingQueue (ArrayBlockingQueue looks like the best choice). Each network thread calls queue.put(response) and the main thread makes response=queue.take() in a loop.
The application we are building has a very simple concept: it receives incoming events from a Database and for each event it opens an interactive session with clients (in the event) by showing a menu. Based on client response, we move to the next state or take some concrete action (e.g. transferring funds).
Sessions are independent of one another. For example, suppose we get two events from the database saying clients A and B have reached a zero account balance state. In response to this event, we establish two connections to A and B show a menu which looks like the following:
Please select an option:
1. Get $5
2. Get $10
3. Ignore
For options 1 and 2, we ask for confirmation in the form of second menu.
Are you sure?
1. yes
2. no
In this case, we'll have two sessions. Client A might choose option 1 (1. Get $5), whereas Client B chooses option 3 [in the first menu]. In the case of Client A, we'll present the second menu (above) and if the response is 1. yes, we'll take some concrete action such as transferring funds and closing the session.
All client communication is done by a 3rd party system which takes JSON including client address, menu text and returns a response back to us. It takes care of actually maintaing the session on the wire, whereas we only need to do response correlation and dealing with session states.
We're expected to handle 50,000 of such sessions in parallel.
Earlier, we designed the system in Java using SEDA model. Having heard of Actors, we are willing to check them out and write a quick PoC project (Java/AKKA). My questions are:
Has anyone had experience in building such kind of an application? Is 50,000 simultaneous sessions too much for AKKA to handle? (Note, we are only waiting for the response. When the response comes, based on the answer, we jump to the next stage, so it should be possible).
Which architectural stye/paradigm which best suit this problem in AKKA? Are there any frameworks out there for this kind of problem?
This is actually a reasonably easy use case with Akka's clustering. 50K sessions represented as an Actor instance for each is not very high load. The reason to use clustering is only for fault tolerance.
The idea behind the architecture would be to have a web tier for handling RESTful requests that correspond to the sessions. These requests would be sent to the Akka cluster and routed to the appropriate session Actor by session ID, or a new one would be created. When a session is done, you stop the actor that is associated with it.
Note that the session actors should send themselves timeout messages via the scheduler. Upon completion of handling a new message, the actor should schedule itself a message via the ActorSystem scheduler for 15 minutes (or whatever your timeout is). When a new session message is received, that scheduled task should be cancelled, the new update handled, and then a new timeout scheduled. There is a plausible race condition here, in that a timeout message may be in your session actor's mailbox queue AFTER a session message, but if your timeout message includes a time of when it was scheduled (the 15 minutes ago), you can check that and ignore it and reschedule another (just as a safety mechanism to avoid a memory leak). If the time is greater than 15 minutes ago, then you stop the actor.
To see how the distribution of work to the session actors would be implemented, please see the "Distributed Workers with Akka and Java" template in Typesafe's Activator. You will have a fully running clustered Akka application that you can tailor to do the session management as I've described above. You can then export the project and work on it in Eclipse/IntelliJ/Sublime/TextMate/etc. To download Activator, see here.
I'm testing a Google Web Toolkit application and having some performance issue with multiple RPC calls. The structure of the app is:
User submits a query
Initial query is serviced by a single server-side servlet
Once initial reply received, multiple components are subsequently updated by iterating over each component and calling an update method, passing it the results of the initial query
Each component's update method does some work on the data passed to it, in addition to potentially calling other server-side services
On success of these calls, the component is updated in the UI.
With the initial query service and 1 component (effectively running sequentially), response time is fast. However, adding any other components (e.g initial query service + 2 components, these 2 components calling asynchronously) hugely impacts the response time.
Is there any way to improve / rectify this?
Example: (IQS = initial query, C1 = component 1, C2 = component 2, C1S = comp. 1 service, C2S = component 2 service)
Initial Query + 1 component
IQS, returned - propagating results, 1297273015477
C1, Sending server request,1297273015477
C1S, Sending back..., 1297273016486
C1, Receiving Complete, 1297273016522 (total time from initial call - 1045ms)
Initial Query + 2 components
IQS, returned - propagating results, 1297272667185
C1, Sending server request,1297272667185
C2, Sending server request,1297272668132
C1S, Sending back..., 1297272668723
C2S, Sending back..., 1297272669371
C1, Back at client to process, 1297272671077 (total time from initial call - 3892ms)
C2, Back at client to process, 1297272674518 (total time from initial call - 6386ms)
Thanks in advance.
Paul
I think you need to make your analysis more fine grained: in the data provided you have established that the client started the 2nd component call and got a response back 6386ms later. Some of this was
Going over the wire
Being received at the server
Processed at the server (this could be broken down, as well).
Sent back over the wire.
The GWT-RPC service really only has to do with 1 and 4. Do you know how long each step takes?
Well, I think your problem is not directly related to GWT. Because , I have used multiple rpc calls at same time, my application performance did not degraded.I think that you may have server side synchronization issues.
The overhead of http with cookies, and the sequencing of some of these (rather than firing all the request when the user is switching to another part of the application) is part of the reason why they seem to slow things down. E.G. A user requests a page, once that page's widgets are in place they fire requests for the data they're supposed to show, possibly making decisions to add more widgets based on that data (but hopefully passing the data into those widgets).
You might be looking for some tools that help you to create batched rpc calls like: gwt-dispatch. I don't think there's anything automatic.
A low-tech way to get more information is to put basic timing logging into every RPC to see how long they take. Create a new Date() at the top, subtract its ms from a new Date()'s ms at the end, print it to stdout or use Log.info() or whatever.
For something more industrial strength I used the "SpringSource tc" combined with Chrome's Speed Tracer in order to get a full stack view of what calls were taking what amount of time, and what was actually able to happen in parallel. Not trivial to set up but once I did I was able to zero in on the real issues (in my case it was getting tons of unnecessary information from Hibernate queries) very quickly.
Here's the basic info we used:
Download the tc Server Developer Edition (free)
http://www.springsource.com/products/tc-server-developer-edition-preview
NOTE: Do not even THINK about installing in a directory structure that has spaces.....
Installing tc Server: Main Steps
http://static.springsource.com/projects/tc-server/2.1/getting-started/html/ch06s02.html#install-developer-edition
Viewing Spring Insight Data In Google Speed Tracer
http://static.springsource.com/projects/tc-server/2.0/devedition/html/ch04s04.html
url is now localhost:8080 instead of the old port address for the other installation of tomcat.
One more detail, you'll need to make a .war file and deploy that to the tomcat directory. (You're not getting perf data on dev mode, but rather a local GWT compiled release)
-- Andrew # learnvc.com