Re: JMSMessageID differences in JMS 0.30.0 and JMS AMQP 0-x 6.3.0 clients

[Oleksandr Rudyy]

Hi Bryan,

Using 0-91 AMQP client should work as expected. I am not aware about
any issue with such approach.

The issue you had run with 0-10 amqp client is caused by 0-10 protocol
restriction which limits message id types to UUID only. The conversion
layer of Broker-J converts the String message id values generated on
amqp 1-0 client into UUID type. Thus, the value of JMSMessageID is
changed in result of conversion. The filtering functionality cannot
find the message as the  converted message id in selector expression
does not match the real message id.

The alternative solution for the issue would be to use custom
application specific header for the message id.

The other alternative would be to configure amqp 1.0 JMS client to
generate JMSMessageIDs as UUID values using UUID policy
(jms.messageIDPolicy.messageIDType=UUID) but it does not work as
expected. The JMS Clients adds prefix "ID:" or "ID:AMQP_UUID:" to the
string representation of message id and Broker fails to find the
message with given prefixes. The Broker (and it seems new JMS client)
would need to be changed to have this working properly. I raised
defects [1] and [2] to address the issues.

Kind Regards,
Alex

[1] https://issues.apache.org/jira/browse/QPID-8139
[2] https://issues.apache.org/jira/browse/QPIDJMS-371


On 23 March 2018 at 16:32, Bryan Dixon  wrote:
> We are getting close to going live in production with Broker-J and since I
> need to stabilize everything what I'm going to do for the time being is set
> the JVM Property qpid.amqp.version to 0-91.  I tested all our clients with
> that and was able to get the desired results.  If you think there are any
> issues with putting this in a production environment please let me know.
>
> Thanks
> Bryan
>
>
>
> --
> 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

Re: JMSMessageID differences in JMS 0.30.0 and JMS AMQP 0-x 6.3.0 clients

[Bryan Dixon]

We are getting close to going live in production with Broker-J and since I
need to stabilize everything what I'm going to do for the time being is set
the JVM Property qpid.amqp.version to 0-91.  I tested all our clients with
that and was able to get the desired results.  If you think there are any
issues with putting this in a production environment please let me know.

Thanks
Bryan



--
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: qpid-proton cpp - Wrong auth with reconnect options lead to error : Too many reconnect attempts

[Justin Ross]

Hi, Baptiste.  There's something coming soon in Proton C 0.22.0 that may
help with that.

https://issues.apache.org/jira/browse/PROTON-1589

This is on master now, and the 0.22.0 release process will start this month.

On Fri, Mar 23, 2018 at 7:57 AM, Baptiste Robert  wrote:

> Hello,
>
> I've an annoying issue when I define reconnect_options and call connect
> method on the proton::container with this option. If the authentication is
> wrong (bad password/login), I got the following error : [proton:io] - [Too
> many reconnect attempts (40)]
> In my use case, I really want to know if it fails because the auth was bad
> or if the server is just unreachable.
> If I remove the reconnect_options then I get this information, but why I
> cannot get both ?
>
> Thank you,
>
> --
> Baptiste Robert
>

Re: Proton-c transport failure on reconnect/failover for brokers that begin the session delivery id sequence not at 0

[Alan Conway]

On Fri, Mar 23, 2018 at 9:10 AM, Robbie Gemmell 
wrote:

