Qpid source code reorg update

[Justin Ross]

Proposal: https://github.com/ssorj/qpid-svn-reorg
Previous discussion:
http://qpid.2158936.n2.nabble.com/Qpid-Subversion-reorganization-proposal-td7639094.html

Hi, everyone.

Since my last update, I have been trying to get the revamped C++ tests to
function under Windows.  I've had only mixed success, but now I believe
it's time to press on.

To recap, in addition to reorganizing the source modules for independent
releases, my work overhauled the C++ tests.  This means that there is now
greater potential for Qpid C++ testing on Windows, but that potential will
require more work to realize.

You can see some representative output here:

https://ci.appveyor.com/project/ssorj/qpid-svn-reorg/build/trunk.66

High level summary: the unit tests are not working[*] (and perhaps most of
all, I'd like go get *them* working), but many of the other tests are
working as expected.  I am satisfied that most of the infrastructure for
making those tests work is in place, and we can start to tackle these
things as individual test issues, not test suite design issues.

On Linux (or rather on my F23 box), the tests are in relatively good
shape.  I don't believe the test situation wrt Windows is a regression.
Rather, even though there are many problems to address, I think it may be a
net improvement.

Aside: there have been some related usability improvements as well.  The
install mechanisms now include batch files so that important tools such as
qpid-config and qpid-python-test are executable from the Windows command
line.

What's next?  I'm now up against the scheduled release of Proton 0.13.0.
Here's the sequence I have in mind:

  - Merge my changes to "trunk" (see also
https://github.com/ssorj/qpid-svn-reorg#sequence-with-respect-to-git-migration
)
  - Start the Proton 0.13.0 release process
  - Meanwhile, address new issues arising from the reorg
  - Complete the Proton 0.13.0 release
  - Start and complete the Qpid C++ 1.35.0 and Qpid Python 1.35.0 releases,
using Proton 0.13.0 as a tested dependency

Thanks,
Justin

---

[*] In the appveyor output above, the part where the unit tests run, you
see a failure about not finding the appveyor-vm cert.  Qpidd on Windows by
default tries to find a cert in CurrentUser/My.  The PowerShell scripting I
use to set up the appveyor cert can be adapted to add one there, but it
produces a dialog box warning that I have not yet been able to suppress
(grumble).  I have also tried to configure the unit tests to load the cert
from LocalMachine/My using QPID_* environment variables.  While those
variables have an effect on the daemon, they do not seem to have any effect
on the unit tests binary.

In any case, when I run the unit tests on a local windows machine where I
can setup the certs correctly, I see another and more cryptic failure.

Some related pieces.  Please let me know if you have suggestions.  I would
really like to make this work under appveyor.

https://github.com/ssorj/qpid-svn-reorg/blob/trunk/appveyor.yml#L40
https://github.com/ssorj/qpid-svn-reorg/blob/trunk/scripts/InstallSelfSignedCert.ps1
https://github.com/ssorj/qpid-svn-reorg/blob/trunk/qpid/cpp/src/tests/run_unit_tests#L32

RE: Incompatible code with NSS when buidling Qpid C++ Broker

[Steve Huston]

Offhand, there would be two reasons I can see...

1. The original poster didn't reply to the request to test the patch - Ken said 
he couldn't test it
2. There was no JIRA entered for it with the patch included

-Steve

> -Original Message-
> From: Adel Boutros [mailto:adelbout...@live.com]
> Sent: Wednesday, April 06, 2016 9:27 AM
> To: users@qpid.apache.org
> Subject: Incompatible code with NSS when buidling Qpid C++ Broker
> 
> Hello,
> While building Qpid C++ Broker on SunOS, I encountered an error which has
> to do with NSS specific code.
> After checking this link (http://qpid.2158936.n2.nabble.com/NSS-lt-v3-14-
> and-qpidc-broker-build-td7622467.html) and applying the proposed patch,
> the file compiled correctly.
> Is there a reason this patch is not yet accepted and committed?
> Regards,
> Adel Boutroswww.murex.com
> 

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

Re: Max Frame Size for Java Broker

[rat...@web.de]

>From my point of view for a solution it should have been enough for the
clients to connect with max-frame-size accordingly set to 16K without
modifying the broker. However, this is not working (the client hangs if
sending messages larger than 16K).

Meanwhile I got it working:

Solution was:
1.) No need to modify the client c++ api
2.) Don't set max-frame-size in the client (i.e. in connection options)
3.) Modify the java broker to have a max-frame-size of 0x3FFF instead of
0X
in org/apache/qpid/server/protocol/v0_10/ServerConnectionDelegate.java

Strangely, if I set a max-frame-size:16384 in the connection parameters of
the client, it hangs if sending larger messages than this. If I remove
max-frame-size parameter from the connection option everything works fine.

