I would need to fully initialize my mosquitto 1.5.7 broker , to clean all messages stored in the broker memory, all messages counter....
How can I do it ?
The #SYS always get all stored information when I restart with :
systemctl restart mosquitto
data in #SYS
If I can initialize the broker,does clients will connect again automatically ? (using their "reconnect process ...")
Thank for your help,
It really isn't clear what you are actually asking here, but to clear all the data from a Mosquitto broker you need to shut it down, then delete the persistence file (the path to this file will be in the mosquitto config file normally found in /etc/mosquitto/mosquitto.conf)
Once you have deleted the persistence file restart the broker.
And yes, most clients will reconnect when the broker comes back up, but all their session data will have been lost so they will need to resubscribe to any topics they are interested in.
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 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 have cloned a Spark project from git which I surely know works and operates correctly. When I run the program, the Jetty server ignites and looks like listening with no problem. Here is the console for that:
[Thread-0] INFO org.eclipse.jetty.util.log - Logging initialized #402ms
[Thread-0] INFO spark.webserver.JettySparkServer - == Spark has ignited ...
[Thread-0] INFO spark.webserver.JettySparkServer - >> Listening on 0.0.0.0:4567
[Thread-0] INFO org.eclipse.jetty.server.Server - jetty-9.3.2.v20150730
[Thread-0] INFO org.eclipse.jetty.server.ServerConnector - Started ServerConnector#36a9b54a{HTTP/1.1,[http/1.1]}{0.0.0.0:4567}
[Thread-0] INFO org.eclipse.jetty.server.Server - Started #600ms
But when I send a request from any browser on my computer, it returns always empty response. I have configuration for the database and all and tried the same configuration with the same data on another computer and it works right away. I have look for the TCP connection status with TCPview and I saw that connection directly goes into time_wait state. Since it does not occur on the other computer I have tested, I'm guessing that the problem does not come from the program or database, but something causes this especially on my computer. Any opinion is appreciated. Thanks.
Make sure you're accessing your webservice like this http://localhost:4567/yourRouteName, note that Spark runs on a not so common port (I wold say), that can be locked by firewall policies or other security software, but you can change the port number like doing it this port(8080); before setting any route.
If nothing works, we would need more information, could you please share the source code of any route you're unable to access ?
We have an upcoming deploy for a system that processes a lot of messages through BizTalk. Since those messages are cumulative updates they need to be queued up during the deployment outage then processed in order when the deploy is finished. Since there may be a large number of them it’s difficult to do this manually.
One possible solution is to leave the send port stopped and let the messages suspend. We can then resume them in order when the deployment is completed.
Is it possible to run a SQL script (or a tool) against the BizTalk messagebox database that will resume suspended messages, for a specific port, in order of receipt?
If you have an ordered requirement (you either do or don't), then the Send Port should be marked for Ordered Delivery.
If so, then when you Start a Stopped Send Port, the messages will be processed in the same order they were submitted.
If you stop the port (but leave it subscribed) and start it again afterwards it should resume the message itself, or if not it is simple enough to go into the Administration Console and batch resume them.
However if the response messages of the send port are subscribed too by running Orchestrations you will not be able to un-deploy the Orchestrations until they have all completed, so stopping the send port would not work in this scenario.
Sometimes one option is if the initiating port is a one way receive, is to stop the receive location and let everything complete. You can then stop the application and redeploy and restart it and the send port will pick up all the waiting message to process.
If the above is not possible you may want to look at doing a side by side deployment where you increment the version numbers of all the assemblies in the solution so you can have both versions deployed at the same time and you can then allow the old version to finish running but have the new version processing any new messages.
The better option is to send messages to msmq, usually there is no extra coding required for this. You can just route messages to msmq using MSMQ adapter and then after deployment receive them in order as MSMQ adapter allows to receive in order. Just make sure you do a small test in yr QA environment before doing it in production.
i have the final builder actions below
sftp connect
try
sftp create directory
finally
sftp disconnect
end
thing is the action always says "connection lost" at sftp create directory. i even insert a reconnect before that line but still the same.
You need to contact FinalBuilder support and they will in turn contact us as developers of SFTP component. The problem is in the server, which gets confused by certain request and forcefully closes connection. We can diagnose the problem but fixing it would require cooperation with FinalBuilder team so we can't support you directly.