While trying to create a session to grakn keyspace,after the grakn server is idle for sometime, i am getting session error.
I am using a python 3.6 application which has grakn-client of version 1.6.0 and the grakn server version is 1.6.0. I am getting this error intermittently. Only after the grakn server is idle for some time and on the first try. Trying to connect again after this error, with create the sessionid.
Could not obtain sessionId for keyspace abc
We have most commonly seen this error when using mismatched versions of client and server somehow - either running the wrong server version. Please double check your client and server versions, and follow the docs for importing the right paths. Also, to verify if the server is doing something wrong (ie. the suspicious "only after grakn server is idle for some time") - try to connect to the server using Grakn console to perform some operations.
Related
Due to slow query, nebula graph was down.
I ran I ran enter code here, and then the connection to the nebulagraph database was lost. The error message is java.net.SocketException:Broken pipe(Write failed)`.
I would like to ask if this is normal and if it is possible to optimize the client to automatically recognize and reinitialize the connection pool?
The application is java client :com.vesoft.client-3.3.0 and the connection pool is com.vesoft.nebula.client.graph.SessionPool.
This is normal, the database kernel restarted the application and the current connection will also be invalid. It will be better that we can catch the corresponding exception in the business layer and re-initialize the session pool. In addition session pool and connection pool are two different concepts.
I'm trying to stop Grakn server but it doesn't stop. When I query status, it says both server and storage are running.
I thought it's related with this issue. However this issue is solved long before.
I did some operations like insert, match, delete with Python client. Is it possible one of them didn't close well?
I can't run any query on Python client or console now, it gives this error:
Unable to create connection to Grakn instance at localhost:48555
Cause: io.grpc.StatusRuntimeException
UNAVAILABLE: io exception
It's possible that the server has actually stopped but the terminal process doesn't know about it.
Grakn Core 1.8 runs as a Java process. You can check if there is a server instance by running:
jps
If there is a Grakn instance, it will be named GraknServer, and you can force quit it if necessary using kill.
After that you can restart Grakn using ./grakn server start as normal.
Requirement: Updating BizTalk application to a new version
Problem: The MSI import does not go through if there are running/suspended instances. Termination would result in loss of messages
What did I try:
I had about 100+ messages in messagebox some active, some with suspended resumable status.
I took the back up of BizTalkMsgBoxDb, I then terminated all instances from BTAdmin console and then restored the BizTalkMsgBoxDb.
I was expecting the messages to be back in BizTalkMsgBoxDb but when I queried from BiztalkAdmin console I don't find any of the message back.
Did I miss anything?
if your changes do not contain any changes to ports etc. try and replace the assemblies in GAC and then restart your host instances.
Doing a backup of just one of the BizTalk databases and restoring it is a very dangerous practice and I would strongly advise against it as it can cause some very nasty side effects.
The normal process of a deployment would be to switch of the receive locations and allow any running processes to finish and to resume or terminate any messages/orchestrations as appropriate.
Once there were no longer any suspended and running processes/messages would you unenlist all the Orchestrations and do the deployment.
If there are some long running processes that cannot be completed or terminated inside the deployment window then you would have to look at doing a side-by-side deployment. That involves changing the version number of all the DLLs, deploying this and then switching of the receive locations of the old version and switching on the new one.
When the old version has finished you stop that and un-deploy it.
Linux distribution is Red Hat. I'm monitoring linux counters with the LoadRunner Controller's System Resources Graphs - Unix Resources. Monitoring is working properly and graphs are plotted in real time. But after a few minutes, errors are appearing:
Monitor name :UNIX Resources. Internal rpc error (error code:2).
Machine: 31.2.2.63. Hint: Check that RPC on this machine is up and running.
Check that rstat daemon on this machine is up and running
(use rpcinfo utility for this verification).
Details: RPC: RPC call failed.
RPC-TCP: recv()/recvfrom() failed.
RPC-TCP: Timeout reached. (entry point: Factory::CollectData).
[MsgId: MMSG-47197]
I logged on the Linux server and found rstatd is still running. Clearing the measurements in Controller's Unix Resources and adding them again, monitoring again started to work but after a few minutes, the same error occurred.
What might cause this error ? Is it due to network traffic ?
Consider using SiteScope, which has been the preferred monitoring foundation for the collection of UNIX|Linux status since version 8.0 of LoadRunner. Every Loadrunner license since version 8 has come with aa 500 Point SiteScope license in the box for this purpose. More points are available upon request for test exclusive use of the instance.
I am facing problem with Oracle 11g Express hosted on Linux Centos 6.4. This server is relocated from one place to another, this relocation changes the IP of server.
We have changed the IP in tnsname.ora and listerner.ora files. After these changes when we are trying to connect to database instance from server we are getting error “Connected to idle instance”. If we are trying it to connect from client using SQL developer we are getting error “Status : Failure -Test failed: Listener refused the connection with the following error: ORA-12505, TNS: listener does not currently know of SID given in connect descriptor”.
We have restarted this server and database multiple time (through option Start and Stop database under Oracle menu) multiple time, but still we are getting the same error.
Request you to please help to resolve this issue.
The local connection via sqlplus user/passwd (as opposed to sqlplus user/passwd#TNSALIAS) is not impacted by IP address or by contents of tnsnames.ora. It also does not require a listener at all, the listener could be stopped or not defined at all in listener.ora. In other words, you did something wrong here.
My guess is that you are mislead into thinking that you've started the database, when in fact it is not started. Check if you have a process called ora_MYORACLE_pmon.
Also the file tnsname.ora is irrelevant; Oracle only checks tnsnames.ora.
we resolved this issue, actually we were missing server address in some files it was still referring old address.
initXE.ora missing local listener parameter, then we added this parameter to it and it start working.
May be this is not the generalise solution but it work in our case.
This behavior is expected if the listener was originally configured with an ALTER SYSTEM command like ALTER SYSTEM SET LOCAL_LISTENER=''; and that command specified the SCOPE=MEMORY option or if the SCOPE is left to default and the database was started with a pfile.
To fix it, reissue all ALTER SYSTEM commands from before the restart. Or at least one that identifies the LOCAL_LISTENER. And set SCOPE=BOTH.