However, it rather seems to be a problem of the c++ api from my point of
view.



--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Max-Frame-Size-for-Java-Broker-tp7641393p7641504.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

Re: SSL maximum message size?

[rat...@web.de]

Meanwhile I got it working:

Solution was: 
1.) No need to modify the client c++ api
2.) Don't set max-frame-size in the client (i.e. in connection options)
3.) Modify the java broker to have a max-frame-size of 0x3FFF instead of
0X
in org/apache/qpid/server/protocol/v0_10/ServerConnectionDelegate.java

Strangely, if I set a max-frame-size:16384 in the connection parameters of
the client, it hangs if sending larger messages than this. If I remove
max-frame-size parameter from the connection option everything works fine. 



--
View this message in context: 
http://qpid.2158936.n2.nabble.com/SSL-maximum-message-size-tp7641114p7641502.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

Re: Building qpid 0.34 on Solaris

[Adel Boutros]

Hello Raphael,

I am experiencing the same issue. I would like to know if you were able to
provide a workaround or a patch other than just commenting out the
"__thread"?

Regards,
Adel Boutros
www.murex.com



--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Building-qpid-0-34-on-Solaris-tp7628470p7641494.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

RE: Unroutable messages in Java Qpid Broker 6.0.0

[Adel Boutros]

Great!
And I can test it once it is ready to confirm it works.
Adel

> Date: Wed, 6 Apr 2016 15:46:49 +0100
> Subject: Re: Unroutable messages in Java Qpid Broker 6.0.0
> From: rob.j.godf...@gmail.com
> To: users@qpid.apache.org
> 
> Thanks!
> 
> I'll raise a JIRA to cover this later this afternoon, as well as some for
> the configuration options we discussed earlier.
> 
> -- Rob
> 
> 
> On 6 April 2016 at 15:20, Adel Boutros  wrote:
> 
> > Here it is:
> > https://qpid.apache.org/releases/qpid-java-6.0.0/java-broker/book/Java-Broker-Concepts-Exchanges.html#Java-Broker-Concepts-Exchanges-UnroutableMessage
> > When you read the last section "Unrouteable Messages", it is only talking
> > about message being discarded on the broker and not that the client will
> > receive an exception.
> > Regards,Adel
> >
> > > Date: Wed, 6 Apr 2016 14:33:07 +0100
> > > Subject: Re: Unroutable messages in Java Qpid Broker 6.0.0
> > > From: rob.j.godf...@gmail.com
> > > To: users@qpid.apache.org
> > >
> > > Can you point me at the section in the document you are referencing?
> > (Most
> > > of the documentation was written with earlier versions of the protocol in
> > > mind so there may be a few places where the AMQP 1.0 behaviour differs
> > from
> > > that of earlier versions).
> > >
> > > -- Rob
> > >
> > > On 6 April 2016 at 14:26, Adel Boutros  wrote:
> > >
> > > > Hello Rob,
> > > > Thank you for explanation, it makes complete sense and the proposed
> > > > configuration would indeed be highly valued.
> > > > So if I understand correctly, today there is no way to configure it. In
> > > > that case, a workaround would consist in setting for the exchange in
> > > > question an alternate exchange which will be linked to a queue without
> > any
> > > > binding and this will be the queue where all unrouted messages would
> > arrive
> > > > (Something like a default queue). Do you agree?
> > > > Also, would it be possible to update the documentation on the website
> > to
> > > > include a mention to this behavior "and will generate an exception on
> > the
> > > > JMS client-side"? This is to avoid people having to debug through code
> > to
> > > > reach the same findings.
> > > > Regards,Adel
> > > >
> > > > > Date: Wed, 6 Apr 2016 10:18:01 +0100
> > > > > Subject: Re: Unroutable messages in Java Qpid Broker 6.0.0
> > > > > From: rob.j.godf...@gmail.com
> > > > > To: users@qpid.apache.org
> > > > >
> > > > > Hi Adel,
> > > > >
> > > > > As you have discovered, currently when the Java Broker receives a
> > message
> > > > > over AMQP 1.0 where the message cannot be routed to a queue, it
> > rejects
> > > > the
> > > > > message (on the basis that the broker has not actually accepted the
> > > > > transfer of responsibility as it will be discarding it).  This is
> > > > probably
> > > > > appropriate when you are looking for the destination to behave like a
> > > > > "queue" but not when you are expecting "topic" like behaviour.  In
> > > > earlier
> > > > > versions of AMQP, the client could indicate via the "mandatory" flag
> > as
> > > > to
> > > > > whether the broker should consider the failure to route to be an
> > error or
> > > > > not - there is no such mechanism in 1.0.  Having said that, I would
> > > > assume
> > > > > that for topic like "fire and forget" behaviour, the client should be
> > > > > sending the transfers pre-settled (since it does not actually care
> > about
> > > > > the outcome).  It may be that the best solution is to introduce
> > > > > configuration on the exchange to indicate whether incoming links
> > should
> > > > be
> > > > > sent rejections, or messages silently discarded - and then to be
> > able to
> > > > > override this behaviour on a per link basis using some form of link
> > > > target
> > > > > property.
> > > > >
> > > > > -- Rob
> > > > >
> > > > > On 4 April 2016 at 17:30, Adel Boutros  wrote:
> > > > >
> > > > > > Hello,
> > > > > > In the documentation of Qpid Java Broker 6.0.0, it is mentioned
> > here
> > > > that
> > > > > > unroutable messages will be discarded eventually.
> > > > > > I have a test where a queue is bound to a topic and a message is
> > sent
> > > > > > which doesn't match the binding filter on purpose. Instead of the
> > > > message
> > > > > > being just discarded, the sender is receiving an error informing
> > him
> > > > the
> > > > > > message was rejected.
> > > > > > Is this expected? shouldn't the sender be "warned" instead of
> > getting
> > > > an
> > > > > > exception?
> > > > > > Another workaround is to implement a "default" queue which will be
> > > > called
> > > > > > from the alternate exchange but I prefer to check with you this
> > > > behaviour
> > > > > > before implementing the workaround.
> > > > > > Test caseCreate topic "T"Create queue "Q"Create binding between T
> > and Q
> > > > > > using a binding key BK1Have a consumer listen to QHave a sender
> > send
> > > > to T 

