I know that I need to make sure that I'm logging out when working with the REST API. But if my program has crashed a few times before the logout could happen, I know there are some hanging sessions out there. Is there a way to kill those open sessions? Or do I just need to restart IIS?
Tim, your program should be written in a way to not completely crash when an exception is thrown. Ideally, it must handle all REST API exceptions and store them in a log file for further analysis.
If you don't log out, IIS will automatically close an open session once the configured session timeout expires (see Acumatica product help for more details). There is no way to "kill" an open session. If you restart IIS or recycle an app pool, you will close all open connections, both with API and web browsers.
Related
i have a problem with nodejs. I process a lot of files with nodejs. My admin has now informed me that I create hundreds of login and logoff actions on the Windows File Server within a second. He asked me to check whether this is really necessary and can possibly be minimized. I think that access to the one file always creates a new session on the Windows File Server. Is it possible to set up some kind of thread pool to keep the session active on the server?
My Chrome Extension's background page is set up as an event page, i.e., most of the time it is asleep unless some registered event listener wakes it up.
I'd like to be able to occasionally send messages from my server to the event page of an individual user of my extension. They should not necessarily show up as a desktop notification, it would rather be up to the background script to decide what to do with any incoming message. It might very well store some information in localstorage for example. If the user client was offline at the moment the message is being sent, it would ideally be delivered once it comes back online.
I'd like to avoid polling my server at regular intervals every time the background script is awake, though that would be an obvious solution.
My question is therefore if it is possible to register a special kind of event in my event page so that it wakes up and triggers some functionality once there's an incoming message from my server. Ideally, the server message would not be a general broadcast to all my users, but rather a targeted message to a specific user.
What options do I have?
I read about service workers and their Push API but it seems they are only slowly being rolled out to Chrome Extensions. I am not sure if they are ready for the browser's stable release yet and didn't find any documentation on how they work with extensions.
I also read a bit about Google Cloud Messaging but it is deprecated in favor of a new costly Firebase solution.
Service worker functions like a proxy server, allowing you to modify requests and responses, replace them with items from its own cache, and more. While Chrome has its own approach to caching/installing the resources need to display a Chrome Extension. Therefore, there will be an error when you will attempt to intercept the registration of a service worker to a Chrome Extension.
See for more information:
Introduction to service worker
Service Worker script errors if run in chrome extension
See related SO post:
Chrome Extensions with service worker receiving push notifications
Essentially, I'm trying to work out the best way to ensure that a user is connected to the server / the internet and is thus able to make requests in my application without error.
I have come across various solutions, but I can;t really decide what is the best performing or useful.
Websockets, using Socket.io to keep an open connection with the server for each client. Also opens up the possibility for real time updates in my app, which could be a nice thing in the future. However, having lots of open sockets is sure to be hard hitting in performance.
Polling, so having an endpoint in my API that the angular app hits every 5 seconds or so to check the user is connected. Again, seems like it isn't a good idea to be hitting the server a load.
Waiting for an error, then start polling every couple of seconds to wait for the connection to be re-established. This is a little change on the above. However, you are still waiting for a user to fail, which isn't good for user experience.
Does anybody have any informed input on this issue?
Thanks
I'm developing a node web application. And, while testing around, one of the client chrome browser went into hung state. The browser entered into an infinite loop where it was continuously downloading all the JavaScript files referenced by the html page. I rebooted the webserver (node.js), but once the webserver came back online, it continued receiving tons of request per second from the same browser in question.
Obviously, I went ahead and terminated the client browser so that the issue went away.
But, I'm concerned, once my web application go live/public, how to handle such problem-client-connections from the server side. Since I will have no access to the clients.
Is there anything (an npm module/code?), that can make best guess to handle/detect such bad client connections from within my webserver code. And once detected, ignore any future requests from that particular client instance. I understand handling within the Node server might not be the best approach. But, at least I can save my cpu/network by not rendering to the bad requests.
P.S.
Btw, I'm planning to deploy my node web application onto Heroku with a small budget. So, if you know of any firewall/configuration that could handle the above scenario please do recommend.
I think it's important to know that this is a pretty rare case. If your application has a very large user base or there is some other reason you are concerned with DOS/DDOS related attacks, it looks like Heroku provides some DDOS security for you. If you have your own server, I would suggest looking into Nginx or HAProxy as load balancers for your app combined with fail2ban. See this tutorial.
I have a java based web application(struts 1.2). I have a requirement to display a status on the frontend (jsp). Now the status might change which my server gets notified by another server. But I want this status change to be notified to the browser.
I don't want to make a refresh at intervals. Rather I have to implement something like done in gmail chat, ie. the browser gets notified by changing events on the server.
Any ideas on how to go about this?
I was thinking on lines of opening a request to server for status, and at the server end I would hold the request and wouldn't respond back until there is a status change. Any pointers, examples on this?
Best possible solution will be to make use of XMPP protocol. It's standardized and a lot of open source solutions will get you started within minutes. You can use combination of Smack, StropheJS and Openfire to get your java based app work as desired.
There's a method called Long Polling (Comet). It basically sends a request to the server. The request thread created on the server simply waits for new data for the user, with a time limit of maybe 1 minute or more. When new data is available it is returned.
The main problem is to tackle the server-side issue, you don't want to have one thread for every user just waiting for new data. Of course you could use some asynchronous methods depending on your back-end.
Ref: http://en.wikipedia.org/wiki/Push_technology
Alternative way would be to use WebSockets. The problem is that it's not supported by all browsers today.