We have a subscription to an RxJS Observable that's obtained from the Sanity javascript client's listen method.
This works fine except that every now and then we get an error "The operation timed out". I haven't been able to pinpoint exactly when and where this arises but I suspect it happens after a certain timeout without the subscription receiving any message. This does not, however, indicate any issue in our case.
I'm not well versed in observables; is there something basic I'm missing, or has anyone had a similar issue?
Listeners are currently automatically closed after 5 minutes. This might be what you're encountering.
It's actually a regression that we discovered recently; listeners are supposed to time out only after 30 minutes. We are expecting a fix for it this week. Edit: The fix has now been released.
It's important for a client to be resilient against any kind of error, though. On the Internet, network timeouts and other glithces are of course very common and must be handled appropriately. eventually the listener will close itself, as this is the intended behaviour.
(I'm a developer at Sanity.)
Related
I have tried IMAP idle way, which works in most time, but:
Sometimes it's missing event... the status updated which IDLE watched it's a delayed message, make my script confused.
The email ISP sometimes close the imap conneciton, connection maybe just last serveral minutes.
When lots email rush in, such as one email per seconds. IDLE status missing lot's event.
I know this is maybe mostly should blame email ISP, but is there a better way I can get email notification in time and reliable.
or I just use hard way, long loop check email?
IDLE doesn't tell you that there is one new message, it tells you that something happened. It may be one new message, or ten, it may be one message being deleted, or ten, or it may be another change. It's up to you to check. (If you want to test how your code handles it, you can cause large changes using UID COPY and EXPUNGE.)
Connections being closed is also your problem to solve. The IMAP server can close a connection (for good or bad reasons), but usually it's done by a NAT middlebox belonging to the customer. Only the client can reconnect to solve the NAT problem, and solving the NAT problem solves the server problem too, as a side effect.
I'm on a network that usually causes a ton of connection timeout issues, and ocasionally I'm running into read timeout issues as well. Retrying the code whenever a connect timeout happens fixes the problem with connecting to the server. Is is safe to retry the code whenever I get a read_timeout, or whould the response become corrupted? I'm using Ruby, with Net::HTTP client, but I guess this could apply to other languages as well.
A read_timeout means that the server did not send any data within the expected timeout. The response becoming corrupted is less likely as this is TCP.
To answer if it's safe or not to retry depends on what operation you're performing and/or any guarantees the service you're interacting with gives you.
In general GET should be safe to retry.
POST/PUT may need special handling (i.e. rereading some state before deciding to retry) as this usually means that something changes on the server.
When I issue an $.ajax query with a timeout: parameter, and my timeout is met such that error: is invoked, what does that mean?
More specifically:
does that mean the server received the request, but is still processing it? That may mean some effect may occur, so I may have to cancel it on the server, or somehow invalidate data that was already partially written to a database.
Or does that mean I was never able to reach the server at all? This is nice to know since then I don't have to deal with partial data on a server "save"
Or does that mean the request made it part of the way, and now we lost track of it? In this case, I'd have to actually ask the server, "Oh hey, about that request I sent awhile ago... did you get that one? yeah? okay ignore that last save"
OS Commands like tracert make it clear there may be many servers for a TCP command to go through, so if one becomes unresponsive, it's hard to tell if it got it or not. But some protocols require an echo-back to be considered receivable (so I'm not sure if HTTP or Apache is involved in this)
It is how long the client will wait to hear from the server before giving up.
The server may or may not have done its part. The only way for the client to know about that is for the client to be notified. Since you don't want to to leave a process or a human waiting forever, by using a timeout you specify the time to wait for success before giving up.
I am trying to handle SSL error scenarios where, for example, SSL async_handshake() is taking too long.
After some time (say 20sec) i want to close this connection (lowest_layer().close()).
I pass shared_ptr with connection object as a parameter to async_handshake(), so object still exists, eventually handshake handler is invoked and object gets destroyed.
But, still I'm getting sporadic crashes! Looks like after close() SSL is still trying to read or operate on read buffer.
So, the basic question - is it safe to hard close() SSL connection?
Any ideas?
Typically the method I've used stop outstanding asynchronous operations on a socket is socket::cancel as described in the documentation. Their handlers will be invoked with asio::error::operation_aborted as the error parameter, which you'll need to handle somehow.
That said, I don't see a problem using close instead of cancel. Though it is difficult to offer much help or advice without some code to analyze.
Note that some Windows platforms have problems when canceling outstanding asynchronous operations. The documentation has suggestions for portable cancelation if your application needs to support Windows.
We have a fairly standard client/server application built using MS RPC. Both client and server are implemented in C++. The client establishes a session to the server, then makes repeated calls to it over a period of time before finally closing the session.
Periodically, however, especially under heavy load conditions, we are seeing an RPC exception show up with code 1754: RPC_S_NOTHING_TO_EXPORT.
It appears that this happens in the middle of a session. The user is logged on for a while, making successful calls, then one of the calls inexplicably returns this error. As far as we can tell, the server receives no indication that anything went wrong - and it definitely doesn't see the call the client made.
The error code appears to have permanent implications, as well. Having the client retry the connection doesn't work, either. However, if the user has multiple user sessions active simultaneously between the same client and server, the other connections are unaffected.
In essence, I have two questions:
Does anyone know what RPC_S_NOTHING_TO_EXPORT means? The MSDN documentation simply says: "No interfaces have been exported." ... Huh? The session was working fine for numerous instances of the same call up until this point...
Does anyone have any ideas as to how to identify the real problem? Note: Capturing network traffic is something we would rather avoid, if possible, as the problem is sporadic enough that we would likely go through multiple gigabytes of traffic before running into an occurrence.
Capturing network traffic would be one of the best ways to tackle this issue. If you can't do that, could you dump the client process and debug with WinDBG or Visual Studio? Perhaps compare a dump when operating normally versus in the error state?