I am having trouble with Openx; here is the issue
OpenX::Services::Base.connection returns the class variable ##connection which is populated by OpenX::Services::Base.connection if it has previously not been initialized.
The problem with it being a class variable is that it persists across connections, which means if there is a lull in activity, the XMLRPC session between my site and OpenX will time out, and the OpenX API has no provisions for communicating an expired session, which would be wasteful anyways as it would require a request before every communication just to verify that the session was still valid.
What I think would be a better way to do it would be to instantiate a connection at the beginning of any request that needs OpenX support, and to close it at the end, ensuring that there is no possibility of a session time-out on the XMLRPC side of things.
Has anyone else encounted this when using OpenX / OpenX XMLRPC? If so how did you resolve this issue?
I have a try/catch block around the OpenX RPC call, and I wrote an exception translator. If I detect a session timeout I will execute a again the login operation, I will take the new session id and I will run the failed OpenX call again. It is a little bit more complicated than having a cron job in order to keep the session alive but more performant and robust (in my opinion).
We faced the same issue. Our solution: Create a unauthenticated controller which does some simple interactions with the OpenX API (just to keep it live) and have this URL invoked by a cron job every 5-10 min.
What solution did you use?
Related
In a bid to try and make my Parse powered app more secure I would like to be able to expire sessions on the server side. Upon launching my App (or visiting the Web App) I will run a check to see if the Session Token is valid.
Where I am struggling is actually being able to monitor the activity of a session. Parse.com have alluded to this capability, however it is impossible to find anything mentioned in their documentation on the subject.
Additionally moving to NodeChef has given me the option to 'Expire In Active Sessions' However, it is not mentioned anywhere how it actually functions or how you can interact with this through cloud or client side code.
I do have the option of setting the session expiry time, however this is a hard and fast rule - it will happily expire the session even if the user is active! Not a nice user experience.
Does anyone have any ideas how I can manage this?
I used this solution:
Create cron job (in Linux) or Schedule Task (in windows) with Parse Code Function that will delete your expired token (With your costume logic)
I have the problem that my software has critical data stored in the session.
Since I'm using ajax and the user can simply open the software in several tabs there WILL be parallel requests.
Limiting it to one request at a time is unfortunately not possible.
My original attempt to solve this problem was to use an after_filter in my application_controller to call a method that would detect changes other workers made and merge them into its own session object before saving it.
Unfortunately that did mitigate my problem but not solve it completely.
It seems to me that between my after_filter and the middleware that actually saves my session, which is ActionDispatch::Session::RedisStore, there is still a gap big enough for another worker write his own session.
I cannot think of any other solution to close this gap but this one:
Write a class that inherits from the middleware
teach it to execute the "merge code" in get_session and set_session
replace the original middleware with my class by config.middleware.swap
Before I do this I would like to aks for opinions and advice or, ideally, a better solution. Messing with the middleware seems too dangerous to me to do without asking for advice first.
Since you said the data in session is critical, I think it's better to synchronize requests from each user, while keep concurrency between different users.
For example, you can fire up several rails processes, each listening its own port, and provide a load balancer (e.g. Nginx) above those processes.
A load balancer with session sticky feature is perfect, but IP hash is also acceptable.
Im doing session timeout with php. Im calling php
through ajax. After X seconds of inactivity, if a user
sends a request it is redirected to login page as session has already expired.
How do I send a session timeout message back to browser automatically
and not waiting for a request trigger?
Like, I should have a thread running in the background to check the time
always? Do you have ideas guys?
Thanks a lot.
Sending a request from the server to the browser via ajax is known as long polling, or "comet". It is a proven technique, but now without pitfalls.
For one, a connection need be kept open for each user. That's a lot of overhead, so it should be done with something like NodeJS. Even so, the long poll need be reset every 20s or so, which result in fickle code. Newer browsers introduce websockets, which improve things but require a framework with fallback mechanisms. The question is whether it's worth it for your application.
What I would do in your situation is implement the same timeout mechanism in JavaScript. That way, the user gets a nice message when the session times out in JavaScript, and the server enforces the timeout in case the user bypasses the browser for some reason.
We have 2 core applications running on our servers on CF 8, and both have the exact same session timeout set in the application CFC (2 hours at the moment). However we're seeing that sessions are spiralling out of control for one of the applications (currently at 120,000+ on one server), lets call it AppA whereas AppB seems fine (and AppB is the one we'd expect a lot more traffic to).
So I did some further digging and found out that most of the sessions for AppA have been idle for many hours with the highest value I've seen so far being over 11 hours.
We're not actually doing that much with sessions so I'm a little confused as to why they're not being timed out as expected. Also I've dumped the this scope in the application CFC and it is showing the expected value for sessionTimeout.
The only thing I had noticed is that in one instance we're assigning a variable on the Request scope from a Session variable. If it were a different scope I would maybe think that is causing some sort of reference that GC (or whatever) can't clear.
In terms of the spiral, I'd say that's to do with some requests which aren't passing through the CFID/CFTOKEN to maintain the session. This could be web service calls, CFHTTP requests, search engine bots, etc. Sounds like one of your apps is experiencing this. If this is the case then for CFHTTP pass the CFID/CFTOKEN through to maintain sessions. Web services bit more tricky, you'll need to create a 'key' which is passed back and forth, whole separate topic! Bots can be handled by having some conditionals to set the session timeout value.
For the 11 hours, I'd say thats due to it been kept alive by something. Some continual polling? Reocurring AJAX request? It would have to be something that continues to pass the ID/TOKEN through.
I used to get server lockups in CF6.1 when I was persisting CFCs in the application or session scopes. Now I instantiate them in the request scope and the lockups stopped happening (with no noticeable performance drop). Maybe you have a similar issue.
Actually turns out the sessions were started from another App which wasn't over-riding the default value in the base Application.cfc (including the application name).
The session timeout in web applications typically denotes the idle time - i.e. the period of time when the user doesn't work with the application.
Now, what if there is an automated script written that posts a request every 5 minutes - wouldn't that user's session go on endlessly? This being the case, won't this approach heavily load the application affecting its performance in the long run?
Running an automated call to the server, say via an AJAX request, will keep the session alive. Typically that's the point though. An interesting side effect of this is that if the request happens predictably and regularly, you can use it as a "ping" to determine if the user's browser is still open. If one or two pings are missed, you can close the session earlier and actually free up resources sooner than if you just let the session time out.
Yes, and Yes.
This is why if you're going to write an application for the web, you really want to find a way to implement it without using server side sessions. Usually, you will be able to find ways to implement the same functionality using cookies -- then the session data is client-side so who cares if they stay active permanently.
I did something similar for an application that relies heavily on session data.
What I did was set the IIS timeout to a relatively low number, say 10 minutes, then have a timed AJAX call that pings a blank page every 5 minutes.
This overhead on this is actually fairly low, as all you are doing is requesting a blank page, and if a person closes their browser, the session ends in 10 minutes.
You want to keep session as small as possible. That said, if everyone starts doing that, of course it will load your application, with(out) session. If you think your users are compelled to do that, consider why, as either your application is missing an important feature or is forcing them into something.
Now, regardless of that, if you are expecting lots of users to be active at the same time, so much than a single server won't do, then you would will end up having the session out of process. If the session is in Sql Server, it is just saved data, so in that case we wouldn't be talking about memory usage.
Well... I guess "It Depends" The first question you should ask yourself is whether you even need session.
If you have an automated process, my guess is that you don't really need to use session.
In that case, either turn it off or don't worry about it.
I guess your session table would be a little bit larger, but on the other hand you won't be tearing down and recreating the session. I don't see how this would "heavily load" the application. I suppose it would depend on the application itself and how much memory is used to maintain session state.
It would allow the use's session to go on endlessly, as long as they have their browser open. If need to keep a session alive for an extended period of time, you could also track the sessions via the DB and not in memory.
Also, if you are worried about the indefinite open session, you could implement a timeout from when the session opened and if there is an extended idle time.