Re: Unroutable messages in Java Qpid Broker 6.0.0

[Rob Godfrey]

Thanks!

I'll raise a JIRA to cover this later this afternoon, as well as some for
the configuration options we discussed earlier.

-- Rob


On 6 April 2016 at 15:20, Adel Boutros  wrote:

> Here it is:
> https://qpid.apache.org/releases/qpid-java-6.0.0/java-broker/book/Java-Broker-Concepts-Exchanges.html#Java-Broker-Concepts-Exchanges-UnroutableMessage
> When you read the last section "Unrouteable Messages", it is only talking
> about message being discarded on the broker and not that the client will
> receive an exception.
> Regards,Adel
>
> > Date: Wed, 6 Apr 2016 14:33:07 +0100
> > Subject: Re: Unroutable messages in Java Qpid Broker 6.0.0
> > From: rob.j.godf...@gmail.com
> > To: users@qpid.apache.org
> >
> > Can you point me at the section in the document you are referencing?
> (Most
> > of the documentation was written with earlier versions of the protocol in
> > mind so there may be a few places where the AMQP 1.0 behaviour differs
> from
> > that of earlier versions).
> >
> > -- Rob
> >
> > On 6 April 2016 at 14:26, Adel Boutros  wrote:
> >
> > > Hello Rob,
> > > Thank you for explanation, it makes complete sense and the proposed
> > > configuration would indeed be highly valued.
> > > So if I understand correctly, today there is no way to configure it. In
> > > that case, a workaround would consist in setting for the exchange in
> > > question an alternate exchange which will be linked to a queue without
> any
> > > binding and this will be the queue where all unrouted messages would
> arrive
> > > (Something like a default queue). Do you agree?
> > > Also, would it be possible to update the documentation on the website
> to
> > > include a mention to this behavior "and will generate an exception on
> the
> > > JMS client-side"? This is to avoid people having to debug through code
> to
> > > reach the same findings.
> > > Regards,Adel
> > >
> > > > Date: Wed, 6 Apr 2016 10:18:01 +0100
> > > > Subject: Re: Unroutable messages in Java Qpid Broker 6.0.0
> > > > From: rob.j.godf...@gmail.com
> > > > To: users@qpid.apache.org
> > > >
> > > > Hi Adel,
> > > >
> > > > As you have discovered, currently when the Java Broker receives a
> message
> > > > over AMQP 1.0 where the message cannot be routed to a queue, it
> rejects
> > > the
> > > > message (on the basis that the broker has not actually accepted the
> > > > transfer of responsibility as it will be discarding it).  This is
> > > probably
> > > > appropriate when you are looking for the destination to behave like a
> > > > "queue" but not when you are expecting "topic" like behaviour.  In
> > > earlier
> > > > versions of AMQP, the client could indicate via the "mandatory" flag
> as
> > > to
> > > > whether the broker should consider the failure to route to be an
> error or
> > > > not - there is no such mechanism in 1.0.  Having said that, I would
> > > assume
> > > > that for topic like "fire and forget" behaviour, the client should be
> > > > sending the transfers pre-settled (since it does not actually care
> about
> > > > the outcome).  It may be that the best solution is to introduce
> > > > configuration on the exchange to indicate whether incoming links
> should
> > > be
> > > > sent rejections, or messages silently discarded - and then to be
> able to
> > > > override this behaviour on a per link basis using some form of link
> > > target
> > > > property.
> > > >
> > > > -- Rob
> > > >
> > > > On 4 April 2016 at 17:30, Adel Boutros  wrote:
> > > >
> > > > > Hello,
> > > > > In the documentation of Qpid Java Broker 6.0.0, it is mentioned
> here
> > > that
> > > > > unroutable messages will be discarded eventually.
> > > > > I have a test where a queue is bound to a topic and a message is
> sent
> > > > > which doesn't match the binding filter on purpose. Instead of the
> > > message
> > > > > being just discarded, the sender is receiving an error informing
> him
> > > the
> > > > > message was rejected.
> > > > > Is this expected? shouldn't the sender be "warned" instead of
> getting
> > > an
> > > > > exception?
> > > > > Another workaround is to implement a "default" queue which will be
> > > called
> > > > > from the alternate exchange but I prefer to check with you this
> > > behaviour
> > > > > before implementing the workaround.
> > > > > Test caseCreate topic "T"Create queue "Q"Create binding between T
> and Q
> > > > > using a binding key BK1Have a consumer listen to QHave a sender
> send
> > > to T a
> > > > > message with a binding key BK2
> > > > > Output client-sidejavax.jms.JMSException: Unknown error from remote
> > > peer
> > > > >   at
> > > > >
> > >
> org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:125)
> > > > >  at
> > > > >
> > >
> org.apache.qpid.jms.provider.amqp.AmqpFixedProducer.processDeliveryUpdates(AmqpFixedProducer.java:232)
> > > > >  at
> > > > >
> > >
> 

