jim.marion wrote:And even if you got it, is this a worth overload ? I don't know what could make the value changes to Y less than a second after the previous update to N (and popup). And if the value is back to Y in that interval, then a new popup will be send a second later, what human can click every second on a popup window ? I'm sure, the customers have better to do than click on popup.
... (unless you store OPRID, session ID, or some other ID per Y response).
That is what makes it so critical to notify the client rather than waiting for the client to ask. As far as network saturation, using Ajax is a definite concern.And I can assure there's many admin who'd be scared about that.
Using long polling/sockets, that is different and should not be an issue. My only concern with long polling/sockets would be maximum concurrent connections exceeded at the server. But after reading this blog post, I don't think it will be a problem: http://blog.caustik.com/2012/08/19/node-js-w1m-concurrent-connections/.I cannot comment, it's out of my knowledge here. But I'm sure PS has not been designed for this.
And even if you got it, is this a worth overload?No. I would not recommend a 1 second ajax interval. That is why I propose a notification option using socket.io and having a real time update sent into node.js from the database, effectively eliminating polling. In my scenario, the database notifies node.js and node.js sends a response to all those waiting requests. Nevertheless, for the original poster, creating the initial Ajax version was a good and necessary learning process.
What about the timeout ? I mean, usually after x minutes of client inactivity, the client is disconnected. Does this solution marks the client as "active" even if he/she does not touched anything ?No, it would not keep the PeopleSoft session active. Once the redirect to the signon page happened, the web socket would close and notifications would stop. The service side of this solution is outside of PeopleSoft, because, like you said, PeopleSoft's design doesn't support it. Since it is outside of PeopleSoft and does not go through the Weblogic server, it won't touch the PeopleSoft session.
And I can assure there's many admin who'd be scared about thatThis is a misunderstanding. The client initiates the connection. The server keeps the connection open until it has a response. Firewall rules would never allow a server to connect to a client and no admin should allow a web server to initiate a connection to a client. The comet/long polling/socket.io approach uses standard HTTP where the client initiates a connection for the standard request/response cycle. The key difference is that the server doesn't return a response until it has one to send. There is no real TCP/IP overhead involved in this. You just have to make sure your OS is configured to support enough concurrent connections, since client connections will be active.
By the way, what about firewall for internet client if any ?
I'm probably too old for such approachNicolas, you are FAR from too old. This is very similar to using RENS.
jim.marion wrote:Yes, sure, not in that case. I rather thought that could be an alternative for the Sabari's case.
... It might not be valuable though if the message is, "Server is going down in 10 minutes for maintenance."