> The C code isn't in my wheelhouse, but it sounds like a bug. Its
> probably just been expected it would start at 0 as it does elsewhere,
> but I dont see anything in the spec requiring that and it isnt
> negotiated.
>
> You can raise JIRAs at https://issues.apache.org/jira/browse/PROTON.
> If you wanted you could even try a patch, or raise a PR. Include the
> JIRA key in the PR title and commit messages and theyll get lined up
> for some bot handling later (comments etc), e.g see an existing PR
> such as https://github.com/apache/qpid-proton/pull/134.
>
> Robbie
>
> On 22 March 2018 at 21:23, Christopher Morgan
>  wrote:
> > Hi all,
> >
> > I'm trying to write a failover, with a host list, example application
> for a solace amqp broker using the qpid-proton-python using the example
> code from http://qpid.2158936.n2.nabble.com/About-failover-td7649247.html
> as a base. When I ran the application I got a lot transport errors from
> pn_do_transfer in transport.c:
> > 
> > if (id_present && id != state->id) {
> >   return pn_do_error(transport, "amqp:session:invalid-field",
> >  "sequencing error, expected delivery-id %u, got
> %u",
> >  state->id, id);
> > }
> > 
> >
> > The errors occurred on the new connection on the first transfer frame
> with the delivery id 1. The solace amqp broker begins its delivery id
> sequence at 1. But, on the reconnected session the
> ssn->state.incoming->next value seems to set to 0. I noticed there is code
> to set the ssn->state.incoming->next value to the first incoming transfer
> base on the flag ssn->state.incoming_init. When I added some extra logs
> around that value I noticed the ssn->state.incoming_init flag is not reset
> when reconnecting and is set to 0 as a part of the transport unbind
> process. I also modified the pn_session_unbind function in engine.c to set
> the ssn->state.incoming_init to false and it seemed to fix my issue.
> >
> > I'm somewhat new to using the proton-c source and was curious if this is
> a bug? If not, why wouldn't the incoming_init be reset? If so, is there a
> better place to reset the flag? Are there more places?
> >
>

Are you re-using the same pn_transport_t for the new connection? I don't
think pn_transport_t was designed with the expectation of being re-used, so
I wouldn't be surprised if it doesn't work.
I'd throw away the old transport and create a new one to re-connect. I
believe that's what the C++ reconnect code does - you may find that useful
for inspiration, it's based on the C library.

https://github.com/alanconway/qpid-proton/blob/ruby-schedule/proton-c/bindings/cpp/src/proactor_container_impl.cpp#L1

qpid-proton cpp - Wrong auth with reconnect options lead to error : Too many reconnect attempts

[Baptiste Robert]

Hello,

I've an annoying issue when I define reconnect_options and call connect
method on the proton::container with this option. If the authentication is
wrong (bad password/login), I got the following error : [proton:io] - [Too
many reconnect attempts (40)]
In my use case, I really want to know if it fails because the auth was bad
or if the server is just unreachable.
If I remove the reconnect_options then I get this information, but why I
cannot get both ?

Thank you,

-- 
Baptiste Robert

Re: [VOTE] Release Apache Qpid C++ 1.38.0

[Timothy Bish]

+1

* Validated signatures and checksums
* Built from source and ran the tests

On 03/23/2018 08:45 AM, Robbie Gemmell wrote:

On 22 March 2018 at 12:33, Justin Ross  wrote:

Hi, all.  Please test this release candidate and indicate your vote on this
thread.

Source archive and signatures:
https://dist.apache.org/repos/dist/dev/qpid/cpp/1.38.0-rc1/

Issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310520=12340228

Tag:
1.38.0-rc1

+1

Checked thigns out as follows:
- Verified signature and checksum files.
- Checked for LICENCE+NOTICE files.
- Ran the source build against proton-0.21.0, ran the tests, all passed.
- Ran the qpid-jms 0.31.0 (RC1) HelloWorld example against the built broker.

Robbie

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




--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/


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

Re: [VOTE] Release Apache Qpid C++ 1.38.0

[Chuck Rolke]

+1

* Checked checksums
* Built with master proton master at 3c80d6f4
* Self tests FAILED: 
  21/26 Test #21: paged_queue_tests ***Timeout 1500.02 sec
* Rebuilt with valgrind disabled
* Self tests pass 100%

My local machine is generally high performance and I'm surprised to have
the valgrind time out. 