RE: Unroutable messages in Java Qpid Broker 6.0.0

[Adel Boutros]

Here it is: 
https://qpid.apache.org/releases/qpid-java-6.0.0/java-broker/book/Java-Broker-Concepts-Exchanges.html#Java-Broker-Concepts-Exchanges-UnroutableMessage
When you read the last section "Unrouteable Messages", it is only talking about 
message being discarded on the broker and not that the client will receive an 
exception.
Regards,Adel

> Date: Wed, 6 Apr 2016 14:33:07 +0100
> Subject: Re: Unroutable messages in Java Qpid Broker 6.0.0
> From: rob.j.godf...@gmail.com
> To: users@qpid.apache.org
> 
> Can you point me at the section in the document you are referencing?  (Most
> of the documentation was written with earlier versions of the protocol in
> mind so there may be a few places where the AMQP 1.0 behaviour differs from
> that of earlier versions).
> 
> -- Rob
> 
> On 6 April 2016 at 14:26, Adel Boutros  wrote:
> 
> > Hello Rob,
> > Thank you for explanation, it makes complete sense and the proposed
> > configuration would indeed be highly valued.
> > So if I understand correctly, today there is no way to configure it. In
> > that case, a workaround would consist in setting for the exchange in
> > question an alternate exchange which will be linked to a queue without any
> > binding and this will be the queue where all unrouted messages would arrive
> > (Something like a default queue). Do you agree?
> > Also, would it be possible to update the documentation on the website to
> > include a mention to this behavior "and will generate an exception on the
> > JMS client-side"? This is to avoid people having to debug through code to
> > reach the same findings.
> > Regards,Adel
> >
> > > Date: Wed, 6 Apr 2016 10:18:01 +0100
> > > Subject: Re: Unroutable messages in Java Qpid Broker 6.0.0
> > > From: rob.j.godf...@gmail.com
> > > To: users@qpid.apache.org
> > >
> > > Hi Adel,
> > >
> > > As you have discovered, currently when the Java Broker receives a message
> > > over AMQP 1.0 where the message cannot be routed to a queue, it rejects
> > the
> > > message (on the basis that the broker has not actually accepted the
> > > transfer of responsibility as it will be discarding it).  This is
> > probably
> > > appropriate when you are looking for the destination to behave like a
> > > "queue" but not when you are expecting "topic" like behaviour.  In
> > earlier
> > > versions of AMQP, the client could indicate via the "mandatory" flag as
> > to
> > > whether the broker should consider the failure to route to be an error or
> > > not - there is no such mechanism in 1.0.  Having said that, I would
> > assume
> > > that for topic like "fire and forget" behaviour, the client should be
> > > sending the transfers pre-settled (since it does not actually care about
> > > the outcome).  It may be that the best solution is to introduce
> > > configuration on the exchange to indicate whether incoming links should
> > be
> > > sent rejections, or messages silently discarded - and then to be able to
> > > override this behaviour on a per link basis using some form of link
> > target
> > > property.
> > >
> > > -- Rob
> > >
> > > On 4 April 2016 at 17:30, Adel Boutros  wrote:
> > >
> > > > Hello,
> > > > In the documentation of Qpid Java Broker 6.0.0, it is mentioned here
> > that
> > > > unroutable messages will be discarded eventually.
> > > > I have a test where a queue is bound to a topic and a message is sent
> > > > which doesn't match the binding filter on purpose. Instead of the
> > message
> > > > being just discarded, the sender is receiving an error informing him
> > the
> > > > message was rejected.
> > > > Is this expected? shouldn't the sender be "warned" instead of getting
> > an
> > > > exception?
> > > > Another workaround is to implement a "default" queue which will be
> > called
> > > > from the alternate exchange but I prefer to check with you this
> > behaviour
> > > > before implementing the workaround.
> > > > Test caseCreate topic "T"Create queue "Q"Create binding between T and Q
> > > > using a binding key BK1Have a consumer listen to QHave a sender send
> > to T a
> > > > message with a binding key BK2
> > > > Output client-sidejavax.jms.JMSException: Unknown error from remote
> > peer
> > > >   at
> > > >
> > org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:125)
> > > >  at
> > > >
> > org.apache.qpid.jms.provider.amqp.AmqpFixedProducer.processDeliveryUpdates(AmqpFixedProducer.java:232)
> > > >  at
> > > >
> > org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdates(AmqpProvider.java:804)
> > > > at
> > > >
> > org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(AmqpProvider.java:92)
> > > >at
> > > >
> > org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpProvider.java:701)
> > > > at
> > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> > > > at java.util.concurrent.FutureTask.run(FutureTask.java:262) at
> > > >
> > 

