How to define RulesBased ACLs

[bryand]

I'm using qpid-broker-j-7.0.0 and can't find anything in the documentation
(https://qpid.apache.org/releases/qpid-broker-j-7.0.0/book/Java-Broker-Security-AccessControlProviders.html)
for how to define rule based ACLs.



--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Status monitoring

[Daniel Gavrila]

Hello,

I have a last value queue and I would like to implement  a proton C++ client 
that read the whole queue in browse mode and exit gracefully. How  can I get 
the event that there are no more messages in the queue? Is it possible with 
proton API to get the queue size ?

Best regards,
Daniel


> On 14. Jan 2018, at 16:04, Daniel Gavrila  wrote:
> 
> 
> 
> Thanks Jakub for suggestion! 
> 
>> On 14. Jan 2018, at 15:12, Jakub Scholz  wrote:
>> 
>> How do you plan to implement this: "Before the shutdown the sensor remove
>> its entry from the queue."?
>> 
>> If you plan to have large amount of sensors (= a lot of messages in the
>> StatusOverview queue) which would shutdown often, finding and accepting the
>> particular message might not be the optimal way to do this. So maybe you
>> can instead send a message which would contain in the properties or body
>> the information that the sensor is shutting down. It would overwrite the
>> previous status and later expire and be removed automatically.
>> 
>> Regards
>> Jakub
>> 
>> On Sun, Jan 14, 2018 at 2:46 PM, Daniel Gavrila 
>> wrote:
>> 
>>> 
>>> These are good news!
>>> I think I'm able now to translate the use case scenario in "AMQP  language"
>>> 
>>> Each sensor publish a durable message with TTL=N seconds to the LVQ
>>> durable queue StatusOverview  every N seconds.
>>> Each GUI  client read the queue OverviewStatus in browse mode.
>>> Before the shutdown the sensor remove its entry from the queue.
>>> If a abnormal exit occurs the queue will remove the entry after maxim N
>>> seconds
>>> 
>>> I have one more general question. Which relation is between qpid-config
>>> and the qpid::messaging API ? Everything that can be done with qpid-config
>>> can be done also with the API ?
>>> 
>>> Best regards,
>>> Daniel
>>> 
>>> 
 On 13.01.2018, at 17:23, Jakub Scholz  wrote:
 
 The LVQ queue is able to persist these messages to disk like any other
 queue. So they can survive restart.
 
 Jakub
 
 On Sat, Jan 13, 2018 at 4:55 PM, Daniel Gavrila 
 wrote:
 
> Hello Andreas,
> 
> Thanks for the suggestion.From what I read from documentation, indeed a
> last value queue should cover a signifiant part of use case
> scenario.Remains the question if the values from a LVQ could be make
> persistent, so that will be recovered after a broker restart?
> 
> Best regards,
> Daniel
> 
> 
>> On 13.01.2018, at 12:55, Andreas Welchlin  wrote:
>> 
>> Hello Daniel,
>> 
>> this should work using a last value queue.
>> 
>> Kind Regards,
>> Andreas
>> 
>> Am 13. Januar 2018 12:19:57 MEZ schrieb Daniel Gavrila <
> d.gavr...@icloud.com>:
>>> 
>>> 
>>> Hello,
>>> 
>>> My environment is:
>>>   C++ Proton v. 0.19
>>>   C++ Broker v.1.37 configured with AMQP 1.0
>>> 
>>> I have to implement the following use case scenario. The network
> contains N publishers(sensors) . When one sensor starts it publish to
>>> the
> queue OverviewStatus one message that contains some data: sensor
> name,type,internal status etc. One GUI program has to display the
> information from the queue OverviewStatus. Everytime the sensor changes
>>> its
> internal status he needs to update the status in the queue.Before the
> shutdown , the sensor has to remove its entry from the queue.
>>> If the sensor exits anormaly the event should be catched and the
>>> sensor
> status modified accordingly. By restarting the broker, all the sensors
> status information should be recovered.
>>> 
>>> Is it possibly to implement such use case in the above mentioned
> environment? Any suggestions are welcomed !
>>> 
>>> Many thanks,
>>> Daniel
> 
>>> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
> 

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Java Broker performance

[Keith W]

Hi Tomas,

The work for QPID-8032 is done on master.   If you could repeat your
test-case with Broker-J compiled for master and let us know how
performance changes (improves, hopefully a lot).  Once I have heard
back from you I'll look to have this included in a 7.0.1 very soon.

Kind regards, Keith Wall.

On 26 November 2017 at 14:54, Keith W  wrote:
> Hi Tomas
>
> Thanks for the attachments.
>
> With your Broadcaster code, which sends persistent messages
> asynchronously, I do see inferior performance from Broker J than the
> CPP Broker.  I am using proton master (fa80534)
>
> Currently for this use-case, Broker-J commits synchronously after each
> delivery (see StandardReceivingLinkEndpoint#receiveDelivery.  The
> pertinent part is its use of an AutoCommitTransaction and the fact
> that AutoCommitTransaction#enqueue uses a synchronous #commitTran) and
> this will explain some (if not all) of the performance difference.  As
> Rob mentioned on the 10th November in this thread, the older protocols
> already have an optimisation for this use-case (involving
> AsyncAutoCommitTransaction) which should improve performance on the
> AMQP 1.0 path.   This was raised as QPID-8032. I try and include this
> in a 7.0.1 soon.
>
> This doesn't explain your observation about performance when using
> Qpid JMS Client which is doing a synchronous send of persistent
> messages, but as I commented above, I cannot reproduce the problem: I
> see very similar performance for Broker-J and CPP on my hardware.
>
> cheers Keith.
>
> On 24 November 2017 at 13:06, Tomas Soltys  wrote:
>> Hi Keith,
>>
>> Please find attached  cpp_vs_java.gz
>>   . This
>> archive contains:
>> * *java* - setup of Java broker (v7.0.0)
>> * *cpp* - setup of C++ broker (v1.36.0)
>> * *proton-client* - C++client based on Qpid proton (v0.18.1)
>> * *java_trace.log* - trace log from client sending 20 messages (10240 Bytes
>> each) to Java broker
>> * *java_trace.log* - trace log from client sending 20 messages (10240 Bytes
>> each) to C++ broker
>>
>> One thing I've noticed in logs is that C++ broker is sending dispositions in
>> chunks of 5 whereas Java broker does this for each message separately.
>>
>> Best regards,
>> Tomas
>>
>>
>>
>> --
>> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: users-h...@qpid.apache.org
>>

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

[ANNOUNCE] Apache Qpid Proton-J 0.25.0 released

[Robbie Gemmell]

The Apache Qpid (http://qpid.apache.org) community is pleased to announce
the immediate availability of Apache Qpid Proton-J 0.25.0.

Apache Qpid Proton-J is a messaging library for the Advanced Message Queuing
Protocol 1.0 (AMQP 1.0, ISO/IEC 19464, http://www.amqp.org). It can be used
in a wide range of messaging applications including brokers, clients,
routers, bridges, proxies, and more.

The release is available now from our website:
http://qpid.apache.org/download.html

Binaries are also available via Maven Central:
http://qpid.apache.org/maven.html

Release notes can be found at:
http://qpid.apache.org/releases/qpid-proton-j-0.25.0/release-notes.html

Thanks to all involved,
Robbie

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org