[EnMasse] REST API

[Tom Harris]

Hi Keith

Thanks for your reply.
Yes, I now understand the JMS 2.0  shared subscription semantics.
I guess we will need to upgrade our clients to integrate with both diverts
and shared subscriptions first before upgrading our broker backend to
enmasse
Our client code is dual deployed on kubernetes and bare metal. We are
hoping to POC our kubernetes deployments
Was hoping for limited client impact i.e. just swap out the Connection
Factory :-(

I suppose bolting on a custom configured Artemis broker with our
non-exclusive diverts  to the enmasse router network is not advised :-)

BR
Tom.


On Tue, 12 Mar 2019 at 17:29, Keith Wall <kwall at redhat.com> wrote:

> Hi Tom,
>
> For JMS 2.0 shared subscription delivery semantics, in the standard
> address space, create an instance of address type subscription [1] bound to
> your topic address type instance.  You are free to connect as many
> consumers to the subscription address (mytopic::mysub) as you want.    For
> the brokered space, just use a JMS 2.0 Shared Subscription from the
> directly  client code.
>
> Kind regards
> Keith.
> [1]
> https://enmasse.io/documentation/0.26.3/openshift/#con-standard-subscription-messaging
>
>
>
> On Tue, Mar 12, 2019 at 12:36 PM Tom Harris <tom.harris at ammeon.com> wrote:
>
>> Hi Keith,
>>
>> Our divert use case is essentially a workaround for HornetQ to provide a
>> JMS 2.0 "shared subscription"  i.e. allow multiple consumers to share the
>> work of receiving messages from a topic and ensure they only process the
>> message once between them.
>>
>> Removal of messages is only used in out test utilities to clear the
>> queues.
>>
>> BR
>> Tom.
>>
>>
>>
>>
>>
>>
>> On Thu, 7 Mar 2019 at 18:07, Keith Wall <kwall at redhat.com> wrote:
>>
>>> Hi Tom,
>>>
>>> In general, the EnMasse Address abstraction hides the implementational
>>> details away from you.  In the case of queues in the standard address space
>>> you don't know where your queue is, how many storage units (i.e. Brokers)
>>> the queue is sharded across.  The implementation may move a queue between
>>> storage units during its lifetime for efficient resource utilisation.   It
>>> may not necessarily be hosted on a Broker....   Exposing the underlying
>>> APIs would be an obstacle when offering these higher level behaviours.
>>>
>>> Tell us about your use-case for for diverts?  They are something we
>>> intend to look later this year, but it would good to hear your requirements.
>>> Removal of messages is planned but we don't have a precise dates at the
>>> moment.  Again, hearing the use-case is useful for us.
>>>
>>> Kind regards
>>>
>>> Keith.
>>>
>>>
>>> On Thu, Mar 7, 2019 at 3:51 PM Tom Harris <tom.harris at ammeon.com> wrote:
>>>
>>>> Hi
>>>> The ENMASSE REST API  does not support creating diverts is there a
>>>> roadmap for this API or is this planned ..?
>>>> Also is it possible to run standard artemis REST commands via Jolokia
>>>> i.e. is this interface exposed..?
>>>>
>>>> e.g  curl -X POST -H "Content-Type: application/json" -d '{ "type":
>>>> "EXEC", "mbean":
>>>> "org.apache.activemq.artemis:address=\"myqueue\",broker=\"0.0.0.0\",component=addresses,queue=\"myqueue\",routing-type=\"anycast\",subcomponent=queues",
>>>> "operation": "removeMessages(java.lang.String)", "arguments": [ "" ] }'
>>>> http://localhost:8161/jolokia/exec | jq .
>>>>
>>>> BR
>>>> Tom
>>>>
>>>> This email and any files transmitted with it are confidential and
>>>> intended solely for the use of the individual or entity to whom they are
>>>> addressed. If you have received this email in error please notify the
>>>> system manager. This message contains confidential information and is
>>>> intended only for the individual named. If you are not the named addressee
>>>> you should not disseminate, distribute or copy this e-mail.
>>>>
>>>> _______________________________________________
>>>> enmasse mailing list
>>>> enmasse at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/enmasse
>>>>
>>>
>> This email and any files transmitted with it are confidential and
>> intended solely for the use of the individual or entity to whom they are
>> addressed. If you have received this email in error please notify the
>> system manager. This message contains confidential information and is
>> intended only for the individual named. If you are not the named addressee
>> you should not disseminate, distribute or copy this e-mail.
>>
>>

-- 
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. 
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/enmasse/attachments/20190315/c302c548/attachment.htm>