- Original Message -
> From: "Justin Ross" 
> To: users@qpid.apache.org
> Sent: Thursday, March 22, 2018 8:33:15 AM
> Subject: [VOTE] Release Apache Qpid C++ 1.38.0
> 
> Hi, all.  Please test this release candidate and indicate your vote on this
> thread.
> 
> Source archive and signatures:
> https://dist.apache.org/repos/dist/dev/qpid/cpp/1.38.0-rc1/
> 
> Issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310520=12340228
> 
> Tag:
> 1.38.0-rc1
> 

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

Re: Proton-c transport failure on reconnect/failover for brokers that begin the session delivery id sequence not at 0

[Robbie Gemmell]

The C code isn't in my wheelhouse, but it sounds like a bug. Its
probably just been expected it would start at 0 as it does elsewhere,
but I dont see anything in the spec requiring that and it isnt
negotiated.

You can raise JIRAs at https://issues.apache.org/jira/browse/PROTON.
If you wanted you could even try a patch, or raise a PR. Include the
JIRA key in the PR title and commit messages and theyll get lined up
for some bot handling later (comments etc), e.g see an existing PR
such as https://github.com/apache/qpid-proton/pull/134.

Robbie

On 22 March 2018 at 21:23, Christopher Morgan
 wrote:
> Hi all,
>
> I'm trying to write a failover, with a host list, example application for a 
> solace amqp broker using the qpid-proton-python using the example code from 
> http://qpid.2158936.n2.nabble.com/About-failover-td7649247.html as a base. 
> When I ran the application I got a lot transport errors from pn_do_transfer 
> in transport.c:
> 
> if (id_present && id != state->id) {
>   return pn_do_error(transport, "amqp:session:invalid-field",
>  "sequencing error, expected delivery-id %u, got %u",
>  state->id, id);
> }
> 
>
> The errors occurred on the new connection on the first transfer frame with 
> the delivery id 1. The solace amqp broker begins its delivery id sequence at 
> 1. But, on the reconnected session the ssn->state.incoming->next value seems 
> to set to 0. I noticed there is code to set the ssn->state.incoming->next 
> value to the first incoming transfer base on the flag 
> ssn->state.incoming_init. When I added some extra logs around that value I 
> noticed the ssn->state.incoming_init flag is not reset when reconnecting and 
> is set to 0 as a part of the transport unbind process. I also modified the 
> pn_session_unbind function in engine.c to set the ssn->state.incoming_init to 
> false and it seemed to fix my issue.
>
> I'm somewhat new to using the proton-c source and was curious if this is a 
> bug? If not, why wouldn't the incoming_init be reset? If so, is there a 
> better place to reset the flag? Are there more places?
>
> Thanks
>
> Chris Morgan

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

Re: [VOTE] Release Apache Qpid JMS 0.31.0

[Oleksandr Rudyy]

+1

* Validated signatures and checksums
* Built from source and ran the tests
* Ran Broker-J master system tests against staged artefacts using
profiles java-mms.1-0 and java-bdb.1-0
* Built sample application publishing messages into Broker-J
7.0.3-SNAPSHOT using staged artefacts


On 22 March 2018 at 18:44, Robbie Gemmell  wrote:
> Hi folks,
>
> I have put together a spin for a 0.31.0 Qpid JMS client release,
> please give it a test out and vote accordingly.
>
> The source and binary archives can be grabbed from:
> https://dist.apache.org/repos/dist/dev/qpid/jms/0.31.0-rc1/
>
> The maven artifacts are also staged for now at:
> https://repository.apache.org/content/repositories/orgapacheqpid-1133
>
> The JIRAs assigned are:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314524=12342832
>
> Regards,
> Robbie
>
> P.S. If you want to test it out using maven (e.g with the examples
> src, or your own things), you can temporarily add this to your poms to
> access the staging repo:
>
>   
> 
>   staging
>   
> https://repository.apache.org/content/repositories/orgapacheqpid-1133
> 
>   
>
> The dependency for the client itself would then be:
>
>   
> org.apache.qpid
> qpid-jms-client
> 0.31.0
>   
>
> -
> 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: [VOTE] Release Apache Qpid C++ 1.38.0

[Robbie Gemmell]

On 22 March 2018 at 12:33, Justin Ross  wrote:
> Hi, all.  Please test this release candidate and indicate your vote on this
> thread.
>
> Source archive and signatures:
> https://dist.apache.org/repos/dist/dev/qpid/cpp/1.38.0-rc1/
>
> Issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310520=12340228
>
> Tag:
> 1.38.0-rc1

+1

Checked thigns out as follows:
- Verified signature and checksum files.
- Checked for LICENCE+NOTICE files.
- Ran the source build against proton-0.21.0, ran the tests, all passed.
- Ran the qpid-jms 0.31.0 (RC1) HelloWorld example against the built broker.

Robbie

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

Re: [VOTE] Release Apache Qpid C++ 1.38.0

[Gordon Sim]

On 22/03/18 12:33, Justin Ross wrote:

Hi, all.  Please test this release candidate and indicate your vote on this
thread.


+1 (verified signature and hash, built from source including running of 
all tests, ran some adhoc tests with qpid-receive and qpid-send, ran 
python examples, rhea examples and jms helloworold example against broker)



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

Re: [VOTE] Release Apache Qpid JMS 0.31.0

[Gordon Sim]

On 22/03/18 18:44, Robbie Gemmell wrote:

Hi folks,

I have put together a spin for a 0.31.0 Qpid JMS client release,
please give it a test out and vote accordingly.


+1 (verified signature and hash, built from source including running of 
all tests, ran example against router from master, java broker 7.0.2 and 
c++ broker 1.38 rc1)


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

Re: [VOTE] Release Apache Qpid JMS 0.31.0

[Robbie Gemmell]

On 22 March 2018 at 18:44, Robbie Gemmell  wrote:
> Hi folks,
>
> I have put together a spin for a 0.31.0 Qpid JMS client release,
> please give it a test out and vote accordingly.
>
> The source and binary archives can be grabbed from:
> https://dist.apache.org/repos/dist/dev/qpid/jms/0.31.0-rc1/
>
> The maven artifacts are also staged for now at:
> https://repository.apache.org/content/repositories/orgapacheqpid-1133
>
> The JIRAs assigned are:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314524=12342832
>
> Regards,
> Robbie
>
> P.S. If you want to test it out using maven (e.g with the examples
> src, or your own things), you can temporarily add this to your poms to
> access the staging repo:
>
>   
> 
>   staging
>   
> https://repository.apache.org/content/repositories/orgapacheqpid-1133
> 
>   
>
> The dependency for the client itself would then be:
>
>   
> org.apache.qpid
> qpid-jms-client
> 0.31.0
>   

+1

I checked things over as follows:
- Verified the signature and checksum files.
- Checked the LICENCE and NOTICE files in the archives.
- Ran mvn apache-rat:check to verify licence headers in the source archive.
- Ran the source build and tests, all good.
- Built Qpid Broker-J master against the staging repo, ran the tests using
the MMS profile, also ran the joram tests, all good.
- Built ActiveMQ 5 master and  ran its AMQP tests using the staging
repo, all good.
- Built ActiveMQ Artemis master and ran its AMQP tests using the staging
repo, all good.
- Ran HelloWorld against qpid-broker-j 7.0.2 and qpid-cpp 1.38.0-rc1 brokers.

Robbie

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

Re: Broker-J Queue Message persistent override

[Robbie Gemmell]

On 22 March 2018 at 16:57, Rob Godfrey  wrote:
> On 22 March 2018 at 12:35, Bryan Dixon  wrote:
>
>> Rob, I wouldn't know if messages are being stored or not.  I'm assuming
>> they
>> are not since a broker restart causes the messages to be 'lost' but that's
>> just my assumption.
>>
>
> OK - great, just checking
>
>
>>
>> At the end of day Keith is correct - the behavior is what I was wanting -
>> the messages don't appear to be persistent (to me persistent means stored).
>> It was just very confusing that the web admin UI was displaying Persistent:
>> true for messages and the JMS JMSDeliveryMode header also reported the
>> message as Persistent yet I defined on the web admin UI Persist Messages?:
>> NEVER.   That's why I was concerned there was an issue.
>>
>> I'm also coming at this from a JMS perspective and not an AMQP one so that
>> could be causing my confusion - terminology differences.
>>
>>
> I think this is really just a broker presentation issue rather than a
> JMS/AMQP thing.

Sounds like it. Effectively the broker (and sending/receiving client)
is simply reporting whats true for the message as sent in JMS and AMQP
terms, it actually was a persistent/durable message that has been
sent, however its also true that queue is explicitly configured to
ignore that and not actually store it to disk.

I'm not sure theres really a great alternative to doing it that way.
I'd probably be surprised personally if it started saying
non-persistent just because the queue was configured in that manner.

>  Both JMS and AMQP basically say that properties like
> persistence shouldn't be changed by the network.  They are effectively
> statements of requirements made by the sender of the message "I want this
> message to be stored persistently".  In the case of setting the queue to
> never persist a message we are basically saying that we are deliberately
> ignoring the sender's wishes.  Note (for instance) if you set up a DLQ for
> a queue with persist NEVER, and that DLQ did not have the persistence
> override, then if the message moved to the DLQ then it would be persisted
> (because the DLQ would respect the wishes of the sender as expressed in the
> message header information).
>
> -- Rob
>
> Bryan
>>
>>
>>
>> --
>> 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

Re: Qpid Proton J - 0.26.0, Need help to Create SASL connection for connecting Azure Service Bus

[Robbie Gemmell]

The reactor is very low level, you likely shoudnt use it here. I know
you have been advised already on IRC that something like the JMS
client or vertx-proton might be a better fit for you. However, given
your other thread about JMS and batch messages, its worth nnoting
vertx-proton doesnt currently expose a way for you to do that. I would
echo the advice there from Clemens on using the Azure client in that
case.

That said, some comments inline.

On 22 March 2018 at 22:54, Abhishek Kumar
 wrote:
> Hi Team,
>
> I need to connect Azure service Bus for sending messages. I followed given
> example and changed only host name to
> amqps://XXX:x...@abcd.servicebus.windows.net/queueName
>

The example expects a hostname and not a URI like above, i.e it doesnt
expect schemes / credentials / queue names, so I expect thats why you
are seeing issues.

> While running the Send class, i am getting below error. I tried a lot but
> could not solve the issue.
>
> Please find attached Example. I think, i need to create SASL connection for
> connecting to Azure Service Bus using host, port, username and password. I
> did not found any sample code to create SASL connection.
>
> It will be highly appreciated if you can provide any sudo code to connect
> Azure Service Bus using  host, port, username and password ?
>

The reactor defaults to doing ANONYMOUS. To configure sasl otherwise,
you need to call sasl() on the Transport object in an
onConnectionBound handler.

There is an example in
https://issues.apache.org/jira/browse/PROTON-1718?focusedCommentId=16316780=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16316780
of doing a completely custom SASL mechanism that shows this and more.
Youd probably just need a simpler thing such as PLAIN, and theres is a
helper method on the Sasl object to do that and set the credentials,
so you could skip the more elaborate listener bits.

You would also need to configure SSL using the ssl() method.