Re: Unroutable messages in Java Qpid Broker 6.0.0

[Rob Godfrey]

Can you point me at the section in the document you are referencing?  (Most
of the documentation was written with earlier versions of the protocol in
mind so there may be a few places where the AMQP 1.0 behaviour differs from
that of earlier versions).

-- Rob

On 6 April 2016 at 14:26, Adel Boutros  wrote:

> Hello Rob,
> Thank you for explanation, it makes complete sense and the proposed
> configuration would indeed be highly valued.
> So if I understand correctly, today there is no way to configure it. In
> that case, a workaround would consist in setting for the exchange in
> question an alternate exchange which will be linked to a queue without any
> binding and this will be the queue where all unrouted messages would arrive
> (Something like a default queue). Do you agree?
> Also, would it be possible to update the documentation on the website to
> include a mention to this behavior "and will generate an exception on the
> JMS client-side"? This is to avoid people having to debug through code to
> reach the same findings.
> Regards,Adel
>
> > Date: Wed, 6 Apr 2016 10:18:01 +0100
> > Subject: Re: Unroutable messages in Java Qpid Broker 6.0.0
> > From: rob.j.godf...@gmail.com
> > To: users@qpid.apache.org
> >
> > Hi Adel,
> >
> > As you have discovered, currently when the Java Broker receives a message
> > over AMQP 1.0 where the message cannot be routed to a queue, it rejects
> the
> > message (on the basis that the broker has not actually accepted the
> > transfer of responsibility as it will be discarding it).  This is
> probably
> > appropriate when you are looking for the destination to behave like a
> > "queue" but not when you are expecting "topic" like behaviour.  In
> earlier
> > versions of AMQP, the client could indicate via the "mandatory" flag as
> to
> > whether the broker should consider the failure to route to be an error or
> > not - there is no such mechanism in 1.0.  Having said that, I would
> assume
> > that for topic like "fire and forget" behaviour, the client should be
> > sending the transfers pre-settled (since it does not actually care about
> > the outcome).  It may be that the best solution is to introduce
> > configuration on the exchange to indicate whether incoming links should
> be
> > sent rejections, or messages silently discarded - and then to be able to
> > override this behaviour on a per link basis using some form of link
> target
> > property.
> >
> > -- Rob
> >
> > On 4 April 2016 at 17:30, Adel Boutros  wrote:
> >
> > > Hello,
> > > In the documentation of Qpid Java Broker 6.0.0, it is mentioned here
> that
> > > unroutable messages will be discarded eventually.
> > > I have a test where a queue is bound to a topic and a message is sent
> > > which doesn't match the binding filter on purpose. Instead of the
> message
> > > being just discarded, the sender is receiving an error informing him
> the
> > > message was rejected.
> > > Is this expected? shouldn't the sender be "warned" instead of getting
> an
> > > exception?
> > > Another workaround is to implement a "default" queue which will be
> called
> > > from the alternate exchange but I prefer to check with you this
> behaviour
> > > before implementing the workaround.
> > > Test caseCreate topic "T"Create queue "Q"Create binding between T and Q
> > > using a binding key BK1Have a consumer listen to QHave a sender send
> to T a
> > > message with a binding key BK2
> > > Output client-sidejavax.jms.JMSException: Unknown error from remote
> peer
> > >   at
> > >
> org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:125)
> > >  at
> > >
> org.apache.qpid.jms.provider.amqp.AmqpFixedProducer.processDeliveryUpdates(AmqpFixedProducer.java:232)
> > >  at
> > >
> org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdates(AmqpProvider.java:804)
> > > at
> > >
> org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(AmqpProvider.java:92)
> > >at
> > >
> org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpProvider.java:701)
> > > at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> > > at java.util.concurrent.FutureTask.run(FutureTask.java:262) at
> > >
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> > >   at
> > >
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> > >  at
> > >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> > > at
> > >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> > > at java.lang.Thread.run(Thread.java:744)
> > > Checking the code of
> > > org.apache.qpid.server.exchange.AbstractExchange#send, when a queue is
> not
> > > found in the routing table of the Exchange and no alternate exchange is
> > > defined, then the message is considered as

