You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So much of the communication between the agents and the server, and the way the agents have to store old log messages in the hope that the network connection will come back, seem to be problems in search of a durable queue.
Could the communications protocols be replaced with AMQP? The actual protocols wouldn't have to change much, and the existing command handler structure would be kept. The connection classes on the server would be replaced with AMQP handlers, and the SQLite-based log of work items would be replaced with a client-side durable queue.
This is really dependent on whether there's a good embedded AMQP broker that's JPMS compatible and doesn't require a ton of admin. Apache Artemis exists, but isn't JPMS compatible and might need a lot of babysitting and admin. QPid exists, and hasn't been investigated yet.
For the user shell protocol, synchronous "send and wait for response" behaviour is needed. Durable queues are not needed.
For the agent protocol, asynchronous "fire and forget" behaviour is needed, along with durable queues so that messages are guaranteed to be retried forever until something accepts them.
The server side for agents needs pluggable authentication support; support for authenticating using a public key, and so on.
The server side for users needs pluggable authentication support; support for authenticating against idstore.
The text was updated successfully, but these errors were encountered:
So much of the communication between the agents and the server, and the way the agents have to store old log messages in the hope that the network connection will come back, seem to be problems in search of a durable queue.
Could the communications protocols be replaced with AMQP? The actual protocols wouldn't have to change much, and the existing command handler structure would be kept. The connection classes on the server would be replaced with AMQP handlers, and the SQLite-based log of work items would be replaced with a client-side durable queue.
This is really dependent on whether there's a good embedded AMQP broker that's JPMS compatible and doesn't require a ton of admin. Apache Artemis exists, but isn't JPMS compatible and might need a lot of babysitting and admin. QPid exists, and hasn't been investigated yet.
idstore
.The text was updated successfully, but these errors were encountered: