Receiver fetch mybey block forever

[634749...@qq.com]

hello!

I use the c++ broker and c++ client api(version 0.34);the broker running on
centos,and the client on windows server 2008;
if the network is not stability between client and broker , I found the
receive fetch() function maybe block forever. 

eg：
Receiver receiver;
Message message;
while(receiver.fetch(message,Duration::IMMEDIATE))
{
// ...
}




--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Receiver-fetch-mybey-block-forever-tp7650498.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

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

some questions about Receiver get() and fetch() function

[634749...@qq.com]

hello!

I use the c++ broker and c++ client api(version 0.34),Now I have some
question about Receiver funtion fetch and get;

call example:
Session session;
Receiver receiver;
receive = session.createReceiver();
receive.setCapacity(1000);

So I receive message from broker just need to call the receive get()
function? Should I need to call the receive fetch() function each period of
time?  



--
View this message in context: 
http://qpid.2158936.n2.nabble.com/some-questions-about-Receiver-get-and-fetch-function-tp7650497.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

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

[RESULT] [VOTE] Release Qpid JMS client 0.11.0

[Robbie Gemmell]

There were 5 binding +1 votes, and no other votes received. The vote has passed.

I will add the archives to the dist release repo and release the maven
staging repo shortly. The website will be updated later after the
artifacts have had time to sync to the mirrors and maven central.

Robbie

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

Re: [VOTE] Release Qpid JMS client 0.11.0

[Robbie Gemmell]

On 5 September 2016 at 16:47, Robbie Gemmell  wrote:
> Hi folks,
>
> I have put together a spin for a 0.11.0 Qpid JMS client release, please
> test it and vote accordingly.
>
> The source and binary archives can be grabbed from:
> https://dist.apache.org/repos/dist/dev/qpid/jms/0.11.0-rc1/
>
> Those files and the other maven artifacts are also staged for now at:
> https://repository.apache.org/content/repositories/orgapacheqpid-1085
>
> 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-1085
> 
>   
>
> The dependency for the client itself would then be:
>
>   
> org.apache.qpid
> qpid-jms-client
> 0.11.0
>   

Adding my +1.

I checked things out as follows:
 - Verified the checksums and signatures.
 - Checked LICENCE+NOTICE files present.
 - Checked licence headers with mvn apache-rat:check.
 - Ran the build and tests from the source archive, no issues.
 - Used the staging repo with maven to build/run examples from the bin
archive against Dispatch, Java broker, C++ broker, and ActiveMQ 5.
 - Built/run the examples source in the bin archive manually using javac.
 - Used the staging repo to run the ActiveMQ 5 master build and AMQP
tests which use the client.

Robbie

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

Re: [proton-j] Connections per client

[Robbie Gemmell]

That doesn't sound expected and I've likely done something vaguely
similar with it in the past (minus the verticles). I'd say that sounds
like a bug in either your [server] usage, the vert.x wrapping of
proton-j, vert.x (/netty, though seems unlikely), and then maybe
proton-j itself (which as being used is just giving/taking a stream of
bytes and doesn't know or care much about most of the rest).

In general I'd expect most questions/issues around those bits to begin
in the vert.x community, and then if some issue or discussion became
centered around proton-j itself it would things transition here.

If you have a reproducer I'd suggest debugging what differs between
the success and failure case and perhaps giving details (and even the
reproducer) on a vertx issue.

Robbie

On 7 September 2016 at 17:15, Hudalla Kai (INST/ESY1)
 wrote:
> On Mi, 2016-09-07 at 15:53 +0100, Robbie Gemmell wrote:
>> Hi Kai,
>>
>> While im inbetween coughs and sneezes here...
>>
>> I'm not sure I understand the question. If you could expand a bit it
>> may help, and perhaps elaborate on what code or behaviour is giving
>> the impression.
>>
> Ok, I'll try to be more specific:
>
> In Hono we have implemented an AMQP 1.0 server as a Verticle that uses
> vertx-proton. When I deploy this verticle once to a vert.x instance and
> connect to it from another vertx-proton based AMQP 1.0 client (again,
> deployed to another vert.x instance) then this works fine, i.e. the
> client can connect to the server and establish an AMQP connection.
>
> However, when I deploy the client verticle twice (in order to scale it
> up), then only one of the two verticles is able to connect to the
> server while the other "hangs", i.e. the ProtonClient.connect() call
> never completes nor fails the handler provided as an argument to it.
>
>> It might not once I better understand, but for now this seems more
>> suited for the Vert.x community: http://vertx.io/community/
>>
>
> This is actually part of my question :-) Is this intended behavior of
> vertx-proton or proton-j or is this a limitation of vert.x handling of
> multiple verticles using TcpServer and TcpClient simultaneously.
>
>> Robbie
>>
>> On 6 September 2016 at 16:32, Hudalla Kai (INST/ESY1)
>>  wrote:
>> >
>> > Hi,
>> >
>> > I have implemented an AMQP 1.0 server on top of vertx-proton (using
>> > proton-j under the hood). When I connect to the server, I get the
>> > impression that the server will only accept and establish a single
>> > connection per client (identified by IP address/port).
>> >
>> > Is that right, and is this configurable?
>> >
>> > --
>> > Mit freundlichen Grüßen / Best regards
>> >
>> > Kai Hudalla
>> > Chief Software Architect
>> >
>> > Bosch Software Innovations GmbH
>> > Schöneberger Ufer 89-91
>> > 10785 Berlin
>> > GERMANY
>> > www.bosch-si.com
>> >
>> > Registered office: Berlin, Register court: Amtsgericht
>> > Charlottenburg,
>> > HRB 148411 B;
>> > Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>> -
>> 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

[Qpid Java Broker 6.0.x] Random failure in queue creation/deletion using REST calls

[Adel Boutros]

Hello guys,

As I mentioned in my previous post, I am having some random REST call failures 
when deleting and creating a queue. I was able to have a smaller test code but 
still the error is very random. I launch my test code 10 000 times to get the 
exception: The failure occurs sometimes at run 600 or run 2000, etc...

I don't know if someone has faced a similar issue before.

I have also created a Jira issue for this with the minimalist test code I could 
find so far:
https://issues.apache.org/jira/browse/QPID-7420

Do not hesitate to let me know if there are missing information.

I have tested with Java Broker 6.0.0, 6.0.1 and 6.0.4 and they all have the 
issue.

I would like to keep debugging the issue from my side. So I was wondering if 
you could provide me some hints where to look in the code or what to activate 
to see in the logs if possible?

Regards,
Adel