RE: ServiceBus and Proton-C 0.12 IOP Issue

2016-02-25 Thread Randy Armstrong
I think it is related to proton because the exact same messages using the exact 
same credentials are processed by an AMQPlite client running at the same time.

I am assuming it is related to how the message is constructed because an error 
that affected all ServiceBus clients should have been seen before my report.

The text 'System.ArgumentNullException: Value cannot be null' comes from a .NET 
library (it is the standard error text for a null pointer passed to a function).
So the error is on the ServiceBus side but it is related to something the 
proton library is sending.
Maybe related to an ACK for the message? 

-Original Message-
From: Andrew Stitcher [mailto:astitc...@redhat.com] 
Sent: Thursday, February 25, 2016 2:51 PM
To: users@qpid.apache.org
Subject: Re: ServiceBus and Proton-C 0.12 IOP Issue

On Thu, 2016-02-25 at 14:26 -0800, Randy Armstrong wrote:
> ...
> I then get what looks like a NULL pointer error from .NET:

It doesn't look like that to me (but I know very little about how Azure works).

> ...
> [00AADD40]:0 <- @detach(22) [handle=0, closed=true, error=@error(29) 
> [condition=:"amqp:link:detach-forced", description="The link 
> 'G12:16548697:MyTopic/Subscriptions/default' is force detached by the 
> broker due to errors occurred in consumer(link39638). Detach origin:
> ExceptionId: 1d35d46d-a26d-493e-8b1c-a01ffbe0cdad-
> System.ArgumentNullException: Value cannot be null.\x0d\x0aParameter
> name: collection.
> TrackingId:44365b43000200109ad656cf7eb9_G12_B31,TimeStamp:2/25/20
> 16 10:23:01 PM"]]

This is the Azure broker force closing the link with an error. The error from 
the Azure end seems to be:

System.ArgumentNullException: Value cannot be null.
Parameter name: collection.

With some tracking information around it.

So I think Azure is telling you that there needs to be a non null collection 
parameter (whatever that is).

Perhaps someone with knowledge of Servicebus can make some informed comments.

> I am guessing this is because my message is missing a field that 
> proton expects.

Why do think it's to do with proton?

Andrew


-
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: Gneral Question: Does QPID a message size limit?

2016-02-25 Thread Jakub Scholz
The C++ broker also doesn't have any problems with 10MB messages. we use
them quite regularly (including persistence). I'm not 100% sure what is the
maximal limit, but I usually start getting careful around 100MB. The reason
for that is not always only the broker, but also the clients which need to
have sufficient memory to handle the messages etc.

On Thu, Feb 25, 2016 at 11:20 PM, Rob Godfrey 
wrote:

> Each different component of Qpid may have different limitations.  As far as
> the Java Broker goes (and the Java AMQP 0-8/0-9/0-9-1/0-10 client - since
> they share a common underlying library) the theoretical message size limit
> is 2GB.  By default the Java Broker rejects messages over 500MB in size,
> but this is just a configuration parameter.  I know we've had people write
> systems that frequently sent persistent messages in the 5-20 MB range.
> I'll let others speak to any limitations in other Qpid components.
>
> -- Rob
>
> On 25 February 2016 at 23:13, Flores, Paul A. 
> wrote:
>
> > At a client site working on the adoption of QPID.
> >
> >
> >
> > The question that has been asked is if QPID can handle messages in the 10
> > MB size range.
> >
> >
> >
> > Is there a documented message size limit anywhere?  Is the size system
> > resource dependent?
> >
> >
> >
> > Thanks for your inputs it is welcomed and appreciated.
> >
> >
> >
> > Paul
> >
>


RE: Gneral Question: Does QPID a message size limit?

2016-02-25 Thread Flores, Paul A.
Thanks Rob

Anyone with some C++ specific information?


From: Rob Godfrey [rob.j.godf...@gmail.com]
Sent: Thursday, February 25, 2016 4:20 PM
To: users@qpid.apache.org
Subject: Re: Gneral Question: Does QPID a message size limit?

Each different component of Qpid may have different limitations.  As far as
the Java Broker goes (and the Java AMQP 0-8/0-9/0-9-1/0-10 client - since
they share a common underlying library) the theoretical message size limit
is 2GB.  By default the Java Broker rejects messages over 500MB in size,
but this is just a configuration parameter.  I know we've had people write
systems that frequently sent persistent messages in the 5-20 MB range.
I'll let others speak to any limitations in other Qpid components.

-- Rob

On 25 February 2016 at 23:13, Flores, Paul A. 
wrote:

> At a client site working on the adoption of QPID.
>
>
>
> The question that has been asked is if QPID can handle messages in the 10
> MB size range.
>
>
>
> Is there a documented message size limit anywhere?  Is the size system
> resource dependent?
>
>
>
> Thanks for your inputs it is welcomed and appreciated.
>
>
>
> Paul
>
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org



Re: ServiceBus and Proton-C 0.12 IOP Issue

2016-02-25 Thread Andrew Stitcher
On Thu, 2016-02-25 at 21:16 +, Gordon Sim wrote:
> On 25/02/16 16:01, Randy Armstrong wrote:
> > 
> > [00B3D578]:0 <- @detach(22) [handle=0, closed=true, error=@error(29
> > )
> > [condition=:"amqp:unauthorized-access", description="Unauthorized
> > access.
> > 'Listen' claim(s) are required to perform this operation. Resource:
> > 'sb://opcfoundation-
> > prototyping.servicebus.windows.net/mytopic/subscriptions
> > /default'.
> > TrackingId:46e13f2c7e0043978dd72021e52b7d22_G22,TimeStamp:2/25/2016
> > 3:26:50
> > PM"]]
> > 
> 
> There was another thread with a similar error recently: 
> https://mail-archives.apache.org/mod_mbox/qpid-users/201509.mbox/%3CD
> ub131-w49fb20a540cac27559ffadc9...@phx.gbl%3E
> 
> I think the issue there was changes in the way the SASL mechanism
> was 
> selected?

I remember that conversation - I think we concluded it was a bug in
Azure, as it was proposing a SASL mechanism it couldn't go on to honor
later. Clearly it hasn't been fixed yet.

In the messenger API there is no way to exclude SASL mechanisms
(PROTON-996 [1]) you will need to use a different API for that. I'd
suggest you look at the reactive APIs for this - they are where most of
our development work is currently going.

Andrew

[1] https://issues.apache.org/jira/browse/PROTON-996

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



RE: ServiceBus and Proton-C 0.12 IOP Issue

2016-02-25 Thread Randy Armstrong
In the function:
pni_process_mechanisms(pn_transport_t *transport, const char *mechs)
mechs = MSSBCBS PLAIN ANONYMOUS EXTERNAL

transport->sasl->username and transport->sasl->password are correct.

EXTERNAL is selected because it is first to be tested in the function.
I changed the order so PLAIN was processed first and it connects and receives 1 
message.
I then get what looks like a NULL pointer error from .NET:

[00AADD40]:0 <- @transfer(20) [handle=0, delivery-id=0, 
delivery-tag=b"w\xff\xf7&\xa1y\x82H\x96\xd7p4:\xe5H\x84", message-format=0, 
more=false, batchable=true] (532) 
"\x00Sp\xc0\x0a\x05@@p\x00\x00\xea`@C\x00Sr\xc1\\x06\xa3\x13x-opt-enqueued-time\x83\x00\x00\x01S\x1a\x870b\xa3\x15x-opt-sequence-number\x81\x00\x00\x00\x00\x00\x00\xd0G\xa3\x12x-opt-locked-until\x83\x00\x00\x01S\x1a\x87\xa5\xa2\x00Ss\xc0\x8a\x0d\xa1$818bdc02-5412-4204-bf45-f54be347db0e@@@\xa1?http://opcfoundation-prototyping.servicebus.windows.net/MyTopic@\xa3\x16application/opcua+amqpC@\x00St\xc1\x01\x00\x00Su\xb0\x00\x00\x01\x07{"EventId":"9CaTawVxAEqCL+U2tU5r6w==","SourceNode":{"Id":"i=2253"},"SourceName":"System","EventType":{"Id":"i=11446"},"Time":"2016-02-25T22:22:43.6084751Z","ReceiveTime":"2016-02-25T22:22:43.6084751Z","Message":"The
 system cycle '5531' has started.","Severity":1}"
Application consumed 574 bytes from peer
process_input_ssl() returning 613, forwarded 574
Address: (null)
Subject: (no subject)
Content: 
b"{"EventId":"9CaTawVxAEqCL+U2tU5r6w==","SourceNode":{"Id":"i=2253"},"SourceName":"System","EventType":{"Id":"i=11446"},"Time":"2016-02-25T22:22:43.6084751Z","ReceiveTime":"2016-02-25T22:22:43.6084751Z","Message":"The
 system cycle '5531' has started.","Severity":1}"
process_output_ssl( max_len=16384 )
[00AADD40]:0 -> @disposition(21) [role=true, first=0, last=0, settled=true]
Gathered 27 bytes from app to send to peer
ssl_encrypt 53 network bytes
Next decryption, 0 left over
[00AADD40]:0 <- @detach(22) [handle=0, closed=true, error=@error(29) 
[condition=:"amqp:link:detach-forced", description="The link 
'G12:16548697:MyTopic/Subscriptions/default' is force detached by the broker 
due to errors occurred in consumer(link39638). Detach origin: ExceptionId: 
1d35d46d-a26d-493e-8b1c-a01ffbe0cdad-System.ArgumentNullException: Value cannot 
be null.\x0d\x0aParameter name: collection. 
TrackingId:44365b43000200109ad656cf7eb9_G12_B31,TimeStamp:2/25/2016 
10:23:01 PM"]]
Application consumed 427 bytes from peer

I am guessing this is because my message is missing a field that proton expects.
Any idea what this field is?

-Original Message-
From: Cliff Jansen [mailto:cliffjan...@gmail.com] 
Sent: Thursday, February 25, 2016 12:54 PM
To: users@qpid.apache.org
Subject: Re: ServiceBus and Proton-C 0.12 IOP Issue

Thank-you for the additional information.

It appears that you successfully create an SSL encrypted TCP connection 
acceptable to each peer.  So SSL configuration seems fine.

It further appears that the service bus refuses to create a link to your topic 
based on an unauthorized access attempt, presumably based on the credentials 
you supplied.  Yet the credentials are OK based on their same use in AMQPLite.

Perhaps there is some quoting problem providing the url to messenger (from the 
command line?).  Or possibly the url encoded service bus key is being parsed 
incorrectly by Proton.

You could try creating your own pn_url_t (see url.h) from the url you are using 
with pn_url_parse(), and see if the associated
pn_url_username() and pn_url_password() are what you expect.

If all that is fine and you are compiling your own Proton library, you could 
further check that PLAIN sasl processing is the chosen sasl mechanism and that 
a correct username and password make it to that layer (in none_sasl.c).

On Thu, Feb 25, 2016 at 8:01 AM, Randy Armstrong  
wrote:
> I am using the "recv" example from the 0.12 codebase.
>
>
>
> The URL I am using is:
>
> amqps://receiver: key>@opcfoundation-prototyping.servicebus.windows.net/MyTopic/Subscrip
> key>tions/
> default"
>
>
>
> I have tried with
>
> pn_messenger_set_flags(messenger, PN_FLAGS_ALLOW_INSECURE_MECHS);
>
> and
>
> pn_messenger_set_flags(messenger, 0);
>
>
>
> The credentials are identical to what I provide to a AMQPLite client 
> that has no problems connecting and receiving messages.
>
>
>
> Any hints/suggestions/links to documentation would be appreciated.
>
>
>
> The trace from the program shows this error:
>
>
>
> [00B3D578]:0 <- @attach(18) [name="MyTopic/Subscriptions/default", 
> handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0, 
> initial-delivery-count=0, max-message-size=266240]
>
> Application consumed 68 bytes from peer
>
> process_input_ssl() returning 101, forwarded 68
>
> process_output_ssl( max_len=16384 )
>
> process_output_ssl() returning 0
>
> process_output_ssl( max_len=16384 )
>
> process_output_ssl() returning 0
>
> process_input_ssl( data size=357 )
>
> Next decryption, 0 left over
>
> 

Re: Gneral Question: Does QPID a message size limit?

2016-02-25 Thread Rob Godfrey
Each different component of Qpid may have different limitations.  As far as
the Java Broker goes (and the Java AMQP 0-8/0-9/0-9-1/0-10 client - since
they share a common underlying library) the theoretical message size limit
is 2GB.  By default the Java Broker rejects messages over 500MB in size,
but this is just a configuration parameter.  I know we've had people write
systems that frequently sent persistent messages in the 5-20 MB range.
I'll let others speak to any limitations in other Qpid components.

-- Rob

On 25 February 2016 at 23:13, Flores, Paul A. 
wrote:

> At a client site working on the adoption of QPID.
>
>
>
> The question that has been asked is if QPID can handle messages in the 10
> MB size range.
>
>
>
> Is there a documented message size limit anywhere?  Is the size system
> resource dependent?
>
>
>
> Thanks for your inputs it is welcomed and appreciated.
>
>
>
> Paul
>


Gneral Question: Does QPID a message size limit?

2016-02-25 Thread Flores, Paul A.
At a client site working on the adoption of QPID.



The question that has been asked is if QPID can handle messages in the 10 MB 
size range.



Is there a documented message size limit anywhere?  Is the size system resource 
dependent?



Thanks for your inputs it is welcomed and appreciated.



Paul


Re: ServiceBus and Proton-C 0.12 IOP Issue

2016-02-25 Thread Gordon Sim

On 25/02/16 16:01, Randy Armstrong wrote:


[00B3D578]:0 <- @detach(22) [handle=0, closed=true, error=@error(29)
[condition=:"amqp:unauthorized-access", description="Unauthorized access.
'Listen' claim(s) are required to perform this operation. Resource:
'sb://opcfoundation-prototyping.servicebus.windows.net/mytopic/subscriptions
/default'.
TrackingId:46e13f2c7e0043978dd72021e52b7d22_G22,TimeStamp:2/25/2016 3:26:50
PM"]]



There was another thread with a similar error recently: 
https://mail-archives.apache.org/mod_mbox/qpid-users/201509.mbox/%3cdub131-w49fb20a540cac27559ffadc9...@phx.gbl%3E


I think the issue there was changes in the way the SASL mechanism was 
selected?



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



Re: ServiceBus and Proton-C 0.12 IOP Issue

2016-02-25 Thread Cliff Jansen
Thank-you for the additional information.

It appears that you successfully create an SSL encrypted TCP
connection acceptable to each peer.  So SSL configuration seems fine.

It further appears that the service bus refuses to create a link to
your topic based on an unauthorized access attempt, presumably based
on the credentials you supplied.  Yet the credentials are OK based
on their same use in AMQPLite.

Perhaps there is some quoting problem providing the url to messenger
(from the command line?).  Or possibly the url encoded service bus key
is being parsed incorrectly by Proton.

You could try creating your own pn_url_t (see url.h) from the url you
are using with pn_url_parse(), and see if the associated
pn_url_username() and pn_url_password() are what you expect.

If all that is fine and you are compiling your own Proton library, you
could further check that PLAIN sasl processing is the chosen sasl
mechanism and that a correct username and password make it to that
layer (in none_sasl.c).

On Thu, Feb 25, 2016 at 8:01 AM, Randy Armstrong
 wrote:
> I am using the "recv" example from the 0.12 codebase.
>
>
>
> The URL I am using is:
>
> amqps://receiver: key>@opcfoundation-prototyping.servicebus.windows.net/MyTopic/Subscriptions/
> default"
>
>
>
> I have tried with
>
> pn_messenger_set_flags(messenger, PN_FLAGS_ALLOW_INSECURE_MECHS);
>
> and
>
> pn_messenger_set_flags(messenger, 0);
>
>
>
> The credentials are identical to what I provide to a AMQPLite client that
> has no problems connecting and receiving messages.
>
>
>
> Any hints/suggestions/links to documentation would be appreciated.
>
>
>
> The trace from the program shows this error:
>
>
>
> [00B3D578]:0 <- @attach(18) [name="MyTopic/Subscriptions/default", handle=0,
> role=false, snd-settle-mode=2, rcv-settle-mode=0, initial-delivery-count=0,
> max-message-size=266240]
>
> Application consumed 68 bytes from peer
>
> process_input_ssl() returning 101, forwarded 68
>
> process_output_ssl( max_len=16384 )
>
> process_output_ssl() returning 0
>
> process_output_ssl( max_len=16384 )
>
> process_output_ssl() returning 0
>
> process_input_ssl( data size=357 )
>
> Next decryption, 0 left over
>
> [00B3D578]:0 <- @detach(22) [handle=0, closed=true, error=@error(29)
> [condition=:"amqp:unauthorized-access", description="Unauthorized access.
> 'Listen' claim(s) are required to perform this operation. Resource:
> 'sb://opcfoundation-prototyping.servicebus.windows.net/mytopic/subscriptions
> /default'.
> TrackingId:46e13f2c7e0043978dd72021e52b7d22_G22,TimeStamp:2/25/2016 3:26:50
> PM"]]
>
> Application consumed 317 bytes from peer
>
> process_input_ssl() returning 357, forwarded 317
>
> process_output_ssl( max_len=16384 )
>
> [00B3D578]:0 -> @detach(22) [handle=0, closed=true]
>
> Gathered 24 bytes from app to send to peer
>
> ssl_encrypt 53 network bytes
>
>
>
>
>

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



RE: General Question: Network Load Balanacing?

2016-02-25 Thread Steve Huston
Hi Paul,

I work with a set of customers that set this kind of thing up as a set of 
meshed brokers with federation links that both load balances and acts as a 
mechanism of high availability.

-Steve Huston

> -Original Message-
> From: Flores, Paul A. [mailto:paul.a.flo...@saic.com]
> Sent: Thursday, February 25, 2016 3:13 PM
> To: users@qpid.apache.org
> Subject: General Question: Network Load Balanacing?
> 
> At a client site evaluating aspects of QPID for adoption for its use in a 
> mission
> critical application.
> 
> 
> 
> This is one question / area I was asked to elicit information regarding 
> current
> capabilities, plans and alternatives.
> 
> 
> 
> Has anyone looked at either the distributed broker functionality and / or the
> dispatcher in this context?  If so can you please share your insights.
> 
> 
> 
> Is there anything specific in this area someone can point me towards?
> 
> 
> 
> Thanks your thoughts, insights, comments and inputs are welcomed.
> 
> 
> 
> Paul

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



General Question: Network Load Balanacing?

2016-02-25 Thread Flores, Paul A.
At a client site evaluating aspects of QPID for adoption for its use in a 
mission critical application.



This is one question / area I was asked to elicit information regarding current 
capabilities, plans and alternatives.



Has anyone looked at either the distributed broker functionality and / or the 
dispatcher in this context?  If so can you please share your insights.



Is there anything specific in this area someone can point me towards?



Thanks your thoughts, insights, comments and inputs are welcomed.



Paul


Re: Qpid Subversion reorganization proposal

2016-02-25 Thread Gordon Sim

On 24/02/16 19:03, Andrew Stitcher wrote:

On Wed, 2016-02-24 at 06:15 -0800, Justin Ross wrote:

...

This actually goes quite far beyond what I was expecting before the
upcoming cpp etc releases, looks like you have been busy! :)


Seconded - I'm really impressed with how far you have taken this.


+1; nice work, Justin!


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



ServiceBus and Proton-C 0.12 IOP Issue

2016-02-25 Thread Randy Armstrong
I am using the "recv" example from the 0.12 codebase.

 

The URL I am using is:

amqps://receiver:@opcfoundation-prototyping.servicebus.windows.net/MyTopic/Subscriptions/
default"

 

I have tried with 

pn_messenger_set_flags(messenger, PN_FLAGS_ALLOW_INSECURE_MECHS);

and

pn_messenger_set_flags(messenger, 0);

 

The credentials are identical to what I provide to a AMQPLite client that
has no problems connecting and receiving messages.

 

Any hints/suggestions/links to documentation would be appreciated.

 

The trace from the program shows this error:

 

[00B3D578]:0 <- @attach(18) [name="MyTopic/Subscriptions/default", handle=0,
role=false, snd-settle-mode=2, rcv-settle-mode=0, initial-delivery-count=0,
max-message-size=266240]

Application consumed 68 bytes from peer

process_input_ssl() returning 101, forwarded 68

process_output_ssl( max_len=16384 )

process_output_ssl() returning 0

process_output_ssl( max_len=16384 )

process_output_ssl() returning 0

process_input_ssl( data size=357 )

Next decryption, 0 left over

[00B3D578]:0 <- @detach(22) [handle=0, closed=true, error=@error(29)
[condition=:"amqp:unauthorized-access", description="Unauthorized access.
'Listen' claim(s) are required to perform this operation. Resource:
'sb://opcfoundation-prototyping.servicebus.windows.net/mytopic/subscriptions
/default'.
TrackingId:46e13f2c7e0043978dd72021e52b7d22_G22,TimeStamp:2/25/2016 3:26:50
PM"]]

Application consumed 317 bytes from peer

process_input_ssl() returning 357, forwarded 317

process_output_ssl( max_len=16384 )

[00B3D578]:0 -> @detach(22) [handle=0, closed=true]

Gathered 24 bytes from app to send to peer

ssl_encrypt 53 network bytes

 

 



Re: Help with Dispatch Build "difficulties" - new issue

2016-02-25 Thread Alan Conway
On Wed, 2016-02-24 at 13:52 -0500, Ken Giusti wrote:
> Hrm - where did libqpid-proton-cpp.* files come from?  I don't
> recognize any proton library that has that -cpp suffix.

Those are the new C++ binding, which I think implies you have installed
proton 12.0 or master at some point as they weren't in 0.11.

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



Re: Frame too large for buffer

2016-02-25 Thread Gordon Sim

On 25/02/16 12:34, Filipe Santos wrote:

Hi

I’m experiencing the error “Frame too large for buffer.” from Qpid
broker version 0.32.

This was already discussed here last April and the following issue was
raised:

https://issues.apache.org/jira/browse/QPID-6501

Does anyone knows if this is already fixed for version 0.34? Or will it
be fixed for the next release?


It has not been fixed. Do you have a reliable reproducer? If so that 
always speeds things up.



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



RE: Help -> QPID Proton 12.0 build error!

2016-02-25 Thread Flores, Paul A.
FYI: I am able to successfully compile qpid-proton0.11.1 with absolutely no 
issues /problems.


From: Flores, Paul A. [paul.a.flo...@saic.com]
Sent: Thursday, February 25, 2016 8:29 AM
To: users@qpid.apache.org
Subject: RE: Help -> QPID Proton 12.0 build error!

It is not a compiler directive that is at the root cause of this error message 
as it is persistent.

It is not the gcc compiler version (gcc (GCC) 4.1.2 20080704 (Red Hat 
4.1.2-55)).

When I do a "make -k" I see a large number of warnings, granted most have to do 
with the generation of documents.

The following error repeats and is preventing the build from completing.

/home/pflores/shop/qpid-proton-0.12.0/proton-c/bindings/cpp/include/proton/container.hpp:129:
 error: declaration of ‘void proton::container::link_options(const 
proton::link_options&)’
/home/pflores/shop/qpid-proton-0.12.0/proton-c/bindings/cpp/include/proton/link_options.hpp:60:
 error: changes meaning of ‘link_options’ from ‘class proton::link_options’
make[2]: *** 
[proton-c/bindings/cpp/CMakeFiles/qpid-proton-cpp.dir/src/acceptor.cpp.o] Error 
1

Can any one shed some light on how to resolve this issue or what could be 
related or any other area I should be examining?

Thank you.

Paul

From: TRUFANOW Alexandre [alexandre.trufa...@murex.com]
Sent: Thursday, February 25, 2016 4:08 AM
To: users@qpid.apache.org
Subject: Re: Help -> QPID Proton 12.0 build error!

If you want to disable the c++ binding, you can use the cmake flag
-DBUILD_CPP=FALSE.

Alexandre

On mer., 2016-02-24 at 22:11 +, Robbie Gemmell wrote:
> I'd expected the error message and context (older OS/compiler) being
> the same might make it applicable.
>
> Its building the C++ binding because you have the necessary
> dependencies, and like the other bindings its part of the install
> unless configured otherwise. I know little about cmake or the C++
> binding, so if the other thread can't aid you in getting it building
> I'll have to defer to the folks who do this stuff on how to disable
> it.
>
> Robbie
>
> On 24 February 2016 at 21:55, Flores, Paul A.  wrote:
> > Interesting but not applicable.
> >
> > Looking for a which cmake file may be the culprit in determining that it 
> > needs to make the library in question.  Can someone point me to the 
> > particular cmake that I may need to address?  Looking as I send this out 
> > but cmake process not that "transparent" and have a sprint with a 
> > dependency on demoing the dispatcher.
> >
> > 
> > From: Robbie Gemmell [robbie.gemm...@gmail.com]
> > Sent: Wednesday, February 24, 2016 3:45 PM
> > To: users@qpid.apache.org
> > Subject: Re: Help -> QPID Proton 12.0 build error!
> >
> > There was a recent thread that seems similar, might get some hints from it:
> >
> > http://qpid.2158936.n2.nabble.com/Error-compiling-proton-C-binding-0-12-with-GCC-3-4-td7638637.html
> >
> > Robbie
> >
> > On 24 February 2016 at 20:49, Flores, Paul A.  
> > wrote:
> >> Seeing the following error building during the 'make" of 
> >> qpid-proton-0.12.0.
> >>
> >>
> >>
> >> Assistance or insights would be helpful!
> >>
> >>
> >>
> >> [ 33%] Building CXX object 
> >> proton-c/bindings/cpp/CMakeFiles/qpid-proton-cpp.dir/src/acceptor.cpp.o
> >> /home/pflores/shop/qpid-proton-0.12.0/proton-c/bindings/cpp/include/proton/container.hpp:129:
> >>  error: declaration of ‘void proton::container::link_options(const 
> >> proton::link_options&)’
> >> /home/pflores/shop/qpid-proton-0.12.0/proton-c/bindings/cpp/include/proton/link_options.hpp:60:
> >>  error: changes meaning of ‘link_options’ from ‘class proton::link_options’
> >> make[2]: *** 
> >> [proton-c/bindings/cpp/CMakeFiles/qpid-proton-cpp.dir/src/acceptor.cpp.o] 
> >> Error 1
> >> make[1]: *** [proton-c/bindings/cpp/CMakeFiles/qpid-proton-cpp.dir/all] 
> >> Error 2
> >> make: *** [all] Error 2
> >>
> >> Centos 5.11
> >>
> >> gcc version 4.1.2 20080704 (Red Hat 4.1.2-55)
> >>
> >> x86_64-redhat-linux
> >
> > -
> > 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
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>

***

This e-mail contains information for the intended recipient only. It may 
contain proprietary material or confidential information. If you are not the 
intended recipient you are not authorised to distribute, copy or use this 
e-mail or any 

RE: Help -> QPID Proton 12.0 build error!

2016-02-25 Thread Flores, Paul A.
It is not a compiler directive that is at the root cause of this error message 
as it is persistent.

It is not the gcc compiler version (gcc (GCC) 4.1.2 20080704 (Red Hat 
4.1.2-55)).

When I do a "make -k" I see a large number of warnings, granted most have to do 
with the generation of documents.

The following error repeats and is preventing the build from completing.

/home/pflores/shop/qpid-proton-0.12.0/proton-c/bindings/cpp/include/proton/container.hpp:129:
 error: declaration of ‘void proton::container::link_options(const 
proton::link_options&)’
/home/pflores/shop/qpid-proton-0.12.0/proton-c/bindings/cpp/include/proton/link_options.hpp:60:
 error: changes meaning of ‘link_options’ from ‘class proton::link_options’
make[2]: *** 
[proton-c/bindings/cpp/CMakeFiles/qpid-proton-cpp.dir/src/acceptor.cpp.o] Error 
1

Can any one shed some light on how to resolve this issue or what could be 
related or any other area I should be examining?

Thank you.

Paul

From: TRUFANOW Alexandre [alexandre.trufa...@murex.com]
Sent: Thursday, February 25, 2016 4:08 AM
To: users@qpid.apache.org
Subject: Re: Help -> QPID Proton 12.0 build error!

If you want to disable the c++ binding, you can use the cmake flag
-DBUILD_CPP=FALSE.

Alexandre

On mer., 2016-02-24 at 22:11 +, Robbie Gemmell wrote:
> I'd expected the error message and context (older OS/compiler) being
> the same might make it applicable.
>
> Its building the C++ binding because you have the necessary
> dependencies, and like the other bindings its part of the install
> unless configured otherwise. I know little about cmake or the C++
> binding, so if the other thread can't aid you in getting it building
> I'll have to defer to the folks who do this stuff on how to disable
> it.
>
> Robbie
>
> On 24 February 2016 at 21:55, Flores, Paul A.  wrote:
> > Interesting but not applicable.
> >
> > Looking for a which cmake file may be the culprit in determining that it 
> > needs to make the library in question.  Can someone point me to the 
> > particular cmake that I may need to address?  Looking as I send this out 
> > but cmake process not that "transparent" and have a sprint with a 
> > dependency on demoing the dispatcher.
> >
> > 
> > From: Robbie Gemmell [robbie.gemm...@gmail.com]
> > Sent: Wednesday, February 24, 2016 3:45 PM
> > To: users@qpid.apache.org
> > Subject: Re: Help -> QPID Proton 12.0 build error!
> >
> > There was a recent thread that seems similar, might get some hints from it:
> >
> > http://qpid.2158936.n2.nabble.com/Error-compiling-proton-C-binding-0-12-with-GCC-3-4-td7638637.html
> >
> > Robbie
> >
> > On 24 February 2016 at 20:49, Flores, Paul A.  
> > wrote:
> >> Seeing the following error building during the 'make" of 
> >> qpid-proton-0.12.0.
> >>
> >>
> >>
> >> Assistance or insights would be helpful!
> >>
> >>
> >>
> >> [ 33%] Building CXX object 
> >> proton-c/bindings/cpp/CMakeFiles/qpid-proton-cpp.dir/src/acceptor.cpp.o
> >> /home/pflores/shop/qpid-proton-0.12.0/proton-c/bindings/cpp/include/proton/container.hpp:129:
> >>  error: declaration of ‘void proton::container::link_options(const 
> >> proton::link_options&)’
> >> /home/pflores/shop/qpid-proton-0.12.0/proton-c/bindings/cpp/include/proton/link_options.hpp:60:
> >>  error: changes meaning of ‘link_options’ from ‘class proton::link_options’
> >> make[2]: *** 
> >> [proton-c/bindings/cpp/CMakeFiles/qpid-proton-cpp.dir/src/acceptor.cpp.o] 
> >> Error 1
> >> make[1]: *** [proton-c/bindings/cpp/CMakeFiles/qpid-proton-cpp.dir/all] 
> >> Error 2
> >> make: *** [all] Error 2
> >>
> >> Centos 5.11
> >>
> >> gcc version 4.1.2 20080704 (Red Hat 4.1.2-55)
> >>
> >> x86_64-redhat-linux
> >
> > -
> > 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
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>

***

This e-mail contains information for the intended recipient only. It may 
contain proprietary material or confidential information. If you are not the 
intended recipient you are not authorised to distribute, copy or use this 
e-mail or any attachment to it. Murex cannot guarantee that it is virus free 
and accepts no responsibility for any loss or damage arising from its use. If 
you have received this e-mail in error please notify immediately the sender and 
delete the original email received, any attachments and all copies from your 
system.

[RESULT] [VOTE] Release Qpid Java 6.0.1

2016-02-25 Thread Oleksandr Rudyy
There were 5 binding and 1 non-binding +1 votes, and no other votes
received. The vote has passed.

Voting thread:
http://qpid.2158936.n2.nabble.com/VOTE-Release-Qpid-Java-6-0-1-RC3-td7638867.html

I am going to publish release artifacts into dist release repo and
maven repo. After that I will update web site.

Kind Regards,
Alex


Re: [VOTE] Release Qpid Java 6.0.1 (RC3)

2016-02-25 Thread Oleksandr Rudyy
There were 5 binding and 1 non-binding +1 votes, and no other votes
received. The vote has passed.

Kind Regards,
Alex

On 22 February 2016 at 11:51, Oleksandr Rudyy  wrote:
> Hi everyone,
>
> I created a new 6.0.1 RC3 build containing a fix for a blocker:
>
> QPID-6817 - [Java Broker] On abrupt connection close from client side when
> Broker is delivering messages to consumer, the delivering messages might not
> be released as part of close in some unlucky circumstances
>
> Please test and vote accordingly.
>
> The source and binary bundles are available from:
> https://dist.apache.org/repos/dist/dev/qpid/java/6.0.1-rc3
>
> Maven release artifacts including source and binary bundles are available
> from maven staging repo at:
> https://repository.apache.org/content/repositories/orgapacheqpid-1067
>
> Kind regards,
> Alex

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



Re: [VOTE] Release Qpid Java 6.0.1 (RC3)

2016-02-25 Thread Oleksandr Rudyy
+1

On 22 February 2016 at 11:51, Oleksandr Rudyy  wrote:
> Hi everyone,
>
> I created a new 6.0.1 RC3 build containing a fix for a blocker:
>
> QPID-6817 - [Java Broker] On abrupt connection close from client side when
> Broker is delivering messages to consumer, the delivering messages might not
> be released as part of close in some unlucky circumstances
>
> Please test and vote accordingly.
>
> The source and binary bundles are available from:
> https://dist.apache.org/repos/dist/dev/qpid/java/6.0.1-rc3
>
> Maven release artifacts including source and binary bundles are available
> from maven staging repo at:
> https://repository.apache.org/content/repositories/orgapacheqpid-1067
>
> Kind regards,
> Alex

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



Frame too large for buffer

2016-02-25 Thread Filipe Santos
Hi

I'm experiencing the error "Frame too large for buffer." from Qpid broker 
version 0.32.
This was already discussed here last April and the following issue was raised:
https://issues.apache.org/jira/browse/QPID-6501

Does anyone knows if this is already fixed for version 0.34? Or will it be 
fixed for the next release?

Best regards,
Filipe Santos

[FS]



Re: Help -> QPID Proton 12.0 build error!

2016-02-25 Thread TRUFANOW Alexandre
If you want to disable the c++ binding, you can use the cmake flag
-DBUILD_CPP=FALSE.

Alexandre

On mer., 2016-02-24 at 22:11 +, Robbie Gemmell wrote:
> I'd expected the error message and context (older OS/compiler) being
> the same might make it applicable.
> 
> Its building the C++ binding because you have the necessary
> dependencies, and like the other bindings its part of the install
> unless configured otherwise. I know little about cmake or the C++
> binding, so if the other thread can't aid you in getting it building
> I'll have to defer to the folks who do this stuff on how to disable
> it.
> 
> Robbie
> 
> On 24 February 2016 at 21:55, Flores, Paul A.  wrote:
> > Interesting but not applicable.
> >
> > Looking for a which cmake file may be the culprit in determining that it 
> > needs to make the library in question.  Can someone point me to the 
> > particular cmake that I may need to address?  Looking as I send this out 
> > but cmake process not that "transparent" and have a sprint with a 
> > dependency on demoing the dispatcher.
> >
> > 
> > From: Robbie Gemmell [robbie.gemm...@gmail.com]
> > Sent: Wednesday, February 24, 2016 3:45 PM
> > To: users@qpid.apache.org
> > Subject: Re: Help -> QPID Proton 12.0 build error!
> >
> > There was a recent thread that seems similar, might get some hints from it:
> >
> > http://qpid.2158936.n2.nabble.com/Error-compiling-proton-C-binding-0-12-with-GCC-3-4-td7638637.html
> >
> > Robbie
> >
> > On 24 February 2016 at 20:49, Flores, Paul A.  
> > wrote:
> >> Seeing the following error building during the 'make" of 
> >> qpid-proton-0.12.0.
> >>
> >>
> >>
> >> Assistance or insights would be helpful!
> >>
> >>
> >>
> >> [ 33%] Building CXX object 
> >> proton-c/bindings/cpp/CMakeFiles/qpid-proton-cpp.dir/src/acceptor.cpp.o
> >> /home/pflores/shop/qpid-proton-0.12.0/proton-c/bindings/cpp/include/proton/container.hpp:129:
> >>  error: declaration of ‘void proton::container::link_options(const 
> >> proton::link_options&)’
> >> /home/pflores/shop/qpid-proton-0.12.0/proton-c/bindings/cpp/include/proton/link_options.hpp:60:
> >>  error: changes meaning of ‘link_options’ from ‘class proton::link_options’
> >> make[2]: *** 
> >> [proton-c/bindings/cpp/CMakeFiles/qpid-proton-cpp.dir/src/acceptor.cpp.o] 
> >> Error 1
> >> make[1]: *** [proton-c/bindings/cpp/CMakeFiles/qpid-proton-cpp.dir/all] 
> >> Error 2
> >> make: *** [all] Error 2
> >>
> >> Centos 5.11
> >>
> >> gcc version 4.1.2 20080704 (Red Hat 4.1.2-55)
> >>
> >> x86_64-redhat-linux
> >
> > -
> > 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
> >
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
> 

***

This e-mail contains information for the intended recipient only. It may 
contain proprietary material or confidential information. If you are not the 
intended recipient you are not authorised to distribute, copy or use this 
e-mail or any attachment to it. Murex cannot guarantee that it is virus free 
and accepts no responsibility for any loss or damage arising from its use. If 
you have received this e-mail in error please notify immediately the sender and 
delete the original email received, any attachments and all copies from your 
system.