I was executing RSeval(c,"4+5"); and encountered :
Error in RSeval(c,"4+5") : remote evaluation failed
in a remote machine connected to a linux server which is running daemon Rserve, where c is connection object. The connection was successful though.
Please share your insights.Thanks in advance
That could be many things, e.g. if Rserve requires authentication. If that's the case, you can use RS.connect and RS.login from the more modern implementation of RSclient (see http://cran.r-project.org/web/packages/RSclient/RSclient.pdf).
Related
I'm trying to connect to a server from my client using gRPC, but connection always fails only on my pc(macbook pro). My teammate tried with the exact same code, and it works perfectly fine. The following is the error messages from each client and server. We are using protobuf 3, python 3.9. Can anyone give me some hint? Thank You.
Client Error Message
grpc._channel._MultiThreadedRendezvous: <_MultiThreadedRendezvous of RPC that terminated with:
status = StatusCode.UNAVAILABLE
details = "Failed parsing HTTP/2"
debug_error_string = "{"created":"#1626678822.089372000","description":"Error received from peer ipv4:10.113.66.145:9390", "file":"src/core/lib/surface/call.cc", "file_line":1067,"grpc_message":"Failed parsing HTTP/2","grpc_status":14}"
Server Error Message
[07/19 01:29:32 cctv_service]: Session Connected
E0719 01:29:32.744434791 14615 parsing.cc:302] Unknown frame type 71
I0719 01:29:32.744519637 14615 chttp2_transport.cc:812] W:0x7f3364002ae0 SERVER [ipv4:10.25.211.173:50662] state IDLE -> WRITING [CLOSE_FROM_API]
I0719 01:29:32.744554230 14615 chttp2_transport.cc:812] W:0x7f3364002ae0 SERVER [ipv4:10.25.211.173:50662] state WRITING -> WRITING [begin write in current thread]
Updated MacOS 11.4 to 11.5, problem never appeared again.
We have a client and server communicating each other with grpc. Previously the server was running on Windows Server, and the client running on Linux or MacOS. Everything works perfectly until we migrate the server from Windows Server to a docker container.
Then we observed some weird tcp broken when we send a large amount of request from client to server.
Then we dig into the grpc arena and run our client and server with GRPC_VERBOSITY=info and GRPC_TRACE=tcp. Then we found that the disconnection was caused from the server side, with error message below:
tcp_custom.cc:218] write complete on 029FCC20: error={"created":"#1594210168.896000000","description":"TCP Write failed","file":"d:\a\grpc-node\grpc-node\packages\grpc-native-core\deps\grpc\src\core\lib\iomgr\tcp_uv.cc","file_line":72,"grpc_status":14,"os_error":"message too long"}
So my question is what does the os_error: message too long really means? What is the next step for me to investigate?
Linked issue
The string "message too long" is the error message for the error code UV_EMSGSIZE, which corresponds to the Linux error code EMSGSIZE. That appears to generally mean that gRPC is trying to write a buffer that is too large to the socket, but I'm not sure what exactly could trigger that.
I am a bit confused about how to use socket.io with Meteor. There is a package called socket-io-client. Is that the only package that I should use or socket-io is required for the client side?
Have anyone implemented a connection? I have managed to print out on the terminal a message that indicates that there is a connection on the server but I cannot print any output on the browser console. Instead I get a message about encoding Uncaught TypeError: response.setEncoding is not a function.
Does the connection is on the same port as my meteor server or must be running on different port?
Thanks very much.
I'm using MonetDB on a variety of platform (e.g. OS X and Linux Centos) with a shiny application.
It is difficult to disconnect the db all the times, so currently my approach is to terminate the shiny app without disconnecting the db.
This means that the shiny app before accessing the data tries to stop any "old" process with:
monetdb.server.stop(pid)
From the source of the command I understand that it basically kills the process associated to the pid provided (which means among other things that the user running the app must have access to the kill function).
This works OK some of the times, but sometimes when I try to start MonetDB again, I get
!FATAL: GDKlockHome: Database lock '.gdk_lock' denied
Warning in socketConnection(host = host, port = port, blocking = TRUE, open = "r+b", :
localhost:50000 cannot be opened
Error in socketConnection(host = host, port = port, blocking = TRUE, open = "r+b", :
cannot open the connection
Is there a way to avoid this error (without forcibly disconnecting the database all the time I use it in shiny)?
It can indeed take a couple of seconds for MonetDB to shut down. If a new process is started on the same dbfarm directory in the meantime, you will get the !FATAL: GDKlockHome: Database lock '.gdk_lock' denied error. I'm considering adding a wait parameter to monetdb.server.stop.
So in the meantime, waiting a bit before the server is started again is a good idea. Otherwise, consider using monetdbd to manage your MonetDB servers.
I'm using ASP.NET 2.0 to connect to a Sybase SQL Anywhere 5 server. And I get this error sporadically. It just happens sometimes. The error message is:
ERROR [HY000] [Sybase][ODBC Driver]General error: attempted two active database requests
Exception Details: System.Data.Odbc.OdbcException: ERROR [HY000] [Sybase][ODBC Driver]
General error: attempted two active database requests
Anyone has any experience with this problem?
The error message means that you attempted to run two queries at the same time using the same database connection.
Are you trying to use the same database connection for all requests? The requests are handled by several threads, so each request needs to have it's own database connection.
Sounds like you're reusing the same connection for multiple commands. Check that you properly dispose of the connections after each command/batch of commands and that all new commands get a new connection.