[
https://issues.apache.org/jira/browse/ARTEMIS-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Andre Pearce updated ARTEMIS-1213:
------------------------------------------
Description:
Client side persistence allows the client decouple the sending of messages with
the availability of the broker for periods of time.
It does not reduce the HA of the messaging product as for message failure/loss
it would require both client and broker side failures.
It has previously been requested here:
https://developer.jboss.org/thread/48115
Other brokers have this feature
Oracle: Store-and-Forward Client
https://docs.oracle.com/middleware/1213/wls/SACLT/saf_client.htm#SACLT150
WebMethods: Client-side-queue
https://www.scribd.com/doc/80485664/Web-Methods-Integration-Server-JMS-Client-Developer-s-Guide-7-1
Fiorano: Client-side-persistance
http://www.fiorano.com/products/Enterprise-Messaging/JMS/Java-Message-Service/FioranoMQ-New-Release.php
It could possibly work in two ways:
Circuit-Breaker where client direct sends if circuit is closed, but on failure
circuit is opened and messages are routed to client store, only after
connection re-estabilished and client store is empty the circuit re-closes.
Benefits of this is the client side store is only used in failure scenario as
such latency is not affected.
All messages flow through the client store, send is return to client on success
of sending to store, and subsequent thread is used to drain the store to the
broker. Benefits of this are that the broker send could batch up message sends
or even better could possible async handle the send, improving throughput.
Ideally this could be an add-on, as in a wrapper factory around the JMS api's
which then could mean its re-use in ActiveMQ5 and also QPID JMS client.
was:
Client side persistence allows the client decouple the sending of messages with
the availability of the broker for periods of time.
It does not reduce the HA of the messaging product as for message failure/loss
it would require both client and broker side failures.
It has previously been requested here:
https://developer.jboss.org/thread/48115
Other brokers have this feature
Oracle: Store-and-Forward Client
https://docs.oracle.com/middleware/1213/wls/SACLT/saf_client.htm#SACLT150
WebMethods: Client-side-queue
https://www.scribd.com/doc/80485664/Web-Methods-Integration-Server-JMS-Client-Developer-s-Guide-7-1
Fiorano: Client-side-persistance
http://www.fiorano.com/products/Enterprise-Messaging/JMS/Java-Message-Service/FioranoMQ-New-Release.php
It could possibly work in two ways:
Circuit-Breaker where client direct sends if circuit is closed, but on failure
circuit is opened and messages are routed to client store, only after
connection re-estabilished and client store is empty the circuit re-closes.
Benefits of this is the client side store is only used in failure scenario as
such latency is not affected.
All messages flow through the client store, send is return to client on success
of sending to store, and subsequent thread is used to drain the store to the
broker. Benefits of this are that the broker send could batch up message sends
of async handle the send, improving throughput.
Ideally this could be an add-on, as in a wrapper factory around the JMS api's
which then could mean its re-use in ActiveMQ5 and also QPID JMS client.
> Support Client Side Persistence.
> --------------------------------
>
> Key: ARTEMIS-1213
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1213
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Reporter: Michael Andre Pearce
> Assignee: Michael Andre Pearce
>
> Client side persistence allows the client decouple the sending of messages
> with the availability of the broker for periods of time.
> It does not reduce the HA of the messaging product as for message
> failure/loss it would require both client and broker side failures.
> It has previously been requested here:
> https://developer.jboss.org/thread/48115
> Other brokers have this feature
> Oracle: Store-and-Forward Client
> https://docs.oracle.com/middleware/1213/wls/SACLT/saf_client.htm#SACLT150
> WebMethods: Client-side-queue
> https://www.scribd.com/doc/80485664/Web-Methods-Integration-Server-JMS-Client-Developer-s-Guide-7-1
> Fiorano: Client-side-persistance
> http://www.fiorano.com/products/Enterprise-Messaging/JMS/Java-Message-Service/FioranoMQ-New-Release.php
> It could possibly work in two ways:
> Circuit-Breaker where client direct sends if circuit is closed, but on
> failure circuit is opened and messages are routed to client store, only after
> connection re-estabilished and client store is empty the circuit re-closes.
> Benefits of this is the client side store is only used in failure scenario as
> such latency is not affected.
> All messages flow through the client store, send is return to client on
> success of sending to store, and subsequent thread is used to drain the store
> to the broker. Benefits of this are that the broker send could batch up
> message sends or even better could possible async handle the send, improving
> throughput.
> Ideally this could be an add-on, as in a wrapper factory around the JMS api's
> which then could mean its re-use in ActiveMQ5 and also QPID JMS client.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
