We have an mqtt server (VerneMq on Linux VM on Azure) which is configured like below
max_inflight_messages=500
upgrade_outgoing_qos=on
max_offline_messages=1000000
max_online_messages=1000000
persistent_client_expiration=1w
in addition to it's default configuration.
In order to test the persistent message mechanism, we created the following scenario:
We fed the server with some test messages and wait couple of minutes before subscribing with the client (with cleanSession = false), we were able to receive all the messages.
But if we do the same thing and wait 24 hours, we can not receive all stored messages, even if we can see awaiting messages for that client with
vmq-admin trace client client-id=<client_id>
Broker and client both use qos=2.
Is there any other configuration on client or server we have to change?
Related
I have multiple devices sending messages to a mosquito broker. I would like to manage a kind of device revocation so that when a device is revoked, I want the mosquito broker to automatically close the connection for this specific device.
Is there any command or way to ask the broker to explicitly close a connection to a specific client?
Thanks in advance,
hak
I do not think you can kick an already connected client.
But what you can do if using the Authentication Plugin (either a 3rd party or the included dynamic security plugin) to change the ACL that the user can publish/subscribe to which should effectively stop the client sending or receiving any messages and when it next tries to connect it will not be allowed.
Does anyone know why do we get association errors?
I have a server and client system where actors from the client-side send messages to the server actor through Akka remoting and both server and client are on the same local machine but using different ports.
Error on the server client side:
[ERROR][12/1/2020 3:59:28 AM][Thread 0021][akka.tcp://RemoteSystem#localhost:8876/system/transports/akkaprotocolmanager.tcp.0/akkaProtocol-tcp%3A%2F%2FRemoteSystem%40localhost%3A8080-1] No response from remote for outbound association. Associate timed out after [15000 ms].
[WARNING][12/1/2020 3:59:28 AM][Thread 0019][remoting (akka://RemoteSystem)] Tried to associate with unreachable remote address [akka.tcp://RemoteSystem#localhost:8080]. Address is now gated for 5000 ms, all messages to this address will be delivered to dead letters. Reason: [Association failed with akka.tcp://RemoteSystem#localhost:8080] Caused by: [System.TimeoutException: No response from remote for outbound association. Associate timed out after [15000 ms].
at Akka.Remote.Transport.AkkaProtocolTransport.Associate(Address remoteAddress, Nullable`1 refuseUid)
at Akka.Remote.EndpointWriter.AssociateAsync()]
Error on server side:
[ERROR][12/1/2020 3:53:29 AM][Thread 0020][akka.tcp://RemoteSystem#localhost:8080/system/transports/akkaprotocolmanager.tcp.0/akkaProtocol-tcp%3A%2F%2FRemoteSystem%40%5B%3A%3Affff%3A127.0.0.1%5D%3A57235-1] No response from remote for
inbound association. Handshake timed out after [15000] ms
My understanding is that handshake is not achieved from client to server.
When I work with 20 client actors sending messages to the server and waiting for the reply it works but with more than 25 it does not work.
Any help will be appreciated.
I have registered 3 LDAP Servers in Solace for client authentication using LDAP protocol. I understand that Solace creates a connection pool to handle requests to one of the LDAP Servers. But, I wonder whether the other two LDAP Servers are being used for load balancing purposes (meaning Solace will send LDAP requests to them in the event that the first one is overloaded) or only for backup purposes in case the first one is not accessible.
The additional LDAP servers are configurable for redundancy purposes. The Solace PubSub+ message broker will attempt to connect to the LDAP server in the order of preference based off of the index number. Once connected, the message broker continues to use this connection to authenticate clients until the connection goes down. (e.g. timeout from the far end or a shutdown of the LDAP profile).
I'm using Glassfish 3.1.2.2 that supports JEE 6. We have a JAX-WS web service and a client. The client has timeouts set so that is disconnect after 30 seconds. Is there a way to detect when a client gets a timeout on server? Is there a way to detect when client disconnects from server?
As far as I know, you could not detect that the client disconnected from server without trying to perform reading or writing. To determine that the client is disconnected the server must send a packet. If the connection is closed will be thrown IOException.
MQTT Broker can disconnect the existing client if the following condition is came up.
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718090
If the ClientId represents a Client already connected to the Server then the Server MUST disconnect the existing Client
[MQTT-3.1.4-2].
At this time, can broker send any specific message excluding "DISCONNECT" to client before server disconnect the existing client ?
Most brokers are going to follow the spec, if you want one to do something different then you will have to either write your own or modify one of the open source versions.