im trying to run logman commands from the command line. crate counter is working fine, but for other commands like:-logman start datacollector , and logman stop datacollector , im getting a error as:- rpc server unavailable.
Make sure the following services are runnning
1.Windows event log
2.Remote procedure call(RPCSS)
3.DCOM server process launcher
4.RPC end point mapper Automatic
5.Secure socket tunneling protocol(sstp)
6.Remote access auto connection manager
7.Remote connection manager
and set the start up type of the services to AUTOMATIC
Related
An instance of a BizTalk send pipeline has started to run continuously. On 09/12/2021 an attempt was made to send a file via SFTP, which retried several times but ultimately failed due to a network issue. The error from the event logs is:
The adapter failed to transmit message going to send port "Deliver Outgoing - SFTP" with URL "sftp://xxx.xxxxxx.co.nz:22/To_****/%SourceFileName%". It will be retransmitted after the retry interval specified for this Send Port. Details:"WinSCP.SessionRemoteException: Network error: Software caused connection abort.
For some reason BizTalk made another send attempt at 1:49pm on 10/12/2021 which succeeded as confirmed by the administrator of the SFTP site. Despite this, BizTalk continued making intermittent send attempts and the pipeline instance is still running. The same file has been sent 4 times to the SFTP server.
The pipeline instance in theory should have suspended at 9:47pm on 09/12/2021. I have been able to confirm definitively whether anybody resumed it, but it seems unlikely at this stage. In any case, after sending successfully the pipeline instance should have terminated and should not be re-executing intermittently.
Does anybody know what could account for this behaviour? This is occurring on BTS2020 with CU2 applied.
I've sent messages over SFTP where the WinSCP interpretation of the date-modified attribute doesn't work with a specific type of SFTP server.
With the WinSCP GUI a dialogue box appears and you can disregard this error, but this option isn't available with BizTalk's GUI. This error appears when a file with the same filename already exists on the server and is supposed to be overwritten.
My solution was to create a pipeline component that removed %SourceFileName% on the server. The pipeline component (just like WinSCP GUI) can disregard the modified-date.
I am using Gremlin Java driver to connect to a local gremlin server.
Simple code flow
Creating client
Cluster cluster = Cluster.build().addContactPoint(<endp>).port(<port>).enableSsl(false).create()
Client client = cluster.connect();
Submit Script
client.submit("g.V().count()");
If when i submit the first time the Gremlin server is down, on subsequent retries after bringing back gremlin server, connection still fails to create.
Exception First attempt when Gremlin Server is down:
org.apache.tinkerpop.gremlin.driver.exception.NoHostAvailableException: All hosts are considered unavailable due to previous exceptions. Check the error log to find the actual reason
Exception After Gremlin server is brought back up:
tinkerpop.gremlin.driver.exception.NoHostAvailableException: All hosts are considered unavailable due to previous exceptions
One thing to note is i do not create client on retry just do
Submit Script
client.submit("g.V().count()");
It is quite possible that Gremlin server may go down anytime, how to recover in such circumstances. Fundamentally is
NoHostAvailableExceptio
recoverable?
Normally, the Client should attempt to reconnect to a host that is previously marked unavailable. By default, it should be retrying the host at 1 second intervals as governed by this configuration: connectionPool.reconnectInterval. In your case, however I think you've uncovered a bug where the reconnect attempts are not started because the Client was never able to reach the host in the first place. As of 3.4.11, you can only remedy this by recreating the Client as you noted in your comments. I've created an issue to track this problem here: TINKERPOP-2569
I have a setup where I use Flask-MQTT to connect my python Flask API to a Mosquitto broker. Whenever I run the Flask API with the development server all is well. But whenever I spin it up for production (using wsgi+nginx), the connection with Mosquitto is made, but everytime i try to publish something i get the following error:
Socket error on client <unknown>, disconnecting.
My app.ini has the processes configured to 1 (processes = 1)
My mosquitto.config has the allow_anonymous flag set to trye (allow_anonymous true)
I can't really seem to figure out what I'm doing wrong here...
Update:
So what i think is happening is that the Flask-uwsgi application is trying to connect to mosquitto more than once. There is a master process that connects with Mosquitto on initialize. Then there is a second process that is being used whenever input is given on the Flask app. I'm not sure, but I think Mosquitto only wants one connection at the time, therefor erroring on the second. So now i either need to:
A) Configure Mosquitto in a way that it accepts multiple connection from the same device
B) Configure Flask in a way that wil only use one single process (configuring processes = 1 is not enough, it will still spawn two processes)
99% of the time, a "Socket error on client <unknown>" is an authentication error. I don't know Flask, so I don't know where to point you at, but something in your code is either trying to pass a username/password that is not defined to Mosquitto, or its trying a TLS connection with an cert that Mosquitto doesn't like.
Alright, it turns I could've read that the whole multiple processes wouldn't work from the start at the official Flask-MQTT documentation. It sais right there in think letters:
Flask-MQTT is currently not suitable for the use with multiple worker
instances.
So I looked at my uwsgi app.ini file again closely and actually the answer is quite simple. I turned out i had a like in there master = true.. after I removed that it works like a charm.
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.
To connect from windows desktop to unix host, in order of administration on command line level, I like to use MobaXterm in it's free version
The connection is encrypted ssh, identification to Unix host is using user id, passwd.
There is an issue in I can't resolve:
In the "Session Settings" is a field "Execute Command".
This command there is supposed to be executed in the target host when login has been successful finished. The hosts I have to use are may be not the fastest - Or MobaXterm is too fast.
However, the command is issued in a to early stage, the host feels mortally offended, closes connection and throws me out.
It does not matter what the command is - even a sleep is not accepted.
How to tell MobaXterm to act a bit slower?
MobaXterm default behavior for executing a command is to close the session after execution.
To prevent that there is a setting near the "Execute command" field that states: "Do not exit after command ends". Just check that and it will fix the problem.