Incompatible code with NSS when buidling Qpid C++ Broker

[Adel Boutros]

Hello,
While building Qpid C++ Broker on SunOS, I encountered an error which has to do 
with NSS specific code. 
After checking this link 
(http://qpid.2158936.n2.nabble.com/NSS-lt-v3-14-and-qpidc-broker-build-td7622467.html)
 and applying the proposed patch, the file compiled correctly.
Is there a reason this patch is not yet accepted and committed?
Regards,
Adel Boutroswww.murex.com
  

RE: Unroutable messages in Java Qpid Broker 6.0.0

[Adel Boutros]

Hello Rob,
Thank you for explanation, it makes complete sense and the proposed 
configuration would indeed be highly valued.
So if I understand correctly, today there is no way to configure it. In that 
case, a workaround would consist in setting for the exchange in question an 
alternate exchange which will be linked to a queue without any binding and this 
will be the queue where all unrouted messages would arrive (Something like a 
default queue). Do you agree?
Also, would it be possible to update the documentation on the website to 
include a mention to this behavior "and will generate an exception on the JMS 
client-side"? This is to avoid people having to debug through code to reach the 
same findings.
Regards,Adel

> Date: Wed, 6 Apr 2016 10:18:01 +0100
> Subject: Re: Unroutable messages in Java Qpid Broker 6.0.0
> From: rob.j.godf...@gmail.com
> To: users@qpid.apache.org
> 
> Hi Adel,
> 
> As you have discovered, currently when the Java Broker receives a message
> over AMQP 1.0 where the message cannot be routed to a queue, it rejects the
> message (on the basis that the broker has not actually accepted the
> transfer of responsibility as it will be discarding it).  This is probably
> appropriate when you are looking for the destination to behave like a
> "queue" but not when you are expecting "topic" like behaviour.  In earlier
> versions of AMQP, the client could indicate via the "mandatory" flag as to
> whether the broker should consider the failure to route to be an error or
> not - there is no such mechanism in 1.0.  Having said that, I would assume
> that for topic like "fire and forget" behaviour, the client should be
> sending the transfers pre-settled (since it does not actually care about
> the outcome).  It may be that the best solution is to introduce
> configuration on the exchange to indicate whether incoming links should be
> sent rejections, or messages silently discarded - and then to be able to
> override this behaviour on a per link basis using some form of link target
> property.
> 
> -- Rob
> 
> On 4 April 2016 at 17:30, Adel Boutros  wrote:
> 
> > Hello,
> > In the documentation of Qpid Java Broker 6.0.0, it is mentioned here that
> > unroutable messages will be discarded eventually.
> > I have a test where a queue is bound to a topic and a message is sent
> > which doesn't match the binding filter on purpose. Instead of the message
> > being just discarded, the sender is receiving an error informing him the
> > message was rejected.
> > Is this expected? shouldn't the sender be "warned" instead of getting an
> > exception?
> > Another workaround is to implement a "default" queue which will be called
> > from the alternate exchange but I prefer to check with you this behaviour
> > before implementing the workaround.
> > Test caseCreate topic "T"Create queue "Q"Create binding between T and Q
> > using a binding key BK1Have a consumer listen to QHave a sender send to T a
> > message with a binding key BK2
> > Output client-sidejavax.jms.JMSException: Unknown error from remote peer
> >   at
> > org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:125)
> >  at
> > org.apache.qpid.jms.provider.amqp.AmqpFixedProducer.processDeliveryUpdates(AmqpFixedProducer.java:232)
> >  at
> > org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdates(AmqpProvider.java:804)
> > at
> > org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(AmqpProvider.java:92)
> >at
> > org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpProvider.java:701)
> > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> > at java.util.concurrent.FutureTask.run(FutureTask.java:262) at
> > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> >   at
> > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> >  at
> > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> > at
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> > at java.lang.Thread.run(Thread.java:744)
> > Checking the code of
> > org.apache.qpid.server.exchange.AbstractExchange#send, when a queue is not
> > found in the routing table of the Exchange and no alternate exchange is
> > defined, then the message is considered as
> > org.apache.qpid.amqp_1_0.type.messaging.Rejected. This is what the
> > org.apache.qpid.amqp_1_0.type.Outcome has as value. Then client side, the
> > code checks the value of the Outcome and sets an error in case it was
> > rejected.
> > org.apache.qpid.jms.provider.amqp.AmqpFixedProducer#processDeliveryUpdates}
> > else if (outcome instanceof Rejected) {
> > LOG.trace("Outcome of delivery was rejected: {}", delivery);
> > ErrorCondition remoteError = ((Rejected) outcome).getError();
> > if (remoteError == null) {

Re: Max Frame Size for Java Broker

[Rob Godfrey]

Alex's point is that the Java Broker change shouldn't really be necessary
as if the client wants 16K, the fact that the Broker offers up to 64K
shouldn't matter - the client should just use 16K, and the broker will use
16K... however maybe there is some issue in the client that makes this
necessary.

-- Rob

On 6 April 2016 at 11:03, rat...@web.de  wrote:

> Hi,
> thanks for your feedback. This already helps me a lot. Appearantly I was
> doing the changes at the wrong positions (ServerDelegate.java instead of
> ServerConnectionDelegate.java of the 0-10 protocol).
> I'll redo my experminents. If it's not working I'll generate the
> corresponding client / broker logs as suggested by you.
> Regards
> Tobias
>
>
>
> --
> View this message in context:
> http://qpid.2158936.n2.nabble.com/Max-Frame-Size-for-Java-Broker-tp7641393p7641460.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
>
>

Re: Max Frame Size for Java Broker

[rat...@web.de]

Hi, 
thanks for your feedback. This already helps me a lot. Appearantly I was
doing the changes at the wrong positions (ServerDelegate.java instead of
ServerConnectionDelegate.java of the 0-10 protocol). 
I'll redo my experminents. If it's not working I'll generate the
corresponding client / broker logs as suggested by you.
Regards
Tobias



--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Max-Frame-Size-for-Java-Broker-tp7641393p7641460.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

Reactor Heartbeat [was: RE: Rapid generation of IOExceptions on Proton-J client recv() when HornetQ stopped/becomes unavailable]

[Matthew Karlsen]

Hello All,

After being directed towards the Proton-J reactor (away from the messenger), I 
have been experimenting with reactor. I modified the supplied reactor examples 
to send/recv to/from a queue on HornetQ fairly quickly.

However, I appear to be having less success implementing a heartbeat/keep-alive 
(HornetQ 2.4.0 will disconnect after a one minute default if it does not 
receive data from the client). 

I have scheduled a regular event using [ e.getReactor().schedule(1, this); 
] with a view to implementing a heartbeat. I then override onTimerTask() and 
call tick() or send an empty frame within onTimerTask() then re-schedule 
another call of onTimerTask() -- I have tried several permutations. 

However, whether I use tick(), or send an empty frame, it does not seem to 
maintain the connection.

I was wondering:
1) Are there any better approaches?
2) What is the "correct" approach/location for using tick()?

