I am using "connect-timeout": "^1.7.0" as a top-level middleware in my express.js 4.12 ("express": "^4.12.3") app. I have no problem in using it as such. I can set the timeout to 50 seconds, 5 seconds, 1 second, all of which function perfectly fine. HOWEVER, I'm noticing that if I set the connect-timeout timeout value to anything greater than 110 seconds, the app will still timeout after 110 seconds with the following message:
"HTTP request was terminated because the script did not produce output for 110 seconds"
Is there some other setting that needs to be adjusted? I can't find any reference of such a setting. Any help or insight would be very much obliged! Let me know if you need any more info from me. Thanks!
Best,
Chris
(Do not worry that the process itself is taking more than 110 seconds, this is intended behavior)
It might be possible but I doubt it. Only your own custom client would wait that long though. And if its your client you might still need to output something to keep the connection open. You could output a newline or . every 30 seconds.
Interested to hear if there is a way. I have found that people really don't want to leave idle HTTP connections open so you are swimming upstream.
Are you sure your client didn't disconnect?
Other options are things like RPC, TCP server, polling an HTTP endpoint for status.
The node.js app is hosted on an Apigee Private Cloud VM cluster, and the timeout is occuring due to a timeout property on the Router/Message Proc. VM.
Within the nodejs.properties file, the property http.request.timeout.seconds is set to 110 seconds by default. One could augment this value to the desired value or set it to 0 (which effectively disables the timeout).
Best,
Chris
Related
Describing of context: java app (running under wildfly) works under high workload and heap is almost filled. Because of that full GC runs often and this leads to frequent long Stop The World phases.
While these phases I try to make login request.
So, if I make this request via front-end side (I just open login page, fill fields and click login button) I see this:
It is interesting that I get canceled request ALWAYS after 50 seconds and front-end even canot make tcp handhaske.
But if I make the same direct request just using console devtools of chrome (alternative is using postman, for example), I see this:
In that case browser establish tcp handshake, send reqiest and wait 2,6 mint for first byte from the server etc,.
Why I see that difference behavioral ? What is root cause of that ?
I've been investigating similar issue, where something killed the request between BE and FE after exactly 50 seconds and I ran into this question. So I am posting here in case it helps someone in future.
In our case, it was the k8s Openstack loadbalancer timeout that did not wait for backend's response:
https://docs.openstack.org/octavia/latest/configuration/configref.html
Specifically timeout_client_data and timeout_member_data.
We updated the IstioOperator settings in spec.components.ingressGateways.k8s.serviceAnnotations with following annotations:
loadbalancer.openstack.org/timeout-client-data: "180000"
loadbalancer.openstack.org/timeout-member-data: "180000"
to increase the timeout limit and then we were able to receive response successfully.
You can find more details on loadbalancer annotation possibilities here:
https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/openstack-cloud-controller-manager/expose-applications-using-loadbalancer-type-service.md
This is not a post about HOW to change channel's name (I know it).
I have an international server using several bots. And we all depend on UTC time (to coordinate through the world). So there was borned a solution to make a time-bot which will show current UTC-time in the dedicated channel nobody can visit. And yes, precision is necessary, even seconds.
I created a voice channel with permissions not to join for #everyone. Everything worked fine, it updated every 1000 ms. Then (after several months of good work) something was broke, it started updating incorrect. I've increased update interval up to 5000 ms and it have started to work fine... until yesterday.
Now it doesn't work anymore. Even if I increase interval much more. It works sometimes I don't really know what the interval is, it's huge and unpredictable.. the time-bot is broken for now and cannot be used anymore in that case.
Is there any restrictions for updating channel name? I can't find any information about this in available documentations.
Client.setInterval(() => {
const { h, m, s } = getTime();
channel.edit({ name: `${getClockEmoji({ h, m })} UTC: ${h}-${m}-${s}` }).catch((err) => console.log(err));
}, updateInterval);
Providing data is correct, 'cause I send it to console and it updates as good as I need in interval I set. But channel name not updates that often..
Does discord filter too often update requests?
discord.js version is v.12.2.0
Discord had set the rate limit for things like channelrename to 2 requests per 10 minutes.
"Normal" requests like sendmessage is limited to 10,000 per 10 minutes.
This seems to likely be an issue directly related to rate limiting:
https://discord.com/developers/docs/topics/rate-limits
IP addresses that make too many invalid HTTP requests are automatically and temporarily restricted from accessing the Discord API. Currently, this limit is 10,000 per 10 minutes. An invalid request is one that results in 401, 403, or 429 statuses.
For every API request made, we return optional HTTP response headers containing the rate limit encountered during your request.
You should probably decrease the interval by a considerable amount to reduce the risk of the IP being restricted.
Currently, I want to check status of socket when network is down with connected property. But i have an issue when unplug network cable, the connected status still true for 20 seconds or more. How can i get the status immediately ?
You'll have to set the timeout option, which by default is set to 20.000 MS (20 seconds). You can find a lot of information here: http://socket.io/docs/client-api/#
I would disrecommend making it absolutely instant though. Most if not all networks have some instabilities, which are accounted for by the timeout delay. It's there for a good reason. Maybe just make it a bit shorter?
Hi I'm new user to atmosphere, and set up a simple test that worked fine. We used long-polling, and the behavior was that my client would send the server a GET that would stay open until:
data was returned by the server
a minute elapsed
in both cases, the client would immediately send another GET for the server to hold open. Most of the time no data was sent, so every minute the GET would be "refreshed." I assumed this was the default behavior because maybe certain browsers or networks would shut off a GET that exceeded a certain time limit, so this was a way to avoid that.
Question:
Is this refresh controlled by the client or the browser? I poked around and couldn't figure out if the client was closing the connection on its own and sending a new request, or if it was the server.
The reason I ask is that the server got deployed, and now that refresh is no longer occurring. My client GET now stays open to the full 5 minute (default) timeout and then throws the timeout event, then reconnects for another 5 minutes.
Server team claims "nothing changed," ha-ha. So did I do something or what? Please let me know! Thank you!
request object:
var request = {
url: 'xyz',
transport: 'long-polling',
reconnectInterval: 5000,
maxReconnectOnClose: 20,
enableXDR: true
};
Edit: the atmosphere server was changed from 2.1.3 (working) to 2.0.7 (not working) when the deploy occurred. When changed back, the 1 minute refresh behavior re-appeared. The problem is that 2.1.3 is not compatible with the server they are using, thus the down-grade.
Question: what is this feature called, is this the heartbeat or something else? Can someone tell me what change was made that would cause this. I've looked through the release notes and nothing jumped out at me.
I have an area in my page where messages go when a database has changed. Now, some days the database will change so much that a new message is displayed every 10 minutes; other days it will change only a few times. The issue I am having is that the EventSource seems to time out after 1hr 22 minutes, and no longer will the browser receive notifications.
I am wondering if there is a way to keep EventSources persistent (i.e., for as long as the browser is displaying the page, the EventSource is alive). According to what I have found in my Google searches, EventSources should remain alive until the tab/window is closed. Unfortunately, there seems to be so very little that I find in my Google searches, and for me this doesn't seem to be the case.
You don't say where the socket closure is happening (on the browser, socket on client machine, socket on server-side, etc.) but it doesn't really matter as the fix is the same for all of them: send keep-alive messages.
The server should send a keep-alive message. Either every, say, 15 seconds; or only after 15 seconds of inactivity. (Whichever is easier to code, server-side, for you.) It can be as simple as an SSE comment: ":\n\n" (lines starting with colons are ignored). I prefer to send actual data, because:
You get to see a message, allowing client-side keep-alive checking (see below)
There is bound to be something useful you want to send, like a timestamp (for a check that client/server clocks are in sync), or metrics, etc.
On the client-side, run a timer with setTimeout() set to 20 seconds. Each time you receive any data from the server (whether genuine data, or your keep-alive), kill the timer, and start it again. Therefore the only time the time-out function will get called is if your server went more than 20 seconds without sending you anything. When that happens, kill the connection and reconnect.
The above is assuming the problem is at the socket-level. The problem might instead be the browser is crashing: perhaps it has run out of memory. The fix I'd do in that case is a once/hour timer (setTimeout() in JavaScript), to manually close and re-open the EventSource connection. Or clear out some memory buffers you might be using. A bit of profiling with FireBug or Chrome tools will tell you if you have a memory problem.
Plug: Over half of the "Making our App production quality" chapter in my coming-soon SSE book is about keep-alive and using LastId on the reconnect. Please buy when it comes out :-)
I had the same problem with Chrome reporting "net::ERR_SPDY_PROTOCOL_ERROR 200" every two minutes.
Sending SSE comments every minute solved the problem for me. See the Nodejs / Express example code below.
exports.addWebServices = function(app) {
app.get('/ws/clientEvent', function(req, res) {
res.writeHead(200, {
'Content-Type': 'text/event-stream',
'Cache-Control': 'no-cache',
'Connection': 'keep-alive'
})
/* Event handlers for SSE here */
let keepAliveMS = 60 * 1000;
function keepAlive() {
// SSE comment for keep alive. Chrome times out after two minutes.
res.write(':\n\n');
setTimeout(keepAlive, keepAliveMS);
}
setTimeout(keepAlive, keepAliveMS);
}
}