>
> Error
>
> Exception in thread "main" org.apache.qpid.proton.engine.HandlerException:
> java.lang.IllegalStateException: No address provided for Connection at
> org.apache.qpid.proton.engine.impl.EventImpl.dispatch(EventImpl.java:112) at
> org.apache.qpid.proton.reactor.impl.ReactorImpl.dispatch(ReactorImpl.java:324)
> at
> org.apache.qpid.proton.reactor.impl.ReactorImpl.process(ReactorImpl.java:292)
> at org.apache.qpid.proton.reactor.impl.ReactorImpl.run(ReactorImpl.java:357)
> at org.apache.qpid.proton.example.reactor.Send.main(Send.java:151) Caused
> by: java.lang.IllegalStateException: No address provided for Connection at
> org.apache.qpid.proton.reactor.impl.IOHandler.handleBound(IOHandler.java:155)
> at
> org.apache.qpid.proton.reactor.impl.IOHandler.onUnhandled(IOHandler.java:380)
> at
> org.apache.qpid.proton.engine.BaseHandler.onConnectionBound(BaseHandler.java:58)
> at org.apache.qpid.proton.engine.BaseHandler.handle(BaseHandler.java:131) at
> org.apache.qpid.proton.engine.impl.EventImpl.dispatch(EventImpl.java:108)
> ... 4 more
>
>
>
> Regards,
> Abhishek Kumar
>
>
>
> -
> 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: Need Help to send Batch message with Qpid JmS in Java

[Robbie Gemmell]

I was replying to say that I wasnt sure if you were talking about the
custom 'batch message' format Azure also supports, but Qpid JMS
doesn't support it (it could perhaps be shoehorned to send them with
some significant abuse of internals as-is, but receipt would be a
different story), but Clemens beat me to the punch and is obviously a
much better person to speak to that area.

In terms of sending asynchronously, you can use the async send APIs
introduced in JMS 2.0 to have multiple messages in flight at a time,
if thats all you meant.

Robbie

On 23 March 2018 at 08:12, Abhishek Kumar  wrote:
> Hi Team,
>
> We have requirement to send 10k message per second to azure service bus with
> the use of Qpid JMS .
>
> I am not able to find, how can I enable and implement batch functionality
> for sending.
>
> Could you please provide any guidance for sending batch message to service
> bus with Qpid JMS ?
>
> Regards,
> Abhishek Kumar
>
>
>
> --
> 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

AW: Need Help to send Batch message with Qpid JmS in Java

[Clemens Vasters]

Hello Abhishek,

I'm an Architect on the Azure Service Bus Team.

I strongly recommend you use the Service Bus native Java client for this. The 
client builds on Proton-J. 
https://github.com/Azure/azure-service-bus-java 

Batching isn't a standardized AMQP feature, and Service Bus uses a custom AMQP 
message format for this where we fit multiple AMQP messages into an outer 
message. QpidJMS will not be able to reproduce that. 

Be advised that you'll need an Azure Service Bus Premium namespace with 4MU for 
sustainable 10k msg/sec and that you must use asynchronous operations, allowing 
for several unacknowledged messages to remain in flight. Please review this doc 
section for details 
https://docs.microsoft.com/en-us/azure/service-bus-messaging/message-transfers-locks-settlement
 

Best Regards
Clemens  



-Ursprüngliche Nachricht-
Von: Abhishek Kumar  
Gesendet: Friday, March 23, 2018 9:13 AM
An: users@qpid.apache.org
Betreff: Need Help to send Batch message with Qpid JmS in Java

Hi Team,

We have requirement to send 10k message per second to azure service bus with 
the use of Qpid JMS . 

I am not able to find, how can I enable and implement batch functionality for 
sending. 

Could you please provide any guidance for sending batch message to service bus 
with Qpid JMS ?

Regards,
Abhishek Kumar



--
Sent from: 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fqpid.2158936.n2.nabble.com%2FApache-Qpid-users-f2158936.html=04%7C01%7Cclemensv%40microsoft.com%7C6e7688a791704fa9e60c08d59096f43e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636573900377355763%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1=0giL5ADGWF9T7YXdSE11i6p4kkJs0Aoh33Of31sIjXw%3D=0

-
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

Need Help to send Batch message with Qpid JmS in Java

[Abhishek Kumar]

Hi Team,

We have requirement to send 10k message per second to azure service bus with
the use of Qpid JMS . 

I am not able to find, how can I enable and implement batch functionality
for sending. 

Could you please provide any guidance for sending batch message to service
bus with Qpid JMS ?

Regards,
Abhishek Kumar



--
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