I have a Spring MVC project in Java. This web app can be accessed by multiple users in different browsers. I haven't coded any session bean in my program.
Now I want to 'crash'/'timeout' the browsing of one of the users, while other users will go on with their normal expected browsing. I want to do this to see if this action has any effect on the shared variables.
What kind of coding I need to do for this? Thanks in advance!
It is not at all clear what you are trying to achieve here, but I'm assuming that you are doing this as an experiment ... to see what happens.
You could modify the webapp to implement some special request, or request parameter, or request parameter value that tells the webapp to crash or freeze the request being processed. Then send that request from one browser while others are doing "normal" things.
Whether this is going to reveal anything interesting is ... questionable.
Another interpretation is that you are aiming to include timed out requests and other things in your normal testing regime. To achieve that, you would need implement some kind of test harness to automate the sending of requests to your server; i.e. to simulate a number of simultaneous users doing things. There are various test tools for doing that kind of thing.
Related
I have a Liferay instance running on a URL like example.org/app. This instance does have a REST API that would normally be running under example.org/app/o/restpath.
The way the server running this instance is that the frontend is accessible without restrictions from the outside, however the REST API is only accessible from the inside the network under a URL like example.org/rest.
I need to make sure that it is impossible to access the REST API with example.org/app. I should also be impossible to access the frontend with example.org/rest. Does anybody have any suggestions?
There are tons of ways of doing that, the best one will depend on your stack, preferences and abilities.
A reverse proxy is the first that comes to mind, bearing in mind that is is normally better if your app has control of who can access it. So a wrapper or a filter checking who is accessing would help. But even then, is the filter to be put on the main application or on your module? That is an evaluation that needs to come from you.
You can also combine the proxy strategy, with a filter, just in case one day you are tuning up your proxy and let something through. You can also decide change your proxy server too..
Or your company already have a proxy that enables traffic going out, and would be easier if that proxy was to have access...
Your servlet contained might also be able to provide such control, so you do not actually need a proxy.
Although I would feel more comfortable if that kind of feature was in the application layer itself, like a wrapper for your component and that wrapper provides the service, a filter, or even a method in in the entry-point, while the others are just extra and to reduce load.
Some companies have networks devices that go up several layers of the network stack, those have lots of potential to help here too, IDS would be able to provide alarms, triggers and such...
As it stands, one would need more information to help you more, even in what you mean by "ensure" ( how far this assurance need to go, like are you thinking about passwords, certificates, IDS, or a simple approach like the mentioned ones ), but I guess that covers it.
Having an existing GWT what kind of pattern should I follow if I want to display to all the users a system wide message like:
System is undergoing maintenance, excuse the potential slowdown here and there.
For new users loading the app I can think of ways of pre-populating their initial page, but for users that already have loaded their SPA page then I cannot think of any elegant way to push the message.
And an equally elegant way to retract the message, when the "maintenance" ends some time later on.
Should I use a timer and ask the server a list of messages to display, and have it run in the background...?
Thanks!
This is IMHO the old way to do this kind of things (polling), but the elegant and modern way is to use server side events via html5 (using something like atmosphere) or any websockets simple gwt library), etc. If you follow this pattern, check also this other related question.
If you don't have other instant server-to-client messages to receive, a simple polling mechanism is most easy to implement and understand. More complex solutions that support instant server-to-client messages are websockets / server side events / long polling.
Also note:
If you are using GWT RPC Services, swapping the backend for a running client will result in a IncompatibleRemoteServiceException, if ...
[...] One of the types used in the RemoteService method invocation has had fields added or removed. [...]
The message of this exception reads "This application is out of date, please click the refresh button on your browser." You might want to check for this Exception in the onFailure methods and (ask the user to) reload. See the link for details in which other cases this exception occurs.
I'm developing an MVC spring web app, and I would like to store the actions of my users (what they click on, etc.) in a database for offline analysis. Let's say an action is a tuple (long userId, long actionId, Date timestamp). I'm not specifically interested in the actions of my users, but I take this as an example.
I expect a lot of actions by a lot of (different) users par minutes (seconds). Hence the processing time is crucial.
In my current implementation, I've defined a datasource with a connection pool to store the actions in a database. I call a service from the request method of a controller, and this service calls a DAO which saves the action into the database.
This implementation is not efficient because it waits that the call from the controller and all the way down to the database is done to return the response to the user. Therefore I was thinking of wrapping this "action saving" into a thread, so that the response to the user is faster. The thread does not need to be finished to get the reponse.
I've no experience in these massive, concurrent and time-critical applications. So any feedback/comments would be very helpful.
Now my questions are:
How would you design such system?
would you implement a service and then wrap it into a thread called at every action?
What should I use?
I checked spring Batch, and this JobLauncher, but I'm not sure if it is the right thing for me.
What happen when there are concurrent accesses at the controller, the service, the DAO and the datasource level?
In more general terms, what are the best practices for designing such applications?
Thank you for your help!
Take a singleton object # apps level and update it with every user action.
This singleton object should have a Hashmap as generic, which should get refreshed periodically say after it reached a threshhold level of 10000 counts and save it to DB, as a spring batch.
Also, periodically, refresh it / clean it upto the last no.# of the records everytime it processed. We can also do a re-initialization of the singleton instance , weekly/ monthly. Remember, this might lead to an issue of updating the same in case, your apps is deployed into multiple JVM. So, you need to implement the clone not supported exception in singleton.
Here's what I did for that :
Used aspectJ to mark all the actions of the user I wanted to collect.
Then I sent this to log4j with an asynchronous dbAppender...
This lets you turn it on or off with log4j logging level.
works perfectly.
If you are interested in the actions your users take, you should be able to figure that out from the HTTP requests they send, so you might be better off logging the incoming requests in an Apache webserver that forwards to your application server. Putting a cluster of web servers in front of application servers is a typical practice (they're good for serving static content) and they are usually logging requests anyway. That way the logging will be fast, your application will not have to deal with it, and the biggest work will be writing a script to slurp the logs into a database where you can do analysis.
Typically it is considered bad form to spawn your own threads in a Java EE application.
A better approach would be to write to a local queue via JMS and then have a separate component, e.g., a message driven bean (pretty easy with EJB or Spring) which persists it to the database.
Another approach would be to just write to a log file and then have a process read the log file and write to the database once a day or whenever.
The things to consider are: -
How up-to-date do you need the information to be?
How critical is the information, can you lose some?
How reliable does the order need to be?
All of these will factor into how many threads you have processing your queue/log file, whether you need a persistent JMS queue and whether you should have the processing occur on a remote system to your main container.
Hope this answers your questions.
I heard a web application should be as stateless as possible. But it seems to me very hard to realize this often. For instance, what if I:
Process a request
Redirect the user to the start page
Want to display the result of the request?
If the result is a little bit more complex, then just a string which could be passed as a parameter (or I don't want to include that information via URL), then I cannot combine 2. and 3.
The only solution I can think of here is keeping the information as states in the Java program.
But that would break with the rule of a stateles web application, wouldn't it?
I heard a web application should be as stateless as possible
What? There is state everywhere in a web app, both in the client and on the server. Frameworks like Sproutcore/Ember even have components called State Managers to manage, um, the state.
The server maintains some state in a user's session (typically).
Did you hear that HTTP is stateless? That's another story, and completely true. Also, it can be a good idea to write server side components that don't share state, due to threading concerns. But neither of those points should be taken to imply that your application doesn't have state.
I have a project. In the first project I set the session
in my first project I put here as code
req.getSession().setAttribute("x", name);
return "ses";
In second project I put here
model.addAttribute("ses", req.getSession().getAttribute("x"));
return "oses";
but session is not appear.
How to make a session appear in different project with Spring framework?
You can't. (Well, perhaps you can setup some sort of session-replication, but you shouldn't do it. See related question)
You should use other forms of communication between your applications. The flow will be more complicated and will include exchange of tokens through (simple) web services, but it is better than relying on the server container, and on the fact that both applications will be run in the same container.
It'd be helpful to describe what you're actually trying to accomplish; as Bozho says you can't really share session objects between apps.
You could, however, use JMS (or any other intra-app comms) to send data from one app to another. You'll still need the capability to decide what to do with that data once you have it in the receiving app: how do I associate it with a given user, how do I get it into that user's session, and so on.
User information can be passed in the message, but there has to be some commonality between the two systems, some agreed-upon key, that can be used to figure out who the info belongs to.
Once you have that, the rest is mechanics; there are interesting games to be played, and it's easy to mess it up :)