Thank you & regards,
Matthew



-Original Message-
From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com] 
Sent: 18 March 2016 17:59
To: users@qpid.apache.org
Subject: Re: Rapid generation of IOExceptions on Proton-J client recv() when 
HornetQ stopped/becomes unavailable

On 18 March 2016 at 12:15, Matthew Karlsen  wrote:
> Hello All,
>
> We have a queue running in HornetQ 2.4.0 (embedded within Wildfly), with a 
> Proton-J 0.12.0 client periodically connecting to this queue.
>
> If HornetQ stops or becomes unavailable when the Proton-J client is running, 
> the Proton-J client continually generates exceptions similar to that below 
> (very rapidly).
>
> The issue is that the IOException generated exception is handled in 
> MessengerImpl's processActive() by generating an "Error processing 
> connection" message in the logs, rather than recv() throwing an exception and 
> hence the higher level program logic is unable to react to the problem.
>
> Is this a bug or am I missing something important?
>
> Thank you,
> Matthew
>
> java.io.IOException: An existing connection was forcibly closed by the remote 
> host
> at sun.nio.ch.SocketDispatcher.read0(Native Method)
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43)
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
> at sun.nio.ch.IOUtil.read(IOUtil.java:197)
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
> at 
> org.apache.qpid.proton.driver.impl.ConnectorImpl.read(ConnectorImpl.java:129)
> at 
> org.apache.qpid.proton.driver.impl.ConnectorImpl.process(ConnectorImpl.java:94)
> at 
> org.apache.qpid.proton.messenger.impl.MessengerImpl.processActive(MessengerImpl.java:738)
> at 
> org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:895)
> at 
> org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:844)
> at 
> org.apache.qpid.proton.messenger.impl.MessengerImpl.recv(MessengerImpl.java:446)
> at 
> org.apache.qpid.proton.messenger.impl.MessengerImpl.recv(MessengerImpl.java:451)
> ...
> at java.lang.Thread.run(Thread.java:745)
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For 
> additional commands, e-mail: users-h...@qpid.apache.org
>

