I don't really know if this is just Meteor of Angular-Meteor, but I receive this error message a lot (in client console). Of course this should be in response to bad code on my part. However I am wondering when should this appear and what situation it tries to describe?
Thanks and bye ...
I think it happens on auto-refresh of the local meteor server (ie: each time you modify a file).
Related
I'm trying to connect my Erlang code and Go code with gRPC, during which I found that if I connect to gRPC too many times at the same time my socket would be closed by Go server, further stops my Erlang client (a gen_server). No error info was given to me, just a simple code in Erlang showing that http2_client socket closed by peer #Port<some port info>.
I'm sure that the limit of concurrent streams gRPC allowed is not reached (as my debug log did not show that we reached that place), and after a carefully look I found the problem occurred in google.golang.org\grpc\server.goserveStreams (line 830), and my logs showed that all the streams successfully reached var wg sync.WaitGroup, but could not finish remaining parts to come back to defer st.Close().
Could someone please kindly help me with this strange error, or at least give me some directions I should look into?
I have managed to solve this problem now, and thus come to answer it.
It turned out that I was using a different log system for debugging, therefore the default Golang error messages are not collected and presented to me... Golang keeps screaming and shouting at me, but I was sitting in another room and cannot hear it.
To the socket problem, this is because the whole connection is closed, due to the lack of long connection support in my 3rd party library http2_client.erl. After manually add a heartbeat to each connection, all problems are solved and the gRPC works just fine.
Then more I research then more I think of it as a hypothetical question.
In my application I try to proceed all command frames correctly. But while building an application I've encountered one issue: NodeJS default http server closes socket after 120 seconds of inactivity. But that's fine, I can easily disable this timeout. But why not to make it actually controllable? So now I implemented an interface to adjust timeout delay. And now I have another issue: server just break the connection. Silently. That is not really good practice for WebSocket protocol, I should send close command frame first. But which status code should I provide?
Documentation describes a set of status codes, but in general they are (1) job is done, (2) server/client going down, (3) some error occurred, (4) protocol reserved:
https://www.rfc-editor.org/rfc/rfc6455#section-7.4.1
And it's unclear to me, which one to choose for idle timeout? It sounds like 1001 (going away) is closer one, but I see nothing in documentation, and found no one ever asked this question.
So which one should I choose? Any ideas?
I was puzzled too. Seems to be no answer that is easily googleable here in 2022.
In my case I've decided to go with 1002 Protocol Error, since not answering to ping is basically protocol violation
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 have done something silly and written a script for a website that does an ajax check every 2 seconds. In this case its using wordpress and its admin-ajax.php file every 2 seconds. This essentially burned up all the CPU power of the server, and made every site on the server run really slowly.
After a lot of detective work, i finally found the script and stopped it, so that it doesn't happen on new loads of that website. But looking at my apache log, i can see that it is still running in one browser somewhere.
Is there a way for me to stop that browser from requesting that ajax-call, or perhaps block it from my server? Or will I just have to wait until that browser is being refreshed or closed?
Try to use netstat or something similar through ssh to detect the IP and port of the unknown browser. Also you should try to reboot the server so it may will loose connection.
PS: It's pretty hard to give a clue or answer in the right direction without having any logs or evidence to ensure you answer to this question correctly.
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?