Hi Matthew,

It certainly doesnt seem desirable, I'd guess its a bug, though someone 
actually familiar with Messenger could certainly correct me on that.

Messenger isn't widely used on the proton-j side, and in general Messenger 
isn't getting much developer attention these days (arguably never did in 
proton-j, which is mostly still used as an pure protocol engine as intended at 
the outset) since folks are concentrated more on newer reactive APIs.

Proton-J is a bit behind the curve in terms of the higher level reactive work 
being/already done in some of the other lanaguages (something I'll be looking 
to get to), but there was a Java port done of the 'reactor' that exists in 
proton-c and some of its bindings. I'm not particularly familiar with it 
either, or how it would handle this situation, but it may be worth you looking 
at as alternative to Messenger. You can see some example of it in the 
examples/java/reactor dir, e.g. the Send class (the Recv class in this case is 
actually a server/listener that accepts incoming connections, such as those 
made by Send).

Robbie

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

Re: Unroutable messages in Java Qpid Broker 6.0.0

[Rob Godfrey]

Hi Adel,

As you have discovered, currently when the Java Broker receives a message
over AMQP 1.0 where the message cannot be routed to a queue, it rejects the
message (on the basis that the broker has not actually accepted the
transfer of responsibility as it will be discarding it).  This is probably
appropriate when you are looking for the destination to behave like a
"queue" but not when you are expecting "topic" like behaviour.  In earlier
versions of AMQP, the client could indicate via the "mandatory" flag as to
whether the broker should consider the failure to route to be an error or
not - there is no such mechanism in 1.0.  Having said that, I would assume
that for topic like "fire and forget" behaviour, the client should be
sending the transfers pre-settled (since it does not actually care about
the outcome).  It may be that the best solution is to introduce
configuration on the exchange to indicate whether incoming links should be
sent rejections, or messages silently discarded - and then to be able to
override this behaviour on a per link basis using some form of link target
property.

-- Rob

On 4 April 2016 at 17:30, Adel Boutros  wrote:

> Hello,
> In the documentation of Qpid Java Broker 6.0.0, it is mentioned here that
> unroutable messages will be discarded eventually.
> I have a test where a queue is bound to a topic and a message is sent
> which doesn't match the binding filter on purpose. Instead of the message
> being just discarded, the sender is receiving an error informing him the
> message was rejected.
> Is this expected? shouldn't the sender be "warned" instead of getting an
> exception?
> Another workaround is to implement a "default" queue which will be called
> from the alternate exchange but I prefer to check with you this behaviour
> before implementing the workaround.
> Test caseCreate topic "T"Create queue "Q"Create binding between T and Q
> using a binding key BK1Have a consumer listen to QHave a sender send to T a
> message with a binding key BK2
> Output client-sidejavax.jms.JMSException: Unknown error from remote peer
>   at
> org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:125)
>  at
> org.apache.qpid.jms.provider.amqp.AmqpFixedProducer.processDeliveryUpdates(AmqpFixedProducer.java:232)
>  at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdates(AmqpProvider.java:804)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(AmqpProvider.java:92)
>at
> org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpProvider.java:701)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262) at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
>   at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
>  at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> Checking the code of
> org.apache.qpid.server.exchange.AbstractExchange#send, when a queue is not
> found in the routing table of the Exchange and no alternate exchange is
> defined, then the message is considered as
> org.apache.qpid.amqp_1_0.type.messaging.Rejected. This is what the
> org.apache.qpid.amqp_1_0.type.Outcome has as value. Then client side, the
> code checks the value of the Outcome and sets an error in case it was
> rejected.
> org.apache.qpid.jms.provider.amqp.AmqpFixedProducer#processDeliveryUpdates}
> else if (outcome instanceof Rejected) {
> LOG.trace("Outcome of delivery was rejected: {}", delivery);
> ErrorCondition remoteError = ((Rejected) outcome).getError();
> if (remoteError == null) {
> remoteError = getEndpoint().getRemoteCondition();
> }
>
> deliveryError = AmqpSupport.convertToException(remoteError);
> }
> Regards,
> Adel Boutroswww.murex.com