RE: Proton python message sending

[Steve Huston]

Hi Ted,

Thanks very much for reading that code and responding. Very nice to hear from 
you.

> Have you looked at the Python Proton examples?  There is a server.py in there
> that does pretty much the same thing that you are trying to do here.
> It might be helpful.

It was - I modeled my code on the examples.

> Another possible issue:  You are calling sender.send with "msg_bytes" and not
> a Message object.  I don't know what msg_bytes is, but I think it needs
> a send() method for it to work.   Maybe you meant
> sender.send(Message(body=msg_bytes)).


That was it. Thank you.

Happy New Year,
-Steve


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

Proton python message sending

[Steve Huston]

I am trying to write a python program that can receive a message, form a 
response, and send it back. I am getting errors on sending the response. Can 
someone help me see what I have wrong? The error appears to be -1 with no 
explanation. I'm hoping I just have some misunderstanding of how this is 
supposed to work.

Thank you,
-Steve

The code is:

import logging
 
from proton.handlers import MessagingHandler
from proton.reactor import Container
 
from emp import EMP_msg
from transport_echo_request import TransportEchoRequest
from transport_echo_response import TransportEchoResponse
 
logger = logging.getLogger("ricochet")
 
class Plugin(MessagingHandler):
def __init__(self):
super(Plugin, self).__init__()
 
def setup(self, config):
self.broker = config['broker-url']
self.recv_queue = config['recv-queue']
self.send_queue = config['send-queue']
self.message_to_send = None
 
def on_start(self, event):
conn = event.container.connect(self.broker)
event.container.create_receiver(conn, self.recv_queue)
self.sender = event.container.create_sender(conn, self.send_queue)
logger.info("sender %r", self.sender)
 
def on_message(self, event):
bytes = event.message.body   # Should be transport echo request - 
translate?
transport = 
event.message.properties['TransportUsed'].tobytes().decode("utf-8")
logger.debug("body: %s", bytes.hex())
 
msg = EMP_msg()
ret = msg.decode(bytes)
logger.debug("EMP header decode: %s", ret)
if msg.msg_type_id != 4000 or msg.msg_ver != 1:
logger.error("Received message type %dv%d not supported.", 
msg.msg_type_id, msg.msg_ver)
return
request = TransportEchoRequest()
try:
request.decode(bytes)
request.decode_body()
except Exception as e:
logger.error("Decoding transport echo request: %s", e)
return
self.on_transport_echo_request(request, transport)
self.release(event.delivery)
 
def on_sendable(self, event):
logger.info("Sendable.")
if self.message_to_send:
event.sender.send(self.message_to_send.msg_bytes)
self.message_to_send = None
return super().on_sendable(event)
 
# These are local calls, not framework callbacks as the above are.
def on_transport_echo_request(self, request, transport):
logger.info("transport_echo from %s np %d on %s", request.src_addr, 
request.QoS_net_pref, transport)
response = TransportEchoResponse(transport, request)
response.encode_body()
response.encode()
self.sender.send(response.msg_bytes)
#self.message_to_send = response
#self.sender.offered(1)

When I run this (and the other side that initiates a request) I get:

INFO:ricochet:starting
INFO:ricochet:sender 
INFO:proton:Connecting to Url('amqp://localhost:8000')...
INFO:proton:Connected to localhost
INFO:ricochet:Sendable.
INFO:ricochet:transport_echo from round-trip np 0 on att
Traceback (most recent call last):
  File "/Users/user/rwn/roma/plugins/ricochet/./ricochet.py", line 87, in 

main()
^^
  File "/Users/user/rwn/roma/plugins/ricochet/./ricochet.py", line 83, in main
asyncio.run(ricochet.run())
~~~
  File 
"/usr/local/Cellar/python@3.13/3.13.0_1/Frameworks/Python.framework/Versions/3.13/lib/python3.13/asyncio/runners.py",
 line 194, in run
return runner.run(main)
   ~~^^
  File 
"/usr/local/Cellar/python@3.13/3.13.0_1/Frameworks/Python.framework/Versions/3.13/lib/python3.13/asyncio/runners.py",
 line 118, in run
return self._loop.run_until_complete(task)
   ~^^
  File 
"/usr/local/Cellar/python@3.13/3.13.0_1/Frameworks/Python.framework/Versions/3.13/lib/python3.13/asyncio/base_events.py",
 line 721, in run_until_complete
return future.result()
   ~^^
  File "/Users/user/rwn/roma/plugins/ricochet/./ricochet.py", line 76, in run
await asyncio.to_thread(self.run_in_thread())
~~^^
  File "/Users/user/rwn/roma/plugins/ricochet/./ricochet.py", line 73, in 
run_in_thread
Container(self).run()
~~~^^
  File "/Users/user/rwn/roma/lib/python3.13/site-packages/proton/_reactor.py", 
line 197, in run
while self.process():
  ^^
  File "/Users/user/rwn/roma/lib/python3.13/site-packages/proton/_reactor.py", 
line 260, in process
event.dispatch(handler)
~~^
  File "/Users/user/rwn/roma/lib/python3.13/site-packages/proton/_events.py", 
line 160, in dispatch
self.dispatch(h, type)
~^
  File "/Users/user/rwn/roma/lib/python3.13/site-packages/proton/_events.py", 
line 160, in dispatch
self.dispatch(h, type)
~^
  File "/Users/user/rwn/roma/lib/python

RE: Proton python and asyncio?

[Steve Huston]

Thank you for the reply, Andrew - any help is appreciated. I'll keep 
experimenting and report back here what I find.

-Steve

> -Original Message-
> From: Andrew Stitcher 
> Sent: Wednesday, December 18, 2024 2:01 PM
> To: users@qpid.apache.org
> Subject: Re: Proton python and asyncio?
> 
> I'm sorry to say that I don't have anything useful to add, except to say that 
> I've
> been interested in making proton python asynchio compatible for some time.
> To a first look qpid bow looks like the approach I would have taken, but it
> seems to be based on a very old version of python qpid proton, so this might
> be the reason it doesn't work!
> 
> Hope this is at least a little helpful.
> 
> Andrew
> 
> On Wed, Dec 18, 2024 at 11:00 AM Steve Huston 
> wrote:
> 
> > I am working on a python application that will allow multiple plug-in
> > modules that add different features and ways to request things, all by
> > various network paths. My intention is to drive it with python
> > asyncio, and each plugin piggybacks on that by using asyncio.
> >
> > The first plugin is to use AMQP messaging so I started with proton,
> > which works fabulously when following the examples. However, it
> > doesn't follow the asyncio framework so I'm trying to work that out.
> >
> > I tried qpid-bow
> >
> (https://url.emailprotection.link/?buEq4eyNl9NRYRhKUfm4VcC_Nr0XfomCW
> dB
> > 3DHEYIm0Rlcfa5cNMuNYcdNj3Yy2aCM0eWg62o9a39y3usUNiZ2A~~) that
> claims to
> > integrate the proton reactor with asyncio. I have been unable to get it to
> work past the initial batch of events to connect (or attempt to connect) to a
> broker.
> >
> > My next idea was to run the proton-based plugin's work in another
> > thread and tie that thread's completion into asyncio's loop, leaving
> > proton reactor to run freely. I'm having trouble there too. I added a
> > simple http-based plugin just to have more than one and they both
> > start but as soon as proton gets to so anything, the http plugin never gets 
> > to
> run again.
> >
> > There's still a good chance I have something fundamentally wrong with
> > the way I'm running asyncio, but I'm interested in any advice or
> > experience from people here who have worked with asyncio and proton -
> > should this be able to work?
> >
> > Thanks,
> > -Steve Huston
> >
> > -
> > 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

Proton python and asyncio?

[Steve Huston]

I am working on a python application that will allow multiple plug-in modules 
that add different features and ways to request things, all by various network 
paths. My intention is to drive it with python asyncio, and each plugin 
piggybacks on that by using asyncio.

The first plugin is to use AMQP messaging so I started with proton, which works 
fabulously when following the examples. However, it doesn't follow the asyncio 
framework so I'm trying to work that out.

I tried qpid-bow (https://github.com/Bynder/qpid-bow) that claims to integrate 
the proton reactor with asyncio. I have been unable to get it to work past the 
initial batch of events to connect (or attempt to connect) to a broker.

My next idea was to run the proton-based plugin's work in another thread and 
tie that thread's completion into asyncio's loop, leaving proton reactor to run 
freely. I'm having trouble there too. I added a simple http-based plugin just 
to have more than one and they both start but as soon as proton gets to so 
anything, the http plugin never gets to run again.

There's still a good chance I have something fundamentally wrong with the way 
I'm running asyncio, but I'm interested in any advice or experience from people 
here who have worked with asyncio and proton - should this be able to work?

Thanks,
-Steve Huston

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

Re: Python Proton Binding on Receiver for Broker

[Steve Huston]

Hi Jerome,

You can do that with the Python QMF API. I extracted the below from another 
script so it may need some adjustments but should get you there.
-Steve

import os
import sys

from qpid import * 
import qpid.messaging

host="localhost"
port=5672
sock = util.connect(host, port)
qmf_con = connection.Connection(sock)
qmf_con.start()
session = qmf_con.session(str(qpid.messaging.uuid4()), timeout=30)

session.queue_declare(queue="MyTopic")
session.exchange_bind(queue="MyTopic", exchange="whatever", 
binding_key="jerome.#")
session.sync
session.close(timeout=10)


On 4/28/22, 4:48 PM, "ONeil, Jerome"  wrote:

Hello,

I am trying to set up a receiver for a topic on a qpid C++ broker and need 
to control the binding between the Source exchange and the receiver queue.  I 
can get a simple receiver set up just fine and pull messages from it.

>>> event.container.create_receiver("amqp://localhost/MyTopic")

[jerome@localhost ~]$ qpid-config -r queues
Queue 'debug-MyTopic'
bind [#] => MyTopic


So that's grand.  I need to control the binding with more detail, though, 
and for the life of me I can't figure out how to do it.  I've tried controlling 
on the URL.  I've tried Filters and Selectors.  I have tried a variety of 
different link and receiver properties (x-bindings, etc..) and other methods 
scrapped up from the internet, and all I ever get for that binding is '#'.

Can someone provide a simple example?  Lets say I wanted that binding to 
actually be

bind [jerome.#] => MyTopic

What would that look like?  I am all out of clues and hope someone has one 
to spare.

Best regards,

-Jerome
This email and any attachments are only for use by the intended 
recipient(s) and may contain legally privileged, confidential, proprietary or 
otherwise private information. Any unauthorized use, reproduction, 
dissemination, distribution or other disclosure of the contents of this e-mail 
or its attachments is strictly prohibited. If you have received this email in 
error, please notify the sender immediately and delete the original. Neither 
this information block, the typed name of the sender, nor anything else in this 
message is intended to constitute an electronic signature unless a specific 
statement to the contrary is included in this message.

Re: [DISCUSS] bumping Qpid JMS to 1.0.0 and requiring Java 11+

[Steve Huston]

I agree, Robbie. Good idea. 

Steve Huston
(sent from my iPhone - please excuse brevity and typos)

> On Apr 15, 2021, at 8:16 AM, Robbie Gemmell  wrote:
> 
> Hi folks,
> 
> I would like to propose bumping Qpid JMS up to version 1.0.0+ for
> future releases, and simultaneously require Java 11+ for those new
> releases, leaving further Java 8 support efforts with the existing 0.x
> stream. Barring discussion otherwise I would look to release such a
> combination in May.
> 
> Java 11 has been the current Java LTS release since September 2018,
> and Java 17 will arrive in September to supplant even it. It is over 4
> years since we required Java 8+ usage, which was itself a bit over 2
> years after first requiring Java 7+ usage (in the old JMS client, the
> current one started out on Java 7+). I have seen other projects
> discussing transition to Java 11+ for over a year now, with some since
> having made the change and some being in progress or imminently so. I
> think now is an appropriate time to begin requiring Java 11+.
> 
> On the version number I think the codebase has been stable for several
> years and the API is fixed, so it's probably long overdue that we just
> did it. Other versions numbers are still available if we need them
> later.
> 
> Doing both at the same time would make it simpler/clearer to
> distinguish old and new, simplifying doing future maintenance releases
> for the old 0.x line to support JDK8 users for a further period of
> time, for example if a security issue arises or just to backport some
> important fixes.
> 
> Thoughts?
> 
> Robbie
> 
> -
> 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: Welcome Jiri Danek as an Apache Qpid committer

[Steve Huston]

Congratulations!
Welcome, Jiri!

Steve Huston
(sent from my iPhone - please excuse brevity and typos)

> On Mar 1, 2019, at 5:12 AM, Robbie Gemmell  wrote:
> 
> Welcome, Jiri

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

RE: [NOTICE / DISCUSS] migrating Git repositories to gitbox.apache.org

[Steve Huston]

+1 - thanks for engaging this, Robbie.

> -Original Message-
> From: Robbie Gemmell 
> Sent: Monday, December 10, 2018 11:10 AM
> To: users@qpid.apache.org; d...@qpid.apache.org
> Subject: [NOTICE / DISCUSS] migrating Git repositories to gitbox.apache.org
> 
> Hi Folks,
> 
> Per the below mail sent by the ASF Infrastructure team (to dev@), our Git
> repositories will be migrated from the original/old git-wip-us service on to
> the newer gitbox.apache.org service by February 7th.
> 
> This is definitely happening, but we have some say over when/how it does:
> 1. Document consensus on list and voluntarily request to move by Jan 9th.
> 2. Wait for mandated move between Jan 9th and Feb 6th, coordinate with
> infra
>to proceed once it has been.
> 3. Do nothing, ignore the mandate, and be forcibly moved on Feb 7th.
> 
> I'm in favour of volunteering and doing it sooner than later, so to that end
> here is my lazy consensus statement:
> 
> Unless there is discussion here resulting in decision to delay, I will raise 
> the
> migration request JIRA with Infra on Thursday 13th Dec, hopefully allowing
> completion of the process by the end of this week if they have bandwidth to
> do so.
> 
> Robbie
> 
> On Fri, 7 Dec 2018 at 16:52, Daniel Gruno wrote:
> >
> > [NOTICE] Mandatory relocation of Apache git repositories on
> > git-wip-us.apache.org
> >
> >
> > [IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US
> PLEASE
> >   DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS]
> >
> > Hello Apache projects,
> >
> > I am writing to you because you may have git repositories on the
> > git-wip-us server, which is slated to be decommissioned in the coming
> > months. All repositories will be moved to the new gitbox service which
> > includes direct write access on github as well as the standard ASF
> > commit access via gitbox.apache.org.
> >
> > ## Why this move? ##
> > The move comes as a result of retiring the git-wip service, as the
> > hardware it runs on is longing for retirement. In lieu of this, we
> > have decided to consolidate the two services (git-wip and gitbox), to
> > ease the management of our repository systems and future-proof the
> > underlying hardware. The move is fully automated, and ideally, nothing
> > will change in your workflow other than added features and access to
> > GitHub.
> >
> > ## Timeframe for relocation ##
> > Initially, we are asking that projects voluntarily request to move
> > their repositories to gitbox, hence this email. The voluntary
> > timeframe is between now and January 9th 2019, during which projects
> > are free to either move over to gitbox or stay put on git-wip. After
> > this phase, we will be requiring the remaining projects to move within
> > one month, after which we will move the remaining projects over.
> >
> > To have your project moved in this initial phase, you will need:
> >
> > - Consensus in the project (documented via the mailing list)
> > - File a JIRA ticket with INFRA to voluntarily move your project repos
> >over to gitbox (as stated, this is highly automated and will take
> >between a minute and an hour, depending on the size and number of
> >your repositories)
> >
> > To sum up the preliminary timeline;
> >
> > - December 9th 2018 -> January 9th 2019: Voluntary (coordinated)
> >relocation
> > - January 9th -> February 6th: Mandated (coordinated) relocation
> > - February 7th: All remaining repositories are mass migrated.
> >
> > This timeline may change to accommodate various scenarios.
> >
> > ## Using GitHub with ASF repositories ## When your project has moved,
> > you are free to use either the ASF repository system
> > (gitbox.apache.org) OR GitHub for your development and code pushes. To
> > be able to use GitHub, please follow the primer
> > at: https://reference.apache.org/committer/github
> >
> >
> > We appreciate your understanding of this issue, and hope that your
> > project can coordinate voluntarily moving your repositories in a
> > timely manner.
> >
> > All settings, such as commit mail targets, issue linking, PR
> > notification schemes etc will automatically be migrated to gitbox as
> > well.
> >
> > With regards, Daniel on behalf of ASF Infra.
> >
> > PS:For inquiries, please reply to us...@infra.apache.org, not your
> > project's dev list :-).
> >
> >
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional
> commands, e-mail: users-h...@qpid.apache.org

RE: Welcome Roddie Kieley as an Apache Qpid committer

[Steve Huston]

Congratulations, and welcome, Roddie!

> -Original Message-
> From: Robbie Gemmell 
> Sent: Tuesday, November 27, 2018 9:28 AM
> To: users@qpid.apache.org
> Subject: Welcome Roddie Kieley as an Apache Qpid committer
> 
> The Qpid PMC have voted to grant commit rights to Roddie Kieley in
> recognition of continued contributions to the project.
> 
> Welcome, Roddie!
> 
> Robbie
> 
> -
> 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: Export control classification number for qpid

[Steve Huston]

It is likely to be 5D002 but I have not specifically chased down the license 
exception for it.

http://www.apache.org/licenses/exports/

-Steve

> -Original Message-
> From: DEMIAN, Beatrice (SOPRA STERIA GROUP SA)
> 
> Sent: Monday, October 08, 2018 8:50 AM
> To: users@qpid.apache.org
> Subject: Export control classification number for qpid
> 
> 
> Hi,
> We are using qpid in one of our products, and are now in the process of
> collecting the information needed to export it.
> Can you tell me what the U.S. Export Control Classification Number (ECCN)
> for qpid is, and whether a license exception may be used for it?
> 
> 
> Béatrice Demian
> On behalf of SOPRA STERIA
> Subcontractor for EYYW6 (AIRBUS France)
> 
> The information in this e-mail is confidential. The contents may not be
> disclosed or used by anyone other than the addressee. Access to this e-mail
> by anyone else is unauthorised.
> If you are not the intended recipient, please notify Airbus immediately and
> delete this e-mail.
> Airbus cannot accept any responsibility for the accuracy or completeness of
> this e-mail as it has been sent over public networks. If you have any concerns
> over the content of this message or its Accuracy or Integrity, please contact
> Airbus immediately.
> All outgoing e-mails from Airbus are checked using regularly updated virus
> scanning software but you should take whatever measures you deem to be
> appropriate to ensure that this message and any attachments are virus free.

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

RE: Signing AMQP messages

[Steve Huston]

I recommend signing the message before handing it off for send. You will need 
to decide on where to place the signature and if/where you will place the 
certificate.

Steve Huston

> -Original Message-
> From: Ryan Yeats 
> Sent: Thursday, September 13, 2018 12:33 PM
> To: users@qpid.apache.org
> Subject: Signing AMQP messages
> 
> Hi,
>   I want to sign and receive signed messages so that I can authenticate who
> they originally came from even when they are picked up and resent across
> multiple brokers.  I didn’t see any built-in way to sign messages in the 
> client
> though.  I was thinking I would just add a signature to the message footer
> myself. I can override onSend(long producerTtl) in the
> AmqpJmsMessageFacade and call encodeMessage().array() to get the
> message bytes to create a signature, however the methods to add to the
> footer are package-private so it doesn’t look like I have any place to put the
> signature.  What is the correct way to sign an amqp message?
> 
> Thanks!

RE: HA Cluster using Qpid C++ Broker 1.36.0

[Steve Huston]

I have used the qpid C++ broker in clusters. On RHEL 6. Works very well.

> -Original Message-
> From: andi welchlin [mailto:andi.welch...@gmail.com]
> Sent: Wednesday, November 08, 2017 12:00 PM
> To: users@qpid.apache.org
> Subject: HA Cluster using Qpid C++ Broker 1.36.0
> 
> Hello,
> 
> I would like to configure a HA cluster using the Qpid C++ message broker
> 1.36.0. In the handbook I read that rgmanager is neccessary.
> 
> When I try to install it on Ubuntu 16.04 it is not found. On a Fedora 
> installation
> it is also not found.
> 
> Is anyone here using the Qpid message broker in a cluster?
> 
> Are you using rgmanager or is there some other cluster manager usable on
> Linux?
> 
> Any hints are welcome ... even if you say "noone uses the Qpid broker in a
> cluster".
> 
> Kind Regards,
> Andreas

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

RE: Struggling to undersand Qpid C++ message store

[Steve Huston]

Try:

qpidd --load-module /usr/local/lib/qpid/daemon/linearstore.so

> -Original Message-
> From: Aleksey Vorona [mailto:voron...@gmail.com]
> Sent: Friday, November 03, 2017 6:06 PM
> To: users@qpid.apache.org
> Subject: Struggling to undersand Qpid C++ message store
> 
> Dear all,
> 
> I am trying to configure the C++ broker with a message persistence plugin
> and I can not find the documentation.
> 
> My current problem is that I see `make install` to place a lib at
> /usr/local/lib/qpid/daemon/linearstore.so
> 
> and yet it fails:
> 
> $ qpidd --load-module linearstore.so
> 2017-11-03 15:04:07 [Broker] critical Unexpected error:
> linearstore.so: cannot open shared object file: No such file or
> directory: linearstore.so
> (/media/data/source/qpid-cpp/src/qpid/sys/posix/Shlib.cpp:35)
> 
> I have tried to change the LDPATH but it did not seem to help.
> 
> I feel that I am missing a section in the documentation, as I can not find any
> documentation on configuring message store with the C++ broker.
> 
> Could you help me, please?
> 
> -- Aleksey
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional
> commands, e-mail: users-h...@qpid.apache.org

RE: Routing messages between two brokers

[Steve Huston]

Wonderful - that worked great, Ted - thanks!!!

> -Original Message-
> From: Ted Ross [mailto:tr...@redhat.com]
> Sent: Friday, October 27, 2017 11:31 AM
> To: users@qpid.apache.org
> Subject: Re: Routing messages between two brokers
> 
> Hi Steve,
> 
> Setting up the addresses as waypoints configures the router to properly
> route producers _to_ the broker and consumers _from_ the broker.  Your
> case is a little different.  Try this alternative configuration:
> 
> autoLink {
> addr: to.myapp
> connection: appbroker
> dir: in
> phase: 0
> }
> 
> autoLink {
> addr: to.myapp
> connection: otherbroker
> dir: out
> phase: 0
> }
> 
> autoLink {
> addr: from.myapp
> connection: appbroker
> dir: out
> phase: 0
> }
> 
> autoLink {
> addr: from.myapp
> connection: otherbroker
> dir: in
> phase: 0
> }
> 
> By default, _out_ autolinks take phase-0 to match directly attached
> producers and _in_ autolinks take phase-1 to match directly attached
> consumers.  Identifying the address as "waypoint: yes" causes consumers
> (normally attached listener links) to assume phase-1.
> 
> In your case, there is no multi-phase path (i.e. producer-to-broker; broker-
> to-consumer), so you can dispense with the waypoint addresses and
> explicitly set your autolink phases to 0.
> 
> In case it's not clear:  Dispatch has a notion of "address phase" which is a 
> way
> of dividing a single address into multiple sub-addresses for routing.  If the
> address is for a broker/queue, the routing from producer to broker is
> separate and independent from the routing from broker to consumer.  From
> outside of the router, there appears to be only one address, but in the
> router's forwarding table, there are multiple distinct addresses.
> 
> Let me know if you have any other problems with this.  It should work fine.
> 
> -Ted
> 
> On Thu, Oct 26, 2017 at 6:26 PM, Steve Huston 
> wrote:
> 
> > I am bootstrapping my dispatch router knowledge on a little project
> > driven by the need to feed messages through:
> >
> > - AMQP 0-10 client sends messages to a broker that speaks both 0-10
> > and 1.0
> > - dispatch router takes messages out of that dual-protocol broker and
> > routes them to another broker that speaks only 1.0
> >
> > ... and back the other way, with a different named queue.
> >
> > So here is the qdrouterd.conf pieces for this goal:
> >
> > router {
> > mode: standalone
> > id: Router.A
> > }
> >
> > #Listener for the dispatch-router management connections - qdstat
> > listener {
> > host: 0.0.0.0
> > port: amqp
> > authenticatePeer: no
> > }
> >
> > connector {
> > name: otherbroker
> > host: otherhost
> > port: 5672
> > role: route-container
> > }
> >
> > connector {
> > name: appbroker
> > host: 0.0.0.0
> > port: 10053
> > role: route-container
> > }
> >
> > address {
> > prefix: to.myapp
> > waypoint: yes
> > }
> >
> > autoLink {
> > addr: to.myapp
> > connection: appbroker
> > dir: in
> > }
> > autoLink {
> > addr: to.myapp
> > connection: otherbroker
> > dir: out
> > }
> >
> > address {
> > prefix: from.myapp
> > waypoint: yes
> > }
> >
> > autoLink {
> > addr: from.myapp
> > connection: appbroker
> > dir: out
> > }
> > autoLink {
> > addr: from.myapp
> > connection: otherbroker
> > dir: in
> > }
> >
> >
> > When qdrouterd runs, it appears to set up the connections and links,
> > but no messages are retrieved from 'appbroker' 'to.myapp' - and there
> > are many messages sitting in that queue waiting.
> >
> > Is there something I'm missing to actually get the messages to flow?
> >
> > Thanks,
> > -Steve
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For
> > additional commands, e-mail: users-h...@qpid.apache.org
> >
> >

Routing messages between two brokers

[Steve Huston]

I am bootstrapping my dispatch router knowledge on a little project driven by 
the need to feed messages through:

- AMQP 0-10 client sends messages to a broker that speaks both 0-10 and 1.0
- dispatch router takes messages out of that dual-protocol broker and routes 
them to another broker that speaks only 1.0

... and back the other way, with a different named queue.

So here is the qdrouterd.conf pieces for this goal:

router {
mode: standalone
id: Router.A
}

#Listener for the dispatch-router management connections - qdstat
listener {
host: 0.0.0.0
port: amqp
authenticatePeer: no
}

connector {
name: otherbroker
host: otherhost
port: 5672
role: route-container
}

connector {
name: appbroker
host: 0.0.0.0
port: 10053
role: route-container
}

address {
prefix: to.myapp
waypoint: yes
}

autoLink {
addr: to.myapp
connection: appbroker
dir: in
}
autoLink {
addr: to.myapp
connection: otherbroker
dir: out
}

address {
prefix: from.myapp
waypoint: yes
}

autoLink {
addr: from.myapp
connection: appbroker
dir: out
}
autoLink {
addr: from.myapp
connection: otherbroker
dir: in
}


When qdrouterd runs, it appears to set up the connections and links, but no 
messages are retrieved from 'appbroker' 'to.myapp' - and there are many 
messages sitting in that queue waiting.

Is there something I'm missing to actually get the messages to flow?

Thanks,
-Steve

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

RE: Possible to set source IP address in queue route setup in C++ broker?

[Steve Huston]

Thanks for replying, Gordon - sorry for the confusing terms.

> On 22/08/17 21:22, Steve Huston wrote:
> > I'm using the C++ broker and I am setting up queue pull routes to
> > another broker. I want to be able to have my local broker set a
> > virtual IP address as the IP source address when connecting to the
> > remote broker it will pull from. Is this possible using current broker
> > capabilities?
> 
> I don't understand the question properly. When creating a pull route you
> always have to supply the host/ip that the destination broker will connect to
> in order to pull the messages. If that is a virtual IP, I don't think 
> anything in
> the broker or the qpid-route tool should care?
> 
> I'm probably misunderstanding what you are trying to do though, can you
> elaborate a bit more?

- Host A wants to set up a pull route to pull messages from Host B
- Host A has two IP addresses assigned to it
- When Host A connects to B, can A specify a particular source IP address that 
B will see it as?

The situation is there's a firewall between A and B; only one of A's addresses 
is reachable from outside that firewall. We're trying to prevent having to 
NAT/PAT A's address at the firewall.

Thanks,
-Steve


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

Possible to set source IP address in queue route setup in C++ broker?

[Steve Huston]

I'm using the C++ broker and I am setting up queue pull routes to another 
broker. I want to be able to have my local broker set a virtual IP address as 
the IP source address when connecting to the remote broker it will pull from. 
Is this possible using current broker capabilities?

I tried to force it using qpid-route, but don't see a way. I tried looking 
through the source as well but did not find a way to specify that.

Thanks,
-Steve


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

Re: Welcome Adel Boutros as an Apache Qpid committer

[Steve Huston]

Welcome, Adel!

Steve Huston
(sent from my iPhone - please excuse brevity and typos)

> On Aug 9, 2017, at 6:49 AM, Robbie Gemmell  wrote:
> 
> The Qpid PMC have voted to grant commit rights to Adel Boutros in
> recognition of continued contributions to the project.
> 
> Welcome, Adel!
> 
> -
> 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: Getting involved with Apache Qpid

[Steve Huston]

Hi Ben,

Thank you for introducing yourself and welcome to the Apache Qpid community!

Documentation pro?! Awesome! Can I get you a cup of coffee? ;-)  make yourself 
at home please.

-Steve

> On Jul 18, 2017, at 6:25 PM, Ben Hardesty  wrote:
> 
> Hi all,
> 
> I'm starting to get involved in the Apache Qpid project, so I wanted to
> take a quick moment to introduce myself. My primary interest is the
> Dispatch Router, which I've been using/playing around with for about a year
> now. I have a background in distributed systems, and my specialty is
> documentation - I've been writing docs professionally as a tech writer for
> about 15 years.
> 
> To get started, I've contributed some small updates to the qdmanage,
> qdstat, and qdrouterd man pages (typo fixes, editing for consistency and
> clarity, etc.), and I'll have more to come for the Dispatch Router book and
> qdrouterd.conf man page.
> 
> In the mean time, if anyone has any doc-related questions or thoughts,
> please feel free to reach out. I'm happy to help out as I can with editing,
> advising, and writing. I hang out as bhardesty on the #qpid channel.
> 
> Thanks,
> Ben Hardesty

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

Re: QPID: Connection failed when connecting to remote QPIDD

[Steve Huston]

Everything is the same… except for the version of qpid ;-)

It may be that the Ubuntu version doesn’t support AMQP 1.0 and that’s what 
ActiveMQ is asking for. Qpid is responding with 0-10.

-Steve

> On Jul 12, 2017, at 12:55 PM, Matt Singman  wrote:
> 
> I have a QPID daemon running inside of a Docker container. I have C++ code 
> that should connect to this daemon, and in the past, it was able to, but it 
> suddenly stopped being able to connect when the C++ code was run on the host 
> machine.
> 
> Trying to connect to the daemon on the container from the host throws a 
> qpid::messaging::TransportFailure expection. When I launch qpidd with -t for 
> trace level logging, I see the following each time a connection is attempted:
> 
> 2017-07-12 15:59:33 debug RECV [172.17.0.2:5672-172.17.0.1:37696]: INIT(0-0)
> 2017-07-12 15:59:33 debug SENT [172.17.0.2:5672-172.17.0.1:37696]: INIT(0-10)
> 
> I would guess that this has something to do with the ActiveMQ protocol, but I 
> am not sure.
> 
> I don't think the fault lies with the code, because the exact same code 
> running on the same container as the broker is able to connect to the QPID 
> broker. I know that the daemon is visible from the host machine because curl 
> finds the daemon
> 
> Why can I not connect to the daemon from the host, even though I can from the 
> container that the daemon is running in?
> 
> It may be worth noting that the versions of QPID on the host are different 
> than the container. The host has the latest version on CentOS 7 (1.36.0) 
> while the container has the latest version on Ubuntu 16.04 (0.16).
> 
> Thanks
> 
> Matt

RE: qpid-0.20 Execution exception: resource-locked

[Steve Huston]

Try increasing your reconnect_interval_min to 1.0

> -Original Message-
> From: Bee [mailto:nbe...@hotmail.com]
> Sent: Monday, December 05, 2016 2:42 PM
> To: users@qpid.apache.org
> Subject: qpid-0.20 Execution exception: resource-locked
> 
> Hello, I'm quite new here.  Hopefully, I can get some help for qpid-0.20 I'm
> using at work.
> 
> A few times now, I get this error:
> [Protocol] error Execution exception: resource-locked: Cannot grant
> exclusive access to queue   (qpid/broker/SessionAdapter.cpp:324)
> 
> Please correct me, but my understanding is this is a race condition where
> connection unexpectedly close, broker-client tries to re-initiate the session,
> but the exclusive queue has not been freed yet.
> When this happens, client or broker (I'm not sure) stops trying to establish
> the session again.
> 
> My question is, how can I ensure the session can re-establish again by itself.
> And, how can I reproduce this issue.  I've tried iptables, it seems to 
> reconnect
> as it's supposed to.  I've tried qpid-config del queue, I get msg that queue 
> is
> deleted, but not the same error msg.
> 
> I'm using these options for broker
> reconnect: true
> heartbeat: 1
> tcp_nodelay: true
> reconnect_timeout: 2.0
> reconnect_interval_min: 0.1
> reconnect_interval_max: 2.0
> 
> 
> Any insights will be very appreciated.


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

Re: [Qpid C++ Broker][HA] How to configure the HA-cluster without rgmanager?

[Steve Huston]

I don't think anyone has done the work to manage availability on Windows so I 
don't think you can run a qpid cluster on Windows at this time. 

-Steve

> On Nov 22, 2016, at 10:03 PM, "lei@airlink-software.com" 
>  wrote:
> 
> Thank you for your reply.
> In fact at the end I must use qpid on windows, so maybe I should find a 
> substitute for rgmanager.
> 
> Regards,
> 
> 
> Lei Dai
> 
> From: Steve Huston
> Date: 2016-11-21 21:56
> To: users@qpid.apache.org
> Subject: RE: [Qpid C++ Broker][HA] How to configure the HA-cluster without 
> rgmanager?
> I am not an expert in all cluster things, but the only way I have seen qpid 
> C++ brokers in a cluster is using rgmanager. It takes care of managing the 
> need to move the cluster primary around. It also manages the virtual IP 
> address assigned to the broker cluster - you didn't mention a virtual IP in 
> your question, but you will need it to use rgmanager for qpid HA.
> 
> -Steve
> 
>> -Original Message-
>> From: lei@airlink-software.com [mailto:lei@airlink-software.com]
>> Sent: Sunday, November 20, 2016 4:54 AM
>> To: users 
>> Subject: [Qpid C++ Broker][HA] How to configure the HA-cluster without
>> rgmanager?
>> 
>> Hi,
>> 
>> I'm trying to configure the qpid HA-cluster without rgmanager but it doesn't
>> work.
>> 
>> The version Infos:
>> ---
>> CentOS 7.2
>> qpid-cpp-1.35.0
>> qpid-proton-0.14.0
>> ---
>> 
>> I installed qpid-cpp and qpid-proton in according to the INSTALL.txt with
>> default configurations on 3 CentOS VMs.
>> The IP addresses are: 172.16.28.231, 172.16.28.232, 172.16.23.233.
>> 
>> Started qpid on every VM with command:
>> $qpidd --auth no --ha-cluster yes --ha-brokers-url
>> 172.16.28.231,172.16.28.232,172.16.28.233
>> 
>> But when I use qpid-ha to show the status of the cluster, all nodes are in
>> joining status.
>> It means the nodes didn't connect to each other?
>> 
>> Did I have some mistakes in the configurations or the usage?
>> I read the documents on the qpid site. It says that rgmanager can manage
>> the cluster and set the primary node by calling qpidd-primary script.
>> But I didn't find the qpidd-primary script in my system.
>> Is the rgmanager necessary to use HA-cluster?
>> 
>> Regards,
>> 
>> 
>> Lei Dai
> 
> -
> 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 C++ Broker][HA] How to configure the HA-cluster without rgmanager?

[Steve Huston]

I am not an expert in all cluster things, but the only way I have seen qpid C++ 
brokers in a cluster is using rgmanager. It takes care of managing the need to 
move the cluster primary around. It also manages the virtual IP address 
assigned to the broker cluster - you didn't mention a virtual IP in your 
question, but you will need it to use rgmanager for qpid HA.

-Steve

> -Original Message-
> From: lei@airlink-software.com [mailto:lei@airlink-software.com]
> Sent: Sunday, November 20, 2016 4:54 AM
> To: users 
> Subject: [Qpid C++ Broker][HA] How to configure the HA-cluster without
> rgmanager?
> 
> Hi,
> 
> I'm trying to configure the qpid HA-cluster without rgmanager but it doesn't
> work.
> 
> The version Infos:
> ---
> CentOS 7.2
> qpid-cpp-1.35.0
> qpid-proton-0.14.0
> ---
> 
> I installed qpid-cpp and qpid-proton in according to the INSTALL.txt with
> default configurations on 3 CentOS VMs.
> The IP addresses are: 172.16.28.231, 172.16.28.232, 172.16.23.233.
> 
> Started qpid on every VM with command:
> $qpidd --auth no --ha-cluster yes --ha-brokers-url
> 172.16.28.231,172.16.28.232,172.16.28.233
> 
> But when I use qpid-ha to show the status of the cluster, all nodes are in
> joining status.
> It means the nodes didn't connect to each other?
> 
> Did I have some mistakes in the configurations or the usage?
> I read the documents on the qpid site. It says that rgmanager can manage
> the cluster and set the primary node by calling qpidd-primary script.
> But I didn't find the qpidd-primary script in my system.
> Is the rgmanager necessary to use HA-cluster?
> 
> Regards,
> 
> 
> Lei Dai

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

RE: Proton's road ahead

[Steve Huston]

+1 to Alan's comments.

> -Original Message-
> From: Alan Conway [mailto:acon...@redhat.com]
> Sent: Monday, October 31, 2016 2:51 PM
> To: users@qpid.apache.org
> Subject: Re: Proton's road ahead
> 
> On Mon, 2016-10-31 at 18:26 +, Rob Godfrey wrote:
> > On 31 October 2016 at 17:28, Robbie Gemmell
>  > >
> > wrote:
> >
> > > > I was going to bring up a similar question - do we believe we are
> > > actually
> > > >
> > > > getting benefit from trying to keep the API of Proton-J and
> > > > Proton-C "identical"?  It's been a while since I worked on it, but
> > > > my feelings at the time were that the enforcing of API identity
> > > > (rather than
> > > equivalence)
> > > >
> > > > actually made proton-j much less natural to use and not
> > > > insignificantly more difficult to maintain.  I'd certainly like to
> > > > see something with functional equivalence between C and Java, but
> > > > it seems like we've
> > > actually
> > > >
> > > > fallen far behind on that with the lack of a reactive api.
> > > >
> > >
> > > No, I don't think keeping API 'identical' has given benefit to
> > > warrant some of the less natural cases. That said, I'm not sure its
> > > actually tried as much as it was in the past either, since they have
> > > actually diverged in API in cases already, e.g. SASL handling is
> > > entirely different between them these days (though partly because
> > > proton-c changed and proton-j did not).
> > >
> >
> > :-) Yeah - that was my impression too... My intent here was really to
> > see if we can better restate the goals of Proton-J in particular so
> > that we focus on an equivalence and maybe at the same time then look
> > to keep the two libraries closer in functionality (i.e. not leaving
> > the Java libraries behind because it is a pain in the ass to try to
> > write C code in
> > Java)
> 
> +1. Interop is the most important issue. Keeping things similar to
> lower learning curves is a good thing, but forcing one language into the mold
> of another raises the learning curve, so there's a balance to be struck. I 
> think
> "native X programmer can walk up and use the X binding" should weigh a
> little more than "programmer who used Y binding can immediately use the X
> binding". Both of those are far more important than "it lets us re-use
> automated tests in Python and gloss over writing tests in the binding
> languages."
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional
> commands, e-mail: users-h...@qpid.apache.org

RE: How, from within a C++ application, is it possible to 'examine' and 'manage' a broker?

[Steve Huston]

I believe you can gather all that info using QMF messages to the broker. You 
can probably "translate" the qpid-stat, qpid-tool tools from python into the 
equivalent C++.

> -Original Message-
> From: Flores, Paul A. [mailto:paul.a.flo...@saic.com]
> Sent: Tuesday, October 25, 2016 10:22 AM
> To: users@qpid.apache.org
> Subject: How, from within a C++ application, is it possible to 'examine' and
> 'manage' a broker?
> 
> Hi,
> 
> 
> As the subject line states: "How, from within a C++ application, is it 
> possible
> to 'examine' and 'manage' a broker?"
> 
> 
> The requirements are rather straightforward we would like to be able to
> answer the following questions.:
> 
> 
>  * How many 'clients' (senders and receivers) are 'connected' to a 'broker'?
> 
> 
> 
>  * How many receivers/subscribers are attached/subscribed to a queue/
> topic?
> 
> 
>  * How many senders/publishers are writing/publishing to a queue/topic?
> 
> 
>  >Is it only one or can their be multiple senders/publishers to a
> queue/topic?
> 
> 
>  *When was the last time a message was retrieved from a queue/topic?
> 
> 
>  *How to 'empty/clear' messages from a queue/topic from within a C++
> application?
> 
> 
> As stated earlier we are replacing CORBA messaging with QPID.  To that
> regard the client has a considerable amount of message channel
> 'management' that is 'baked'  into their 'framework'. While the goal is to 
> shift
> away from the CORBA paradigm we are faced with task of identifying.
> developing and implementing 'like' functionality and this is one area we
> would like some 'sage' advice and guidance.
> 
> 
> Thanks
> 
> 
> Paul
> 
> 
> 
> 
> This communication (including any attachments) may contain information
> that is proprietary, confidential or exempt from disclosure. If you are not 
> the
> intended recipient, please note that further dissemination, distribution, use
> or copying of this communication is strictly prohibited. Anyone who received
> this message in error should notify the sender immediately by telephone or
> by return email and delete it from his or her computer.

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

RE: Using QPID behind HTTP proxy

[Steve Huston]

Hi Tobias,

> -Original Message-
> From: rat...@web.de [mailto:rat...@web.de]
> Sent: Thursday, August 25, 2016 8:30 AM
> To: users@qpid.apache.org
> Subject: Using QPID behind HTTP proxy
> 
> Hello,
> in my c++ application several computations are performed on a remote
> server.
> I have implemented this using QPID and everything works fine if a direct
> internet connection is available. However, some of my clients use a HTTP
> proxy to access the internet. Is there any possibility to tell QPID (in the
> c++ version) to use a specific HTTP proxy?

The OASIS AMQP Bindings and Mappings Technical Committee recently approved a 
specification for AMQP over WebSockets 
(http://docs.oasis-open.org/amqp-bindmap/amqp-wsb/v1.0/amqp-wsb-v1.0.html) 
Would that sort of mechanism suit you?

The Qpid Java broker has WebSocket support, I believe. Also, you could look 
into Kaazing's product 
(https://kaazing.com/products/websocket-gateway/editions/)

-Steve Huston


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

Re: Issue when using CMake to install Qpid broker

[Steve Huston]

No I don't think so. 

Steve Huston
(sent from my iPhone - please excuse brevity and typos)

> On Jul 6, 2016, at 3:32 PM, loremIpsum1771  wrote:
> 
> I'm not sure. I just tried deleting the cache from the CMake GUI and I then
> re-ran:  cmake -G "Visual Studio 12 2013"
> C:\Users\I664761\Downloads\qpid-cpp-0.34 but the filepath seems to still be
> the same. I have both Cmake and Boost in my downloads folder and I can't
> move them to program files because I don't have admin access on my computer.
> Could that be causing the problem?
> 
> 
> 
> --
> View this message in context: 
> http://qpid.2158936.n2.nabble.com/Issue-when-using-CMake-to-install-Qpid-broker-tp7646766p7646949.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
> 

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

RE: Issue when using CMake to install Qpid broker

[Steve Huston]

Not Boost... the cmake cache in your qpid build stores that stuff. You can 
either run the cmake gui and delete those variables, or delete the whole cache 
file.

> -Original Message-
> From: loremIpsum1771 [mailto:celij...@gmail.com]
> Sent: Wednesday, July 06, 2016 2:53 PM
> To: users@qpid.apache.org
> Subject: RE: Issue when using CMake to install Qpid broker
> 
> Ok I tried deleting the environment variable for BOOST_ROOT and creating it
> again as it is currently set to C://Downloads/boost_1_61_0 but for
> some reason, whenever I run CMake, I still get the same error with the same
> file path showing up so I'm not really sure what's going on. I also tried 
> running
> set BOOST_ROOT="C:\Users\I664761\Downloads\boost_1_61_0\boost" but
> it doesn't seem to have done anything. Is there some specific way that Boost
> internally stores the root location?
> 
> 
> 
> --
> View this message in context: http://qpid.2158936.n2.nabble.com/Issue-
> when-using-CMake-to-install-Qpid-broker-tp7646766p7646942.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


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

RE: Issue when using CMake to install Qpid broker

[Steve Huston]

The CMake find module for Boost is rather finicky. The BOOST_ROOT env variable 
should be set to the 'root', which is the directory above the one where your 
boost library binaries are. If that doesn't work, try setting BOOST_LIBRARYDIR 
explicitly - that is more direct.

-Steve

> -Original Message-
> From: loremIpsum1771 [mailto:celij...@gmail.com]
> Sent: Wednesday, July 06, 2016 1:56 PM
> To: users@qpid.apache.org
> Subject: Re: Issue when using CMake to install Qpid broker
> 
> Oh ok, it seems that those missing packages are in fact not causing a
> problem. For some reason though, it seems that CMake is able to find only
> some of the Boost libraries, but not others:
> https://gist.github.com/loremIpsum1771/fc1d912bbe5a741325cdd259f7a538
> 37
> 
> I created the BOOST_ROOT environment variable and set it to:
> C:\Users\I664761\Downloads\boost_1_61_0\boost  which is where all of the
> Boost libraries are (e.g. math, log, random) but it seems that CMake isn't
> recognizing the directory. Is this the correct filepath to be using?
> 
> 
> 
> --
> View this message in context: http://qpid.2158936.n2.nabble.com/Issue-
> when-using-CMake-to-install-Qpid-broker-tp7646766p7646940.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


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

FW: [amqp-bindmap-comment] Public Review for AMQP WebSocket Binding V1.0 - ends June 6th

[Steve Huston]

Qpid users… please be advised of the following related public review of the 
AMQP WebSocket binding from OASIS.

Please submit any comments on the document as directed in the below 
announcement. Please do not submit them here – the OASIS TC needs to track and 
properly respond to each comment and following the announced procedure helps us 
to do that.

Thank you,
Steve Huston, Chair
OASIS AMQP Bindings and Mappings TC


From: amqp-bindmap-comm...@lists.oasis-open.org 
[mailto:amqp-bindmap-comm...@lists.oasis-open.org] On Behalf Of Chet Ensign
Sent: Friday, May 20, 2016 4:27 PM
To: tc-annou...@lists.oasis-open.org; memb...@lists.oasis-open.org; 
amqp-bind...@lists.oasis-open.org; amqp-bindmap-comm...@lists.oasis-open.org
Subject: [amqp-bindmap-comment] Public Review for AMQP WebSocket Binding V1.0 - 
ends June 6th


OASIS members and other interested parties,

The OASIS Advanced Message Queuing Protocol (AMQP) Bindings and Mappings 
(AMQP-BINDMAP) TC members [1] have produced an updated Committee Specification 
Draft (CSD) and submitted this specification for 15-day public review:

Advanced Message Queuing Protocol (AMQP) WebSocket Binding (WSB) Version 1.0
Committee Specification Draft 02 / Public Review Draft 02
19 April 2016

Specification Overview:

This specification describes how the WebSocket protocol can be used as a 
transport for AMQP 1.0 protocol traffic. It is applicable for two main 
scenarios:

- Firewall traversal. Since WebSocket connection establishment is implemented 
as standard HTTP traffic using the default ports (80 and 443), it is often able 
to pass through network security devices without requiring special 
configuration or opening of additional ports. When WebSocket is used as a 
transport for AMQP 1.0 protocol traffic, this enables communication between 
arbitrary AMQP peers such as an application using an AMQP client library and an 
AMQP message broker, separated by a firewall.

- Browser-based messaging. HTML5 compatible Web browsers have built-in support 
for the WebSocket protocol, thereby enabling a broad range of browser-based 
AMQP messaging scenarios.

About the TC:

The purpose of the AMQP Bindings and Mappings (AMQP-BINDMAP) TC is to define 
bindings of AMQP 1.0 core protocol to underlying transports other than TCP, to 
define mappings of the AMQP 1.0 core protocol to existing well-known 
programming APIs, and to define representations of the AMQP 1.0 message format 
in existing well-known languages.

Public Review Period:

The public review starts 23 May 2016 at 00:00 UTC and ends 06 June 2016 at 
11:59 UTC. The specification was previously submitted for public review [2]. 
This 15-day review is limited in scope to changes made from the previous 
review. Changes are highlighted in the included red-lined DIFF file [3].

This is an open invitation to comment. OASIS solicits feedback from potential 
users, developers and others, whether OASIS members or not, for the sake of 
improving the interoperability and quality of its technical work.

Reviewers may provide comments directly from the comment-tag version of 
document. The file

amqp-wsb-v1.0-csprd02-COMMENT-TAGS.html

contains the HTML version of the draft with a “[comment?]” link next to each 
section heading. Clicking on this link will launch your email application and 
begin a message to 
amqp-bindmap-comm...@lists.oasis-open.org<mailto:amqp-bindmap-comm...@lists.oasis-open.org>
 with the specific section number and title in the subject line. Simply enter 
your comment and click send.

Note that you must be subscribed to the comment mailing list before sending 
feedback. Instructions on how to subscribe can be found at 
https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=amqp-bindmap.

URIs:
The prose specification document and related files are available here:

PDF (Authoritative):
http://docs.oasis-open.org/amqp-bindmap/amqp-wsb/v1.0/csprd02/amqp-wsb-v1.0-csprd02.pdf

HTML:
http://docs.oasis-open.org/amqp-bindmap/amqp-wsb/v1.0/csprd02/amqp-wsb-v1.0-csprd02.html

HTML with in-line comment tags:
http://docs.oasis-open.org/amqp-bindmap/amqp-wsb/v1.0/csprd02/amqp-wsb-v1.0-csprd02-COMMENT-TAGS.html

Editable source:
http://docs.oasis-open.org/amqp-bindmap/amqp-wsb/v1.0/csprd02/amqp-wsb-v1.0-csprd02.doc

ZIP distribution files (complete):

For your convenience, OASIS provides a complete package of the prose 
specification and related files in a ZIP distribution file. You can download 
the ZIP file here:

http://docs.oasis-open.org/amqp-bindmap/amqp-wsb/v1.0/csprd02/amqp-wsb-v1.0-csprd02.zip

Additional information about this specification and the AMQP-BINDMAP TC may be 
found on the TC's public home page located at:

http://www.oasis-open.org/committees/amqp-bindmap/

Comments may be submitted to the TC by any person through the use of the OASIS 
TC Comment Facility which can be accessed via the button labeled "Send A 
Comment" at the top of the TC public home page, or directly 

RE: Messages in qpid.management exchange

[Steve Huston]

They are for management messages. They only exist in memory, never in the file 
system.

> -Original Message-
> From: rammohan ganapavarapu [mailto:rammohanga...@gmail.com]
> Sent: Wednesday, May 04, 2016 3:03 PM
> To: users 
> Subject: Re: Messages in qpid.management exchange
> 
> Thank you Steve, do you know what are those exchanges for? when it say
> drop those messages are still in file system so will file system grows as 
> those
> msg count grow?
> 
> On Wed, May 4, 2016 at 11:59 AM, Steve Huston 
> wrote:
> 
> > The message counts you see for qpid.management are "drops" - they were
> > not routed to a queue (no topic matches on any of its bindings). They
> > are not held in memory. Exchanges route messages, they do not queue
> them.
> >
> > So there's no resource issue with those numbers.
> >
> > -Steve Huston
> >
> > > -Original Message-
> > > From: rammohan ganapavarapu [mailto:rammohanga...@gmail.com]
> > > Sent: Wednesday, May 04, 2016 2:56 PM
> > > To: users 
> > > Subject: Re: Messages in qpid.management exchange
> > >
> > > One more thing to add, does it impact qpid performance?
> > >
> > > Ram
> > >
> > > On Wed, May 4, 2016 at 11:41 AM, rammohan ganapavarapu <
> > > rammohanga...@gmail.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > Do you know what are these messages in these exchanges and why
> > > > they didn't get consumed and will it cause any issue if those msg
> > > > number grow if so how to resolve that issue? restarting qpidd may
> > > > clear those messages but wanted to know if we can configure to set
> > > > threshold and
> > > clear them automatically.
> > > >
> > > >
> > > > qpid-stat -e
> > > >
> > > > Exchanges
> > > >   exchange  type dur  bind  msgIn  msgOut  msgDrop
> > > > byteIn  byteOut  byteDrop
> > > >   qmf.default.directdirect   2  28.9m  28.9m  0
> > > > 272g272g   0
> > > >   amq.topic topicY   0 0  0   0
> > > > 0   00
> > > >   qpid.management   topic6  75.6m 075.6m
> > > > 144g  0  144g
> > > >
> > > > Thanks,
> > > > Ram
> > > >
> >

RE: Messages in qpid.management exchange

[Steve Huston]

The message counts you see for qpid.management are "drops" - they were not 
routed to a queue (no topic matches on any of its bindings). They are not held 
in memory. Exchanges route messages, they do not queue them.

So there's no resource issue with those numbers.

-Steve Huston

> -Original Message-
> From: rammohan ganapavarapu [mailto:rammohanga...@gmail.com]
> Sent: Wednesday, May 04, 2016 2:56 PM
> To: users 
> Subject: Re: Messages in qpid.management exchange
> 
> One more thing to add, does it impact qpid performance?
> 
> Ram
> 
> On Wed, May 4, 2016 at 11:41 AM, rammohan ganapavarapu <
> rammohanga...@gmail.com> wrote:
> 
> > Hi,
> >
> > Do you know what are these messages in these exchanges and why they
> > didn't get consumed and will it cause any issue if those msg number
> > grow if so how to resolve that issue? restarting qpidd may clear those
> > messages but wanted to know if we can configure to set threshold and
> clear them automatically.
> >
> >
> > qpid-stat -e
> >
> > Exchanges
> >   exchange  type dur  bind  msgIn  msgOut  msgDrop
> > byteIn  byteOut  byteDrop
> >   qmf.default.directdirect   2  28.9m  28.9m  0
> > 272g272g   0
> >   amq.topic topicY   0 0  0   0
> > 0   00
> >   qpid.management   topic6  75.6m 075.6m
> > 144g  0  144g
> >
> > Thanks,
> > Ram
> >

RE: [VOTE] Migrate Qpid C++ and Qpid Python to Git

[Steve Huston]

+1

> -Original Message-
> From: Justin Ross [mailto:justin.r...@gmail.com]
> Sent: Tuesday, April 26, 2016 10:40 AM
> To: users@qpid.apache.org
> Subject: [VOTE] Migrate Qpid C++ and Qpid Python to Git
> 
> As proposed and discussed at the following links:
> 
> 
> http://qpid.2158936.n2.nabble.com/Qpid-source-code-reorg-update-
> tt7641526.html
> 
> http://qpid.2158936.n2.nabble.com/Qpid-Subversion-reorganization-
> proposal-tt7639094.html
>   https://github.com/ssorj/qpid-svn-reorg
>   https://issues.apache.org/jira/browse/QPID-7207
> 
> If you favor the migration of Qpid C++ and Qpid Python to Git, vote +1.  If 
> you
> oppose it, vote -1.

RE: [VOTE] move the website bits to a Git repo

[Steve Huston]

+1

> -Original Message-
> From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com]
> Sent: Tuesday, April 19, 2016 8:03 PM
> To: users@qpid.apache.org
> Subject: [VOTE] move the website bits to a Git repo
> 
> Hi folks,
> 
> Short version:
> As per the title, I'd like to vote on moving the website bits to a Git repo,
> specifically "qpid-site".
> 
> Further info:
> The site is one of the single largest groups of stuff we have, both with 
> regard
> to its previous release content and for the additions of various new releases
> as they occur. That's in terms of both overall file size and especially the
> overall number of files. On the latter point, this makes using Subversion
> particularly slow; for example it took well over 30mins just to check in the
> website updates I made yesterday. I literally had to leave and come back
> later because it took so long.
> 
> Support for Git based sites have been offered by infra for some time now
> [1]. Things work in essentially the same manner to our current Subversion
> based site, whereby upon checkin the 'content' bits then get published to
> the web servers. The only real difference is that the site stuff must exist in
> the 'asf-site' branch of a particular git repo, either the same one as general
> code or just a dedicated separate repo. In our case a dedicated repo seems
> to makes the most sense, and again it seems to be what various other
> projects do (even the otherwise single-repo projects).
> 
> [1] https://blogs.apache.org/infra/entry/git_based_websites_available
> 
> Robbie
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional
> commands, e-mail: users-h...@qpid.apache.org

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

[Steve Huston]

It would be great if you can raise a JIRA and attach your patch against the 
current trunk/head/master.

Thanks,
-Steve

> -Original Message-
> From: Adel Boutros [mailto:adelbout...@live.com]
> Sent: Thursday, April 07, 2016 4:01 AM
> To: users@qpid.apache.org
> Subject: RE: Incompatible code with NSS when buidling Qpid C++ Broker
> 
> Hello Steve,
> I am willing to help close this issue as I am currently compiling on SunOS.
> What do you need me to do?
> As I mentioned before, applying the proposed patch works (It fixes the
> compilation issue raised but of course there are other issues I am facing
> now).But, I couldn't find any jira issue with the patch attached.
> Regards,Adel Boutros,www.murex.com
> 
> > From: shus...@riverace.com
> > To: users@qpid.apache.org
> > Subject: RE: Incompatible code with NSS when buidling Qpid C++ Broker
> > Date: Wed, 6 Apr 2016 23:11:35 +
> >
> > 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
> >
> 

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

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: Qpid C++ Broker 0.34 failing unit tests on Windows with Visual Studio 2013 Win64

[Steve Huston]

The test is failing because the test script looks through the log for errors 
and flags the SSL error. It isn't perfect and should be worked on, but at this 
point in time you can safely ignore that particular error.

-Steve

> -Original Message-
> From: Adel Boutros [mailto:adelbout...@live.com]
> Sent: Monday, April 04, 2016 12:06 PM
> To: users@qpid.apache.org
> Subject: RE: Qpid C++ Broker 0.34 failing unit tests on Windows with Visual
> Studio 2013 Win64
> 
> Hello Steve,
> This is the full output given. If what you are saying is correct, then I don't
> understand why the test is failing.
> Do you think there is an easy way to find out? Do you need some extra
> information?
> Regards,Adel
> 
> > From: shus...@riverace.com
> > To: users@qpid.apache.org
> > Subject: RE: Qpid C++ Broker 0.34 failing unit tests on Windows with
> > Visual Studio 2013 Win64
> > Date: Mon, 4 Apr 2016 15:47:16 +
> >
> > Hi Adel,
> >
> > Those messages are expected unless you set up a certificate, and do not
> indicate a failure of the actual test.
> >
> > -Steve
> >
> > > -Original Message-
> > > From: Adel Boutros [mailto:adelbout...@live.com]
> > > Sent: Sunday, April 03, 2016 2:15 PM
> > > To: users@qpid.apache.org
> > > Subject: RE: Qpid C++ Broker 0.34 failing unit tests on Windows with
> > > Visual Studio 2013 Win64
> > >
> > > Hello,
> > > Did anyone have the time to check the below?
> > > Regards,Adel
> > >
> > > From: adelbout...@live.com
> > > To: users@qpid.apache.org
> > > Subject: Qpid C++ Broker 0.34 failing unit tests on Windows with
> > > Visual Studio
> > > 2013 Win64
> > > Date: Wed, 30 Mar 2016 19:19:07 +0200
> > >
> > >
> > >
> > >
> > > Hello,
> > > I have compiled Qpid C++ broker 0.34 with Boost 1.55.0 and Qpid
> > > Proton
> > > 0.12.0 using Visual Studio 2013 Win64 compiler.
> > > The compilation is successful however all unit tests are failing
> > > with the same exception which is related to certificates and SASL
> > > despite the fact that when running a configure with cmake, it didn't
> locate SASL libraries.
> > > Please note that the same tests are running correctly on Linux using
> > > gcc 4.9 Can you please assist?
> > > Full log of cmake and the test are attached to this mail ctest -R
> > > qpid-client- test -V2: 2016-03-30 19:02:17 [Broker] notice Broker
> (pid=60712) start-up2:
> > > 2016-03-30 19:02:17 [Broker] notice SASL disabled: No Authentication
> > > Performed2: 2016-03-30 19:02:17 [Security] error Failed to
> > > initialise SSL
> > > listener: Locating certificate green-win-slave in store My Cannot
> > > find object or property.
> > > (D:\qpid.git\qpid\cpp\src\qpid\broker\windows\SslProtocolFactory.cpp
> > > :184)
> > > 2: 2016-03-30 19:02:17 [Network] notice Listening on TCP/TCP6 port
> 539832:
> > > 2016-03-30 19:02:17 [Security] warning SASL: No Authentication
> Performed2:
> > > 2016-03-30 19:02:17 [Broker] notice Broker (pid=60712) shut-down2:
> > > WARNING: suspicious log entries in
> > > D:\qpid.git\qpid\cpp\build_dir\src\tests\\qpid-client-test-
> > > qpidd.log:\nD:\qpid.git\qpid\cpp\build_dir\src\tests\qpid-client-tes
> > > t-
> > > qpidd.log:3:2016-03-30 18:57:53 [Security] error Failed to initialise SSL
> listener:
> > > Locating certificate green-win-slave in store My Cannot find object
> > > or property.
> > > (D:\qpid.git\qpid\cpp\src\qpid\broker\windows\SslProtocolFactory.cpp
> > > :184)
> > > D:\qpid.git\qpid\cpp\build_dir\src\tests\qpid-client-test-qpidd.log:
> > > 5:2016-
> > > 03-30 18:57:53 [Security] warning SASL: No Authentication Performed
> > > D:\qpid.git\qpid\cpp\build_dir\src\tests\qpid-client-test-qpidd.log:
> > > 9:2016-
> > > 03-30 19:02:17 [Security] error Failed to initialise SSL listener:
> > > Locating certificate green-win-slave in store My Cannot find object or
> property.
> > > (D:\qpid.git\qpid\cpp\src\qpid\broker\windows\SslProtocolFactory.cpp
> > > :184)
> > > D:\qpid.git\qpid\cpp\build_dir\src\tests\qpid-client-test-qpidd.log:
> > > 11:2016-
> > > 03-30 19:02:17 [Security] warning SASL: No Authentication Performed
> > > Regards, Adel Boutroswww.murex.com
> > >
> > > 
> > > - 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

RE: Qpid C++ Broker 0.34 failing unit tests on Windows with Visual Studio 2013 Win64

[Steve Huston]

Hi Adel,

Those messages are expected unless you set up a certificate, and do not 
indicate a failure of the actual test.

-Steve

> -Original Message-
> From: Adel Boutros [mailto:adelbout...@live.com]
> Sent: Sunday, April 03, 2016 2:15 PM
> To: users@qpid.apache.org
> Subject: RE: Qpid C++ Broker 0.34 failing unit tests on Windows with Visual
> Studio 2013 Win64
> 
> Hello,
> Did anyone have the time to check the below?
> Regards,Adel
> 
> From: adelbout...@live.com
> To: users@qpid.apache.org
> Subject: Qpid C++ Broker 0.34 failing unit tests on Windows with Visual Studio
> 2013 Win64
> Date: Wed, 30 Mar 2016 19:19:07 +0200
> 
> 
> 
> 
> Hello,
> I have compiled Qpid C++ broker 0.34 with Boost 1.55.0 and Qpid Proton
> 0.12.0 using Visual Studio 2013 Win64 compiler.
> The compilation is successful however all unit tests are failing with the same
> exception which is related to certificates and SASL despite the fact that when
> running a configure with cmake, it didn't locate SASL libraries.
> Please note that the same tests are running correctly on Linux using gcc 4.9
> Can you please assist?
> Full log of cmake and the test are attached to this mail ctest -R qpid-client-
> test -V2: 2016-03-30 19:02:17 [Broker] notice Broker (pid=60712) start-up2:
> 2016-03-30 19:02:17 [Broker] notice SASL disabled: No Authentication
> Performed2: 2016-03-30 19:02:17 [Security] error Failed to initialise SSL
> listener: Locating certificate green-win-slave in store My Cannot find object
> or property.
> (D:\qpid.git\qpid\cpp\src\qpid\broker\windows\SslProtocolFactory.cpp:184)
> 2: 2016-03-30 19:02:17 [Network] notice Listening on TCP/TCP6 port 539832:
> 2016-03-30 19:02:17 [Security] warning SASL: No Authentication Performed2:
> 2016-03-30 19:02:17 [Broker] notice Broker (pid=60712) shut-down2:
> WARNING: suspicious log entries in
> D:\qpid.git\qpid\cpp\build_dir\src\tests\\qpid-client-test-
> qpidd.log:\nD:\qpid.git\qpid\cpp\build_dir\src\tests\qpid-client-test-
> qpidd.log:3:2016-03-30 18:57:53 [Security] error Failed to initialise SSL 
> listener:
> Locating certificate green-win-slave in store My Cannot find object or
> property.
> (D:\qpid.git\qpid\cpp\src\qpid\broker\windows\SslProtocolFactory.cpp:184)
> D:\qpid.git\qpid\cpp\build_dir\src\tests\qpid-client-test-qpidd.log:5:2016-
> 03-30 18:57:53 [Security] warning SASL: No Authentication Performed
> D:\qpid.git\qpid\cpp\build_dir\src\tests\qpid-client-test-qpidd.log:9:2016-
> 03-30 19:02:17 [Security] error Failed to initialise SSL listener: Locating
> certificate green-win-slave in store My Cannot find object or property.
> (D:\qpid.git\qpid\cpp\src\qpid\broker\windows\SslProtocolFactory.cpp:184)
> D:\qpid.git\qpid\cpp\build_dir\src\tests\qpid-client-test-qpidd.log:11:2016-
> 03-30 19:02:17 [Security] warning SASL: No Authentication Performed
> Regards,
> Adel Boutroswww.murex.com
> 
> -
> 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: SSL maximum message size?

[Steve Huston]

I haven't tried this, but the documentation suggests you can set it:
http://qpid.apache.org/releases/qpid-0.32/messaging-api/cpp/api/classqpid_1_1messaging_1_1Connection.html#aed260d368e7a61444bd20536dd8ee0a8

I don't know which API you are using, but the above may help you.

> -Original Message-
> From: rat...@web.de [mailto:rat...@web.de]
> Sent: Thursday, March 31, 2016 5:29 PM
> To: users@qpid.apache.org
> Subject: RE: SSL maximum message size?
> 
> Yes, fixing the bug would of course make the most sense.
> Just one more question: In a comment on
> https://issues.apache.org/jira/browse/QPID-2410 you wrote "In a debugger
> session I forced the AMQP tune max frame size to 16K and things went
> swimmingly from there."
> Maybe I could first try if this solves my issue. Where would I change this?
> In the source code of qpid or in the broker configuration?
> Thx
> 
> 
> 
> --
> View this message in context: http://qpid.2158936.n2.nabble.com/SSL-
> maximum-message-size-tp7641114p7641156.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


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

RE: SSL maximum message size?

[Steve Huston]

Offhand, your options at this point are:

- Fix the bug (most long-term benefit)
- Write an alternative SSL handling mechanism (more difficult)
- Split them and reassemble at the other end. I don't know anything about your 
system so don't know how hard this would be. I've seen a system that does 
something similar. It's more complexity, probably more than fixing the problem.

I recommend fixing it... it's the most direct, and beneficial option. In the 
long run it's going to help you much more.

-Steve

> -Original Message-
> From: rat...@web.de [mailto:rat...@web.de]
> Sent: Thursday, March 31, 2016 4:49 PM
> To: users@qpid.apache.org
> Subject: RE: SSL maximum message size?
> 
> Hm, this is really getting me into trouble because I need to send encrypted
> messages of larger sizes than 16k. Is there really no other option, e.g. to 
> link
> qpid with alternative SSL implementations like OpenSSL or NSS? Could I split
> up messages into smaller parts and send somehow guarantee that they are
> received by the same server and put them together manually?
> Any hint would help me.
> Thx!
> 
> 
> 
> --
> View this message in context: http://qpid.2158936.n2.nabble.com/SSL-
> maximum-message-size-tp7641114p7641154.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


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

RE: SSL maximum message size?

[Steve Huston]

That's the one... there is no workaround at this time, but Cliff's recent 
analysis provides a way forward for someone to work on.

> -Original Message-
> From: rat...@web.de [mailto:rat...@web.de]
> Sent: Thursday, March 31, 2016 3:35 PM
> To: users@qpid.apache.org
> Subject: Re: SSL maximum message size?
> 
> Sure, I'll do that asap. Meanwhile, I found a bug report that seems to be very
> related (its from 2010 but appearantly still unfixed)
> https://issues.apache.org/jira/browse/QPID-2410
> Even the 16K message size seems to be consistent with my tests. I did not
> fully understand the comments in the bug report. Is there some kind of
> workaround?
> Thank you
> 
> 
> 
> --
> View this message in context: http://qpid.2158936.n2.nabble.com/SSL-
> maximum-message-size-tp7641114p7641150.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


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

RE: SSL maximum message size?

[Steve Huston]

And which OS is the C++ part on? There was discussion of a buffer overrun on 
Windows w/ SSL a short while back.

> -Original Message-
> From: Rob Godfrey [mailto:rob.j.godf...@gmail.com]
> Sent: Thursday, March 31, 2016 11:42 AM
> To: users@qpid.apache.org
> Subject: Re: SSL maximum message size?
> 
> That sounds like a bug - can you confirm which version of the AMQP protocol
> you are using (0-10 or 1.0)?
> 
> Thanks,
> Rob
> 
> On 31 March 2016 at 16:38, rat...@web.de  wrote:
> 
> > By the way, I'm using the Java Broker version 6.0.1 together with the
> > qpid
> > c++ messaging api.
> >
> >
> >
> > --
> > View this message in context:
> > http://qpid.2158936.n2.nabble.com/SSL-maximum-message-size-
> tp7641114p7
> > 641115.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
> >
> >

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

RE: QPID CPP 0.34: Interop Test Failure?

[Steve Huston]

The tests try to pick an unused port, so 52652 is reasonable.

> -Original Message-
> From: Flores, Paul A. [mailto:paul.a.flo...@saic.com]
> Sent: Tuesday, March 08, 2016 11:27 AM
> To: users@qpid.apache.org
> Subject: RE: QPID CPP 0.34: Interop Test Failure?
> 
> Is the URL incorrect in this particular test?
> 
> ConnectError: Connect failed to amqp:tcp:127.0.0.1:52652: Reconnect
> disabled
> 
> Shouldn't the port be 5672 and not 52652?
> 
> 
> From: Gordon Sim [g...@redhat.com]
> Sent: Tuesday, March 08, 2016 10:22 AM
> To: users@qpid.apache.org
> Subject: Re: QPID CPP 0.34: Interop Test Failure?
> 
> On 08/03/16 15:43, Justin Ross wrote:
> > It means one of the tests defined here is failing:
> >
> >
> > https://github.com/apache/qpid/blob/trunk/qpid/cpp/src/tests/interop_t
> > ests.py
> >
> > You should first determine which one is failing.  Use the following
> > command to run the test verbosely:
> >
> >ctest -R '^interop_tests$' -VV
> >
> > And then see what it says.
> 
> You can also look under Testing/Temporary/LastTest.log under the build
> directory for a log of all the tests lasts run, which should have details of 
> the
> failing tests.
> 
> 
> -
> 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

RE: Welcome Ganesh Murthy as an Apache Qpid committer

[Steve Huston]

Congratulations, Ganeth! Welcome!

> -Original Message-
> From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com]
> Sent: Tuesday, March 01, 2016 12:30 PM
> To: users@qpid.apache.org
> Subject: Welcome Ganesh Murthy as an Apache Qpid committer
> 
> The Qpid PMC have voted to grant commit rights to Ganesh Murthy in
> recognition of his contributions to the project.
> 
> Welcome, Ganesh!
> 
> 
> Robbie
> 
> -
> 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?

[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

RE: QPID C++ broker and Java - One broker to "rule them all"

[Steve Huston]

Hi Paul,

> -Original Message-
> From: Flores, Paul A. [mailto:paul.a.flo...@saic.com]
> Sent: Tuesday, February 16, 2016 4:26 PM
> To: users@qpid.apache.org
> Subject: RE: QPID C++ broker and Java - One broker to "rule them all"
> 
> Steve,
> 
> The compatibility table is what drew me to posting my original question.

Ah, ok... did not realize that.

> We are using the QPID Messaging API which notable does not list Java
> language support.

Right.

> Brokers appear to be language dependent implementations.

Ah, I see the confusion the brokers have an overlapping but not equivalent 
set of features but it doesn't matter what programming language you use to 
access either one - it just matters which AMQP version(s) you want to use.

> In passing the
> C++ Broker documentation mentions in a one liner that it will work with JMS
> but no further details are provided.

Ok - it will. There's nothing C++-ish about the C++ broker's interface to 
clients. It works fine with JMS clients. In particular, if you want to avoid 
AMQP 1.0 you should stick with the older JMS API - it can talk AMQP 0-10 to the 
C++ broker.

> We have looked at Proton but are not convinced it will fit into an existing
> framework without some really extensive changes to a CORBA like
> framework, hence the hesitation.

Ok.

> Which brings me to this question.  Is there an example of QPID JMS utilizing
> the C++ Broker (qpidd)?

I'm using it in a project now for a customer... (Camel -> JMS -> C++ broker)

The examples hanging off http://qpid.apache.org/components/jms/amqp-0-x.html 
should be a good start for you.

-Steve

> 
> From: Steve Huston [shus...@riverace.com]
> Sent: Tuesday, February 16, 2016 3:07 PM
> To: users@qpid.apache.org
> Subject: RE: QPID  C++ broker and Java - One broker to "rule them all"
> 
> There's a compatibility matrix on the page:
> http://qpid.apache.org/components/index.html
> If that doesn't contain all the info you need to help decide, try asking 
> again - I
> may not understand the problem.
> 
> -Steve
> 
> > -Original Message-
> > From: Flores, Paul A. [mailto:paul.a.flo...@saic.com]
> > Sent: Tuesday, February 16, 2016 1:29 PM
> > To: users@qpid.apache.org
> > Subject: RE: QPID C++ broker and Java - One broker to "rule them all"
> >
> > Per Steve's advice:
> >
> > Environment:
> > Centos 5.11 (moving soon to 7)
> > C++: gcc 4.1.2
> > Java: 1.7.0_95
> >
> > QPID Messaging API: qpid-cpp-0.34
> > C++ Broker
> > 
> > From: Steve Huston [shus...@riverace.com]
> > Sent: Tuesday, February 16, 2016 12:13 PM
> > To: users@qpid.apache.org
> > Subject: RE: QPID  C++ broker and Java - One broker to "rule them all"
> >
> > As long as the front end, back end, and broker can speak the same AMQP
> > version, they should all play nice regardless of the programming language.
> >
> > If you can be a little more specific about the client code versions,
> > it's highly likely that someone can help point you to at least one broker to
> do the job.
> >
> > -Steve
> >
> > > -Original Message-
> > > From: Flores, Paul A. [mailto:paul.a.flo...@saic.com]
> > > Sent: Tuesday, February 16, 2016 1:06 PM
> > > To: users@qpid.apache.org
> > > Subject: QPID C++ broker and Java - One broker to "rule them all"
> > >
> > > Situation:
> > >
> > >
> > >
> > > I am looking at a mixed language implementation.
> > >
> > >
> > >
> > > Server side (backend) is in C++ while user facing side (frontend) is Java.
> > >
> > >
> > >
> > > A fair amount of JNI "in play".
> > >
> > >
> > >
> > > Specific option of using JMS would be painful because there is a
> > > substantial amount of backend communications between servers.
> > >
> > >
> > >
> > > Questions are straightforward.
> > >
> > >
> > >
> > > How do I get both sides (backend and frontend) to use the same Broker?
> > >
> > >
> > >
> > > Is JNI the only option?
> > >
> > >
> > >
> > > Insights and comments are welcomed and appreciated.
> > >
> > >
> > >
> > > Paul
> > >
> > >
> > >
> > > p.s. I apologize for the "Lord of the Rings&quo

RE: QPID C++ broker and Java - One broker to "rule them all"

[Steve Huston]

There's a compatibility matrix on the page: 
http://qpid.apache.org/components/index.html
If that doesn't contain all the info you need to help decide, try asking again 
- I may not understand the problem.

-Steve

> -Original Message-
> From: Flores, Paul A. [mailto:paul.a.flo...@saic.com]
> Sent: Tuesday, February 16, 2016 1:29 PM
> To: users@qpid.apache.org
> Subject: RE: QPID C++ broker and Java - One broker to "rule them all"
> 
> Per Steve's advice:
> 
> Environment:
> Centos 5.11 (moving soon to 7)
> C++: gcc 4.1.2
> Java: 1.7.0_95
> 
> QPID Messaging API: qpid-cpp-0.34
> C++ Broker
> 
> From: Steve Huston [shus...@riverace.com]
> Sent: Tuesday, February 16, 2016 12:13 PM
> To: users@qpid.apache.org
> Subject: RE: QPID  C++ broker and Java - One broker to "rule them all"
> 
> As long as the front end, back end, and broker can speak the same AMQP
> version, they should all play nice regardless of the programming language.
> 
> If you can be a little more specific about the client code versions, it's 
> highly
> likely that someone can help point you to at least one broker to do the job.
> 
> -Steve
> 
> > -Original Message-
> > From: Flores, Paul A. [mailto:paul.a.flo...@saic.com]
> > Sent: Tuesday, February 16, 2016 1:06 PM
> > To: users@qpid.apache.org
> > Subject: QPID C++ broker and Java - One broker to "rule them all"
> >
> > Situation:
> >
> >
> >
> > I am looking at a mixed language implementation.
> >
> >
> >
> > Server side (backend) is in C++ while user facing side (frontend) is Java.
> >
> >
> >
> > A fair amount of JNI "in play".
> >
> >
> >
> > Specific option of using JMS would be painful because there is a
> > substantial amount of backend communications between servers.
> >
> >
> >
> > Questions are straightforward.
> >
> >
> >
> > How do I get both sides (backend and frontend) to use the same Broker?
> >
> >
> >
> > Is JNI the only option?
> >
> >
> >
> > Insights and comments are welcomed and appreciated.
> >
> >
> >
> > Paul
> >
> >
> >
> > p.s. I apologize for the "Lord of the Rings" reference in subject line.
> 
> -
> 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

RE: QPID C++ broker and Java - One broker to "rule them all"

[Steve Huston]

As long as the front end, back end, and broker can speak the same AMQP version, 
they should all play nice regardless of the programming language.

If you can be a little more specific about the client code versions, it's 
highly likely that someone can help point you to at least one broker to do the 
job.

-Steve

> -Original Message-
> From: Flores, Paul A. [mailto:paul.a.flo...@saic.com]
> Sent: Tuesday, February 16, 2016 1:06 PM
> To: users@qpid.apache.org
> Subject: QPID C++ broker and Java - One broker to "rule them all"
> 
> Situation:
> 
> 
> 
> I am looking at a mixed language implementation.
> 
> 
> 
> Server side (backend) is in C++ while user facing side (frontend) is Java.
> 
> 
> 
> A fair amount of JNI "in play".
> 
> 
> 
> Specific option of using JMS would be painful because there is a substantial
> amount of backend communications between servers.
> 
> 
> 
> Questions are straightforward.
> 
> 
> 
> How do I get both sides (backend and frontend) to use the same Broker?
> 
> 
> 
> Is JNI the only option?
> 
> 
> 
> Insights and comments are welcomed and appreciated.
> 
> 
> 
> Paul
> 
> 
> 
> p.s. I apologize for the "Lord of the Rings" reference in subject line.

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

Re: qpid errors

[Steve Huston]

Google for that error. The hoops PS makes you jump through to run scripts is 
amazing. 

Steve Huston
(sent from my iPhone - please excuse brevity and typos)

> On Aug 5, 2015, at 4:50 AM, Suman.Patro-TRN  
> wrote:
> 
> OK Steve. Thanks for  the correction. But I  would  like to run tests of 
> qpid. But when I  build run_tests from  Visual studio, all the  tests fail. 
> The Testing log file has  recorded  the reason of failure.
> The reason  is ,
> run_test.ps1 cannot be loaded because the execution of scripts is disabled on 
> this system.
> Even after enabling script  execution on  the  system, the  error  still  
> persists.
>Kindly suggest some solutions.
> --Suman
> ________
> From: Steve Huston [shus...@riverace.com]
> Sent: Tuesday, August 04, 2015 7:16 PM
> To: users@qpid.apache.org
> Subject: RE: qpid errors
> 
> The broker doesn't need to be run as a Windows service (but that's a 
> perfectly good thing to do). The error below was likely because there is no 
> \temp or \temp\qpidd.data directories and your account didn't have rights to 
> create it.
> 
> -Steve
> 
>> -Original Message-
>> From: Suman.Patro-TRN [mailto:suman.patro-...@lntebg.com]
>> Sent: Tuesday, August 04, 2015 5:41 AM
>> To: users@qpid.apache.org
>> Subject: RE: qpid errors
>> 
>> Hey  Gordon,
>>  Thanks a ton.  The  error  got  resolved.  The  broker  
>> in qpid 0.34 is
>> named as qpidd.exe which  needed to  be  run as  a windows  service.
>> 
>> From: Gordon Sim [g...@redhat.com]
>> Sent: Tuesday, August 04, 2015 3:05 PM
>> To: users@qpid.apache.org
>> Subject: Re: qpid errors
>> 
>>> On 08/04/2015 07:30 AM, Suman.Patro-TRN wrote:
>>> Hey Gordon,
>>>  1.  There is  no amqp broker .exe , but  there is qpidbroker.dir  which  
>>> has
>> broker.cpp.obj  and qpidbrokerd.dll in D:\qpid_build\src\Debug. what  do 
>> I
>> start and how??
>>>  2. I  tried running qpid.exe but  with  errors  as :
>>> 
>>> D:\qpid_build\src\Debug>qpidd.exe
>>> 2015-08-04 11:50:18 [Broker] notice Broker (pid=7536) start-up
>>> 2015-08-04 11:50:18 [Broker] notice Broker (pid=7536) shut-down
>>> 2015-08-04 11:50:18 [Broker] critical Unexpected error: Can't create
>> directory:
>>> \TEMP\QPIDD.DATA
>> 
>> That is the right executable, the error is because it can't create the 
>> directory
>> it wants. I'm not sure why that is the case (I'm not a windows user, but
>> hopefully someone more familiar with it will chip in with suggestions).
>> 
>> There are two options you could use to avoid that: (1) use the no-data-dir
>> option, which avoids needing a directory and (2) use the data-dir option to
>> point at a valid directory the broker can use.
>> qpidd.exe -h should give you all the available options.
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional
>> commands, e-mail: users-h...@qpid.apache.org
>> 
>> Larsen & Toubro Limited
>> 
>> www.larsentoubro.com
>> 
>> This Email may contain confidential or privileged information for the 
>> intended
>> recipient (s). If you are not the intended recipient, please do not use or
>> disseminate the information, notify the sender and delete it from your
>> system.
>> 
>> -
>> 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
> 
> Larsen & Toubro Limited
> 
> www.larsentoubro.com
> 
> This Email may contain confidential or privileged information for the 
> intended recipient (s). If you are not the intended recipient, please do not 
> use or disseminate the information, notify the sender and delete it from your 
> system.
> 
> -
> 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 errors

[Steve Huston]

The broker doesn't need to be run as a Windows service (but that's a perfectly 
good thing to do). The error below was likely because there is no \temp or 
\temp\qpidd.data directories and your account didn't have rights to create it.

-Steve

> -Original Message-
> From: Suman.Patro-TRN [mailto:suman.patro-...@lntebg.com]
> Sent: Tuesday, August 04, 2015 5:41 AM
> To: users@qpid.apache.org
> Subject: RE: qpid errors
> 
> Hey  Gordon,
>   Thanks a ton.  The  error  got  resolved.  The  broker  
> in qpid 0.34 is
> named as qpidd.exe which  needed to  be  run as  a windows  service.
> 
> From: Gordon Sim [g...@redhat.com]
> Sent: Tuesday, August 04, 2015 3:05 PM
> To: users@qpid.apache.org
> Subject: Re: qpid errors
> 
> On 08/04/2015 07:30 AM, Suman.Patro-TRN wrote:
> > Hey Gordon,
> >   1.  There is  no amqp broker .exe , but  there is qpidbroker.dir  which  
> > has
> broker.cpp.obj  and qpidbrokerd.dll in D:\qpid_build\src\Debug. what  do I
> start and how??
> >   2. I  tried running qpid.exe but  with  errors  as :
> >
> > D:\qpid_build\src\Debug>qpidd.exe
> > 2015-08-04 11:50:18 [Broker] notice Broker (pid=7536) start-up
> > 2015-08-04 11:50:18 [Broker] notice Broker (pid=7536) shut-down
> > 2015-08-04 11:50:18 [Broker] critical Unexpected error: Can't create
> directory:
> > \TEMP\QPIDD.DATA
> 
> That is the right executable, the error is because it can't create the 
> directory
> it wants. I'm not sure why that is the case (I'm not a windows user, but
> hopefully someone more familiar with it will chip in with suggestions).
> 
> There are two options you could use to avoid that: (1) use the no-data-dir
> option, which avoids needing a directory and (2) use the data-dir option to
> point at a valid directory the broker can use.
> qpidd.exe -h should give you all the available options.
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional
> commands, e-mail: users-h...@qpid.apache.org
> 
> Larsen & Toubro Limited
> 
> www.larsentoubro.com
> 
> This Email may contain confidential or privileged information for the intended
> recipient (s). If you are not the intended recipient, please do not use or
> disseminate the information, notify the sender and delete it from your
> system.
> 
> -
> 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: In qpidd what's the maximum number of subscriptions to a queue node

[Steve Huston]

Hi Frase,

You’ve done a good job at guessing the limits - I’ll let Gordon educate us on 
the rest.

The threading model, though - definitely not per connection. There’s a pool of 
threads that can handle I/O - by default there are (number of cores) + 1, but 
you can change it by command line option.

The I/O model is proactive (as opposed to reactive) and those threads handle 
what ever handles get I/O completions. Yes, at some point, it gets saturated 
but it’s driven by the amount of I/O going on concurrently, not by the sheer 
number of connections.

So go for it - let us know how high you (well, the number of clients) can get 
:-)

-Steve

> On Jul 11, 2015, at 12:52 PM, Fraser Adams  
> wrote:
> 
> Hey all,
> Suppose I have a queue on qpidd, I know that I can have multiple consumer 
> clients subscribing to that queue node - I've used that several times to 
> provide a means of scaling out consumers, so if I have "n" consumers each 
> consumer receives roughly 1/n of the messages published onto the queue.
> 
> I've never really pushed the limits of this and have tended to only have 10 - 
> 20 consumers, but it got me wondering:
> a) What's the maximum theoretical limit for the number of consumers on such a 
> shared resource
> b) what's the maximum practical limit - I'm not sure how the qpidd threading 
> model works (I *think* it's per connection), so I'm wondering at what point 
> we get into a position where the "stampeding herds" lock contention problem 
> kicks in.
> 
> I know I should probably just stand up a test and give it a whirl, but 
> figured I'd ask first :-)
> 
> I *think* that the answer to a) is that the theoretical limit is the maximum 
> number of link handles and is a 32 bit unsigned int so would be 4294967295, 
> though I suspect something else would get a bit sad before that limit is 
> reached.
> 
> 
> On point b. has anyone (most likely Gordon) explored the scaling limits of 
> qpidd? Obviously when Qpid started out servers tended to have something 
> between one and four cores, but now of course Moore's law tends to be 
> followed by increasing the number of cores, so I'm curious as to how qpidd 
> scales. I'm thinking of things like ActiveMQ Apollo where as I understand it 
> it uses hawt-dispatch (which I think is the Java equivalent of Apple's Grand 
> Central Dispatch pattern) and I know with Proton there has been a lot of work 
> migrating to a more reactive pattern, which makes me wonder if that's an 
> acknowledgement of any potential scaling limits in qpidd at present? If there 
> are known limits is there a roadmap to change the threading model. I'm mostly 
> just curious at the moment, but I guess it's a question that's going to crop 
> up more and more.
> 
> Cheers,
> Frase
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
> 

RE: Connecting to RabbitMQ using QPid client

[Steve Huston]

Hi Mansour,

>  I am a bit confused by the compatibily issues between different versions of
> the AMPQ, and lost in the documentation.

Sorry about that - hopefully we can help get things straightened out.

> First thing, as far as I know, AMQP is not JMS. There's a lot of examples QPid
> about JMS, which led me to include that in QPid, JMS is compatible with
> AMQP. Is this conclusiong correct ?
> Is it documented some where ??

Sort of - JMS is an API spec; AMQP is a protocol spec. The JMS clients supplied 
by Apache Qpid are compatible with AMQP.

> We have two components "QPid Proton" and "QPid JMS". Both are clients for
> AMQP. QPid JMS is built on Proton.
> Which one do I use ?

Neither. Those are both to work with AMQP 1.0. RabbitMQ is AMQP 0.8 (0.9?) so 
it requires the JMS client that works with older AMQP versions. You can find it 
here:
http://qpid.apache.org/components/jms/amqp-0-x.html

> Additionally, I am not sure about what mvn depencies to use with what.
> Then comes the URL and the initial factory part. Looking at the examples, was
> not a lot of help, as I am testing agains RabbitMQ, and don't know when I am
> hitting an issue, if it's compatability or I am doing something wrong.

Hopefully someone else can help with the detailed questions below as I don't 
have much experience with those.

-Steve

> Here's the initial factory options we have,
> 
> 
> java.naming.factory.initial =
> org.apache.qpid.jms.jndi.JmsInitialContextFactory
> java.naming.factory.initial =
> org.apache.qpid.jndi.PropertiesFileInitialContextFactory
> java.naming.factory.initial =
> org.apache.qpid.amqp_1_0.jms.jndi.PropertiesFileInitialContextFactory
> 
> Then the URL format,
> connectionfactory.localhost =
> amqp://guest:guest@localhost:5672?clientid=test-client&remote-
> host=default
> connectionfactory.localhost = amqp://guest:guest@localhost:5672
> connectionfactory.localhost = amqp://localhost:5672
> 
> I have read these pages, but still lost:
> 
> https://cwiki.apache.org/confluence/display/qpid/AMQP+compatibility
> https://www.rabbitmq.com/interoperability.html
> 
> Now, my issue is connecting using QPid client to both RabbitMQ and QPid
> broker 0.32
> 
> I am just doing the simple HelloWord example:
> 
> Here's my jndi:
> java.naming.factory.initial =
> org.apache.qpid.jms.jndi.JmsInitialContextFactory
> connectionfactory.localhost = amqp://localhost:5672 queue.myQueue = git-
> repo-name
> 
> maven:
> 
> org.apache.qpid
> qpid-jms-client
> 0.2.0
> 
> 
> Java:
> Context context = new InitialContext();
> ConnectionFactory factory = (ConnectionFactory)
> context.lookup("localhost");
> Destination queue = (Destination) context.lookup("myQueue");
> Connection connection = factory.createConnection(USER,
> PASSWORD);
> connection.setExceptionListener(new MyExceptionListener());
> connection.start();
> Session session = connection.createSession(false,
> Session.AUTO_ACKNOWLEDGE);
> MessageProducer producer = session.createProducer(queue);
> 
> 
> The error on the client when connecting to QPid:
> 
> 2015-06-10 17:22:04,483 [localhost:5672]] - DEBUG AmqpAbstractResource
>   - AmqpSession { ID:localhost-48465-1433942523956-0:1:1 } is now 
> open:
> 2015-06-10 17:22:04,488 [localhost:5672]] - DEBUG AmqpSession
>   - Creating AmqpFixedProducer for: git-repo-name
> 2015-06-10 17:22:04,495 [localhost:5672]] - TRACE NettyTcpTransport
>   - Attempted write of: 253 bytes
> 2015-06-10 17:22:07,498 [ntLoopGroup-2-1] - TRACE NettyTcpTransport
>   - Exception on channel! Channel is [id: 0x6ca00e8f,
> /127.0.0.1:44497 => localhost/127.0.0.1:5672]
> 2015-06-10 17:22:07,499 [localhost:5672]] - INFO  AmqpProvider
>   - Transport failed: Connection reset by peer
> 2015-06-10 17:22:07,500 [ntLoopGroup-2-1] - TRACE NettyTcpTransport
>   - Channel has gone inactive! Channel is [id: 0x6ca00e8f,
> /127.0.0.1:44497 :> localhost/127.0.0.1:5672] Connection ExceptionListener
> fired, exiting.
> 2015-06-10 17:22:07,501 [localhost:5672]] - DEBUG AmqpProvider
>   - Transport connection remotely closed
> javax.jms.JMSException: Connection reset by peer
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionS
> upport.java:60)
> at
> org.apache.qpid.jms.JmsConnection.onAsyncException(JmsConnection.java:
> 1169)
> at
> org.apache.qpid.jms.JmsConnection.onConnectionFailure(JmsConnection.ja
> va:1085)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.fireProviderException(A
> mqpProvider.java:832)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpProvider.ja
> va:688)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureT

Re: Welcome Jakub Scholz as Qpid committer and PMC member

[Steve Huston]

Welcome Jakub!

Steve Huston
(sent from my iPhone - please excuse brevity and typos)

> On May 22, 2015, at 2:24 PM, Robbie Gemmell  wrote:
> 
> The Qpid PMC has voted to grant commit rights and PMC membership to
> Jakub Scholz in recognition of his contributions to the project.
> 
> Please join me in extending Jakub a warm welcome!
> 
> Robbie
> 
> -
> 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: connectivity issues with Azure service bus

[Steve Huston]

Sorry if this is a stupid question, but does your board have TCP/IP support?

> -Original Message-
> From: Vinod, Shelke [mailto:vinod.she...@honeywell.com]
> Sent: Thursday, May 21, 2015 9:16 AM
> To: users@qpid.apache.org
> Subject: connectivity issues with Azure service bus
> 
> Hi,
>   I have started using Apache qpid-proton llibrary recently. I have a sample
> code where I post a test message to a azure service bus.
>   When I compile this program and library for x86 and run it, I am able to 
> send
> the messages successfully.
>   But when I cross compile this library and sample program for ARM and put it
> on a experimental board, I get an error
> 
> ==
> =
> CALL pn_messenger_set_outgoing_window... RETURNED 0 CALL
> pn_messenger_set_blocking... RETURNED 0 CALL pn_messenger_start...
> RETURNED 0 CALL pn_messenger_put... RETURNED -2
> ERROR: PROTON API: pn_messenger_put Errno: -2 (PN_ERR)
> ERROR: PROTON Msg: CONNECTION ERROR (text-
> xxx.servicebus.windows.net:(null)): pn_create_socket: No such file or
> directory
> ==
> 
> 
> Has anybody faced this issue?  Any help would be appreciated.
> 
> Regards
> Vinod
> 
> 


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

RE: [VOTE] Ask infra to add git repo and JIRA for qpid-interop

[Steve Huston]

+1

> -Original Message-
> From: Kim van der Riet [mailto:kim.vdr...@redhat.com]
> Sent: Tuesday, May 19, 2015 10:52 AM
> To: users@qpid.apache.org
> Subject: [VOTE] Ask infra to add git repo and JIRA for qpid-interop
> 
> Thank you to all those who responded to my e-mail about the qpid-interop
> project. I don't see any concern about this that precludes going ahead and
> asking for infra to add a git repo and a JIRA for this project.
> 
> In short, I am asking for a vote to:
> Ask infra@ to add a git repo for qpid-interop; Ask infra@ to add a JIRA for
> qpid-interop; No additional mailing lists should be needed, as discussions
> should be conducted on qpid-users@
> 
> I will close the vote on Friday May 22.
> 
> Kim van der Riet
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional
> commands, e-mail: users-h...@qpid.apache.org

RE: Qpid client in Mac OS X

[Steve Huston]

Great! Thanks for the update, Filipe!

If you have patches to enable OS X builds, please attach them to a jira entry.

-Steve

> -Original Message-
> From: Filipe Santos [mailto:filipe.san...@coollink.pt]
> Sent: Friday, April 24, 2015 1:42 PM
> To: users@qpid.apache.org
> Subject: RE: Qpid client in Mac OS X
> 
> Hi
> 
> Made it to compile c++ qpid client in Mac Os X.
> I had some issues with CLOCK_MONOTONIC, but I made it to compile
> libqmf2, libqpidclient, libqpidcommon, libqpidmessaging and libqpidtypes.
> 
> Already made a small test, like send/receive message and it went well.
> I'll make more tests to check everything is ok.
> 
> Best,
> Filipe Santos
> 
> -Original Message-
> From: Filipe Santos [mailto:filipe.san...@coollink.pt]
> Sent: quarta-feira, 22 de Abril de 2015 18:19
> To: users@qpid.apache.org
> Subject: RE: Qpid client in Mac OS X
> 
> Hi
> 
> I'll find a way to set this task among my work and tell you how it went.
> 
> Best
> Filipe Santos
> 
> -Original Message-
> From: Steve Huston [mailto:shus...@riverace.com]
> Sent: terça-feira, 21 de Abril de 2015 20:22
> To: users@qpid.apache.org
> Subject: RE: Qpid client in Mac OS X
> 
> Hi Filipe,
> 
> I'm not aware of anyone trying this since that time. However, I see 
> conflicting
> reports of __thread support being added and working on OS X g++/clang.
> Intel C++ allegedly supports it in 15.0.
> 
> It's worth a try... If you give it a try, please let us know how it goes.
> 
> -Steve
> 
> > -Original Message-
> > From: Filipe Santos [mailto:filipe.san...@coollink.pt]
> > Sent: Tuesday, April 21, 2015 5:38 AM
> > To: users@qpid.apache.org
> > Subject: Qpid client in Mac OS X
> >
> > Hi everyone!
> >
> > Does anyone knows if the c++ qpid client can be used in Os X?
> >
> > I know this was already asked in 2010 (It was not possible then "the
> > OSX runtime has no support for the gcc thread specific variables
> > extension"), but five years have passed and things have changed!
> >
> > Best regards,
> > Filipe Santos
> 
> -
> 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


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

RE: Qpid client in Mac OS X

[Steve Huston]

Hi Filipe,

I'm not aware of anyone trying this since that time. However, I see conflicting 
reports of __thread support being added and working on OS X g++/clang. Intel 
C++ allegedly supports it in 15.0.

It's worth a try... If you give it a try, please let us know how it goes.

-Steve

> -Original Message-
> From: Filipe Santos [mailto:filipe.san...@coollink.pt]
> Sent: Tuesday, April 21, 2015 5:38 AM
> To: users@qpid.apache.org
> Subject: Qpid client in Mac OS X
> 
> Hi everyone!
> 
> Does anyone knows if the c++ qpid client can be used in Os X?
> 
> I know this was already asked in 2010 (It was not possible then "the OSX
> runtime has no support for the gcc thread specific variables extension"), but
> five years have passed and things have changed!
> 
> Best regards,
> Filipe Santos

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

RE: Website changes for the JMS client

[Steve Huston]

I agree - it looks really good.

> -Original Message-
> From: Gordon Sim [mailto:g...@redhat.com]
> Sent: Friday, March 20, 2015 9:27 AM
> To: users@qpid.apache.org
> Subject: Re: Website changes for the JMS client
> 
> On 03/19/2015 05:55 PM, Robbie Gemmell wrote:
> > http://people.apache.org/~robbie/qpid/jms/0.1.0/website/
> >
> > What do people think of the changes?
> 
> Looks good to me!
> 
> > My main questions were around
> > whether we should give a more prominent link on the download page for
> > the old client for a bit longer during transition, and whether the 0-x
> > client is exposed enough on the component pages to avoid too much
> > confusion?
> 
> I think its about right as you have it. It's still fairly easy to find the 
> older/other
> clients, since the pages are not too cluttered, but the focus is on the new 
> one
> which is what I think we want.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional
> commands, e-mail: users-h...@qpid.apache.org

RE: 0.32 release update - RC is available

[Steve Huston]

qpid-cpp is ok on AIX.

> -Original Message-
> From: Justin Ross [mailto:justin.r...@gmail.com]
> Sent: Tuesday, March 10, 2015 9:22 AM
> To: users@qpid.apache.org
> Subject: 0.32 release update - RC is available
> 
> Hi, folks.  The 0.32 release candidate is now available.
> 
>   Release artifacts: https://dist.apache.org/repos/dist/dev/qpid/0.32-rc/
>   Maven staging repo:
> https://repository.apache.org/content/repositories/orgapacheqpid-1027
>   Test output: http://people.apache.org/~jross/qpid-0.32-rc.log
> 
> This is pre-release code, for testing only!  Thanks very much to those who
> have reported on their testing thus far.  Please verify that the RC works for
> you.
> 
> Note that the ssl_test failure in the cpp test output is a still unresolved
> problem with my test harness.  The test succeeds when I run it manually.
> 
> These release artifacts are signed.  If approved by vote, the RC bits will be
> the GA bits.  I will open the vote later today.
> 
> Thanks!
> Justin
> 
> ---
> 0.32 release page:
> https://cwiki.apache.org/confluence/display/qpid/0.32+Release

RE: Images transfer

[Steve Huston]

Yes.

> -Original Message-
> From: Michael Ivanov [mailto:iv...@logit-ag.de]
> Sent: Tuesday, March 10, 2015 4:52 PM
> To: users@qpid.apache.org
> Subject: Images transfer
> 
> Good evening,
> 
> Is it reasonable to use amqp messages (currently I am using proton together
> with qpidd) for image transfer? The images are expected to be of 1 ... 1.5Mb
> size.
> 
> Best regards,
> --
>  \   / | |
>  (OvO) |  Mikhail Iwanow   |
>  (^^^) |  Voice:   +7 (911) 223-1300   |
>   \^/  |  E-mail:  iv...@logit-ag.de   |
>   ^ ^  |   |
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional
> commands, e-mail: users-h...@qpid.apache.org

RE: handling old Subversion contents after migrations to Git

[Steve Huston]

The only one I'm strongly opposed to is #4.

I slightly prefer #3 of the remaining options. It gets the old content out of 
the way without deleting it.

> -Original Message-
> From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com]
> Sent: Monday, March 09, 2015 12:25 PM
> To: users@qpid.apache.org
> Subject: handling old Subversion contents after migrations to Git
> 
> Hi all,
> 
> As you probably know, we migrated the Proton and new JMS client code to
> Git repositories last year. As part of the process the old locations within 
> the
> Subversion repo were frozen read-only and left in place.
> 
> Some folks have been caught out by using the old stale locations, as although
> we have updated our website with the new locations (and all the commits@
> traffic mentions the new locations) it isnt particularly clear from the old
> contents themselves that they are no longer in use (other than by realising
> the last commits were a while ago).
> 
> I noticed some documentation which indicated as Chair I should be able to
> modify the access rights to the old locations, allowing us to edit them and
> make things clearer. I checked with infra and that is indeed the case,
> although they are also happy to do it for us depending on the change (e.g
> move contents to an attic dir, add pointer file).
> 
> I wonder what people think we should do:
> 1. Add pointer files indicating the contents are no longer used and directing
> to the Git repos.
> 2. Delete the trunk dirs, add pointer files to the Git repos.
> 3. Move the contents to an attic area, add pointer files to the Git repos in 
> old
> locations.
> 4. Delete the contents entirely, dont add pointers.
> 
> (The 'deleted' files will obviously remain in Subversion history)
> 
> Thoughts?
> 
> Thanks,
> Robbie
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional
> commands, e-mail: users-h...@qpid.apache.org

RE: towards releasing the new AMQP 1.0 JMS client

[Steve Huston]

> -Original Message-
> From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com]
> Sent: Wednesday, February 18, 2015 10:41 AM
> To: users@qpid.apache.org
> Subject: Re: towards releasing the new AMQP 1.0 JMS client
> 
> On 18 February 2015 at 14:59, Justin Ross  wrote:
> > On Wed, Feb 18, 2015 at 7:33 AM, Robbie Gemmell
> > 
> > wrote:
> >
> >> At the moment the version number is 0.1[-SNAPSHOT], to be followed by
> >> 0.2 etc until we think there is sufficient maturity to go 1.0
> >> (sidenote: not years :P). The initial focus has been on implementing
> >> the JMS 1.1 API for now so change will come once we begin
> >> implementing the JMS 2.0 API, which could also be when we bump to 2.0
> >> for the client itself if we hadn't already for other reasons. I
> >> envisage us doing releases more frequently than our existing
> >> components have tended to and expect we will do small point releases
> >> eventually, so I think it probably makes sense to use 0.1.0 etc from
> >> the start (or even
> >> 0.0.1 to underscore its the initial release). We could consider
> >> adding alpha/beta etc status, however we would then have to contend
> >> with the version ordering disparities between e.g Maven and OSGi by
> >> crafting some horrible release versions (including the final
> >> versions), and I'm not much of a fan of publishing those to central.
> >>
> >
> > All of this seems fine to me, except perhaps 0.0.1.  That looks very
> > strange to me--like a patch update on a 0.0 release--and I think 0.1
> > gets the point across well enough.
> >
> 
> Point taken. In that case 0.1.0 is what I would propose starting with.
> Skipping back and forth between 2 and 3 digits isnt something I want to do,
> but I do want to do point releases if appropriate.

+1 to that.

> >> Next up is the name. The new client has thus far been called simply
> >> 'Qpid JMS', with module names qpid-jms-foo, and binary tar
> >> apache-qpid-jms[-bin]. We already release two other JMS clients, the
> >> original AMQP 0-x one, module named qpid-client, and the older AMQP
> >> 1.0 one, module named qpid-amqp-1-0-jms-client. Although the new
> >> clients name describes what it is, and the version numbers will
> >> differ from the previous clients, do people think this is enough
> difference?
> >> I think it is still going to be confusing for people no matter what
> >> we do here, but should we perhaps give the new client a component
> >> name to allow them more easily distinguished, i.e a name of the style
> >> Qpid Foo or Qpid FooJMS? If so, any ideas (failing spectacularly over
> here)?
> >>
> >
> > I lean toward letting the new jms impl take the prime naming real estate:
> > qpid-jms, as you have it now.  I haven't thought of a good name ("Qpid
> > JamSession"? kidding), and since this is really where we want to
> > direct users going forward, it deserves the mantle of "Qpid JMS".
> >
> 
> Thats why we went with that originally, I think it is an entirely appropriate
> name for what it is/will be, and I certainly havent been able to think of
> anything that fits as nice. Its just a question of whether its a bit 
> overloaded.
> I'm happy to leave it as it is if people think we can manage things going
> forward though.

I agree with Justin to position the new AMQP 1.0 JMS client as Qpid JMS, even 
at the risk of some short term confusion.

> > Could we rename the qpid-amqp-1-0-jms-client artifact to include the
> > word "prototype"?
> 
> I think its a few years late for that hehe. If we were renaming, I'd possibly 
> go
> with 'legacy' or something to that effect, but I'd quite possibly leave it
> unchanged.

I think that leaving it as is is fine, and make the distinction on the web 
site, aiming to have just the Qpid JMS after a small number of releases.

> > On the website, I see the previous AMQP 1.0 jms client as being
> > visible but not prominent, and perhaps only available through some extra
> navigation.
> > The new AMQP 1.0 client, and the 0-10-0-8 client, should be the
> > featured offerings (especially the former).

+1

-Steve

Re: C++ build problem

[Steve Huston]

There's a missing file that was (should have) been added with the patch. Will 
check on it later. 

Steve Huston
(sent from my iPhone - please excuse brevity and typos)

> On Feb 4, 2015, at 4:44 PM, Justin Ross  wrote:
> 
> https://paste.apache.org/eGBG
> 
> Steve, this appears to arise from the AIX change, 1657338.
> 
> I'm on F20 in this case, with cmake version 2.8.12.2.
> 
> Justin

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

Re: C++ build problem

[Steve Huston]

Thanks Justin. I will check on this tonight 

Steve Huston
(sent from my iPhone - please excuse brevity and typos)

> On Feb 4, 2015, at 4:44 PM, Justin Ross  wrote:
> 
> https://paste.apache.org/eGBG
> 
> Steve, this appears to arise from the AIX change, 1657338.
> 
> I'm on F20 in this case, with cmake version 2.8.12.2.
> 
> Justin

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

RE: Proton Java Messenger API questions

[Steve Huston]

Great - thanks very much for the quick reply and explanation!
-Steve

> -Original Message-
> From: Rafael Schloming [mailto:r...@alum.mit.edu]
> Sent: Monday, January 26, 2015 10:50 PM
> To: users@qpid.apache.org
> Subject: Re: Proton Java Messenger API questions
> 
> On Mon, Jan 26, 2015 at 5:38 PM, Steve Huston 
> wrote:
> 
> > Hi,
> > I have a customer working on some development and trying the Proton
> > Java Messenger API. They're having some problems and sent along the
> > following questions. Could someone please help clarify these issues?
> > Thanks,
> > -Steve
> >
> >
> > The roadmap is at a pretty high level.   Any insight on what API
> > stabilization means?
> >
> 
> Once Proton hits 1.0 I'd like to guarantee ABI stability (and API
> compatibility) for the entire 1.x series. This is basically a bucket for 
> things to
> fix prior to that point. Off the top of my head, things that fall into this 
> bucket
> inculde:
> 
>   - removing deprecated/unused APIs (the driver, some of the more ancient
> message codec routines)
>   - removing some useless duplicate structs
>   - making sure internal headers are not publicly accessible
>   - streamlining usage of the codec API
>   - streamlining sending/receiving messages
> 
> 
> > Does API stabilization include some type of fatal error handling in
> > the Messenger API?
> >
> 
> API stabilization is really about locking down the core APIs and making sure
> we can commit to the ABI/API for long enough to justify a 1.x series.
> Messenger's error handling doesn't really fall into this bucket. That's not to
> say it won't happen, though.
> 
> 
> > Going forward is the Messenger API going be the primary API or will
> > most applications need to write directly to the lower levels (engine,
> > transport...)?
> >
> > As it stands the Messenger API's lack of error handling (silent
> > failure and continued operation under failure conditions) really makes
> > the Messenger API unusable for real applications.
> >
> 
> Going forward, my plan is to reconcile Messenger with the Reactor API. I
> believe by doing this we can provide a much better model for non blocking
> use of messenger than the current API provides. I also intend to rework the
> internals of messenger to operate as a set of cooperating handlers which can
> be made accessible to applications, thereby allowing much more flexibility
> and customization of a given messenger's behavior. The events framework
> should also provide a strong basis for doing proper error handling, and the
> timer system should make certain higher level features like automatic
> reconnect possible.
> 
> At its inception, Messenger's goal was to provide a very simple interface for
> sending and receiving AMQP messages that doesn't require understanding
> many more concepts than just "message" and "address". I still believe this is
> a very important goal, however where the current Messenger API has fallen
> short is in the ability to easily transition people to some of the more
> advanced scenarios available to them with AMQP. I believe the above design
> can address that shortcoming, so that is where I've been focusing my efforts.
> 
> I know this doesn't directly answer your question of whether it will be "the
> primary API", but my hope is to make that question kind of moot by making
> transition between the messenger portion of the API and the rest of the API
> smooth enough that you don't really need to choose up front which
> approach to use. You can just do what is easiest for your initial use case 
> and if
> you need to tweak something at a lower level or provide some aspect of
> higher level functionality, that will be easy to do.
> 
> Initially I'm doing all this on the C side only simply because it involves a 
> fair
> amount of exploratory coding and design work and doing that in two
> languages simultaneously is not very efficient at all. Once the design is in
> place though, I believe it should be significantly less work to provide the
> same sort of thing in Java.
> 
> --Rafael

Proton Java Messenger API questions

[Steve Huston]

Hi,
I have a customer working on some development and trying the Proton Java 
Messenger API. They're having some problems and sent along the following 
questions. Could someone please help clarify these issues?
Thanks,
-Steve


The roadmap is at a pretty high level.   Any insight on what API stabilization 
means?

Does API stabilization include some type of fatal error handling in the 
Messenger API?   

Going forward is the Messenger API going be the primary API or will most 
applications need to write directly to the lower levels (engine, transport...)?

As it stands the Messenger API's lack of error handling (silent failure and 
continued operation under failure conditions) really makes the Messenger API 
unusable for real applications. 


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

RE: Qpid C++ and Python 15.02 - Alpha approaches

[Steve Huston]

Sorry to chime in late on this - I saw the discussions going by in December but 
paid no attention as I was mostly not working then.

> -Original Message-
> From: Gordon Sim [mailto:g...@redhat.com]
> Sent: Tuesday, January 20, 2015 10:49 AM
> To: users@qpid.apache.org
> Subject: Re: Qpid C++ and Python 15.02 - Alpha approaches
> 
> On 01/20/2015 03:37 PM, Justin Ross wrote:
> > http://qpid.2158936.n2.nabble.com/Any-ETA-on-a-QPid-0-32-release-
> td761
> > 7054.html
> >
> > Yes, the generally agreed goal is to move away from "0." for our now
> > mature components.  I don't think any suggestion was made about Proton.
> >
> > Most participants on that thread favored a YY.MM (Year, Month) scheme,
> > so that's where I started.
> 
> The main advantage I see from the year/month scheme is the ability to relate
> different component versions to each other. E.g. 15.06 of component X was
> released at the same time 15.06 of component y was, but after 15.01 of
> component z and before 15.12 of component, um, a, lets say.

Ok, but a month is a long time and if components aren't released "together" 
then both in the same month may not mean much.

> I.e. you really only get benefit out if this if it is used fairly broadly 
> across
> components that are released at different times.
> 
> While I see some advantage from this scheme, there are different
> advantages for other schemes so I have no desire to impose this it.
> However if there isn't sufficient agreement to use it more widely than just
> the qpid-cpp and related bits, I'm not sure it has much advantage (and it is
> definitely a bit unusual).

It is unusual. Not necessarily bad, but it will require more explanation and 
attention because of the confusion it would cause.

Also, what do we mark JIRA entries with for "fix version"? If we don't know the 
time a next release will come, it's hard to mark the next release, and our 
current odd-even won't work any longer either. It's important to be able to 
tell when a bug was fixed.

-Steve

RE: Compiling qpid on aix 6.1 with xlc 13.1.0

[Steve Huston]

I don't think the boost warnings are pertinent in this case, and boost is tough 
to get built with xlC, so for the time being, I'd let that dog lie.

It smells like a mismatch between std::vector arguments between xlC and what 
the code expects. I'd chase that one down first. If I get done with customer 
commitments today I will check into it later.

-Steve

> -Original Message-
> From: Chuck Rolke [mailto:cro...@redhat.com]
> Sent: Wednesday, December 17, 2014 3:00 PM
> To: users@qpid.apache.org
> Subject: Re: Compiling qpid on aix 6.1 with xlc 13.1.0
> 
> Hi Chris,
> 
> In your makeAllOutput.txt file you are getting boost (1_57) warnings right off
> the bat. I've never used any boost beyond 1_53 on linux or windows but
> 1_53 works on both of those platforms.
> 
> Could you try downgrading your boost to 1_53, a "known good on Windows
> and Linux" version?
> 
> -Chuck
> 
> - Original Message -
> > From: "Chris Whelan" 
> > To: users@qpid.apache.org
> > Sent: Wednesday, December 17, 2014 9:31:35 AM
> > Subject: Compiling qpid on aix 6.1 with xlc 13.1.0
> >
> > Hi,
> >
> > We have abandoned using gcc on aix to compile qpid and have now moved
> > on to our next problem child, xlc.  Boost compiled successfully, but
> > when we try to compile qpid, an argument mismatch apparently occurs.
> > The environment description and details are below.  The associated
> > files are attached.  If anyone can offer any insight into what is
> > wrong or has any suggestions on what we should try to resolve this,
> > your assistance will be gratefully accepted.
> >
> > Regards,
> >
> > Chris Whelan
> >
> > # environment
> > export CC=/opt/IBM/xlC/13.1.0/bin/xlc
> > export CXX=/opt/IBM/xlC/13.1.0/bin/xlc++ export
> > BOOST_ROOT=/home/dbapi/enquesta_5_0/boost_1_57_0
> > # for xlC:
> > export PATH=/opt/IBM/xlC/13.1.0/bin:$PATH
> > # for other dependencies built locally export
> > PATH=/home/dbapi/enquesta_5_0/usr/local/bin:$PATH
> >
> > Email attachments:
> > cmakeOutput.txt is the output from running cmake makeAllOutput.txt is
> > the output from the compile (make all) vector.t is an IBM source file,
> > /opt/IBM/xlC/13.1.0/include/vector.t
> > InlineVector.h is from qpid source, $QPID_HOME/src/qpid/InlineVector.h
> >
> > The error from makeAllOutput.txt ("make all" command)
> > /opt/IBM/xlC/13.1.0/include/vector.t", line 41.55: 1540-0215 (S) The
> > wrong numb er of arguments has been specified for
> > "qpid::InlineAllocator > d::Range >,3>::allocate(size_type)".
> > "/opt/IBM/xlC/13.1.0/include/vector.t", line 37.6: 1540-0700 (I) The
> > previous me ssage was produced while processing
> > "std::vector > enceNumber>,qpid::InlineAllocator > enceNumber>ming::Sequ
> > enceNumber> >,3> >::reserve(size_type)".
> > "/home/dbapi/enquesta_5_0/qpid-cpp-0.30/src/qpid/InlineVector.h", line
> 50.13:
> > 15
> > 40-0700 (I) The previous message was produced while processing
> > "qpid::InlineVect
> >
> or,3,std::allocator nge > :framing::SequenceNumber> > >::InlineVector(const allocator_type &)".
> >
> >
> > -
> > 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: Compiling qpid on aix 6.1 with gcc 4.8.2 (or gcc 4.8.3)

[Steve Huston]

I have a feeling you're right... will be here waiting ;-)

> -Original Message-
> From: Chris Whelan [mailto:chris.whe...@systemsandsoftware.net]
> Sent: Tuesday, December 16, 2014 6:04 PM
> To: 
> Subject: Re: Compiling qpid on aix 6.1 with gcc 4.8.2 (or gcc 4.8.3)
> 
> Thanks for your quick reply Steve.  We are proceeding with xlc as you
> suggested.  I have a feeling though it being aix and all, I will be posting 
> again
> shortly...
> 
> Regards,
> 
> -Chris
> 
> > On Dec 16, 2014, at 4:17 PM, Steve Huston 
> wrote:
> >
> > Hi Chris,
> >
> > I don't have any insight into the gcc error. However, I've spent many years
> working on AIX with C++. I've had my share of long and unfruitful nights
> dealing with gcc. IBM has people involved with gcc and it still seems to have
> never-ending problems for some reason.
> >
> > For my 2 cents, I recommend biting the bullet and going with xlC++.
> >
> > FWIW,
> > -Steve Huston
> >
> > From: Chris Whelan [mailto:chris.whe...@systemsandsoftware.net]
> > Sent: Tuesday, December 16, 2014 3:54 PM
> > To: users@qpid.apache.org
> > Subject: Compiling qpid on aix 6.1 with gcc 4.8.2 (or gcc 4.8.3)
> >
> > Hello,
> >
> > We have been struggling mightily to get qpid to compile on aix 6.1 with gcc.
> We have tried both 4.8.2 and 4.8.3 and the error we have run into is:
> >
> > /home/dbapi/enquesta_5_0/qpid-cpp-
> 0.30/src/qpid/sys/posix/PosixPoller.
> > cpp:796:2: internal compiler error: in
> > function_and_variable_visibility, at ipa.c:868 }}  ^ libbacktrace
> > could not find executable to open Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See <http://gcc.gnu.org/bugs.html> for instructions.
> > make: 1254-004 The error code from the last command is 1.
> >
> > This appears to be a problem with gcc itself rather than qpid code,
> > but since we are utilizing the latest version of the gcc compiler I
> > could find for aix and it still does not work, any help in providing a
> > workaround would be greatly appreciated.  My coworker was able to
> > identify the problematic lines.  Two of the errors appear to be
> > related to the use of the PollerHandleDeletionManager (Line 701 and
> > 712) and  Event (Line 729)
> >
> > PollerHandleDeletionManager.destroyThreadState();  (2 occurrences)
> > Event event = impl->eventStream.next(timeout);  (1 occurrence)
> >
> > When he commented out those lines (and additional affected code in the
> case of the Event line), the compilation of PosixPoller.cpp succeeded.  We
> surmised that it has something to do with gcc handling of namespaces, but
> could not come up with a way to get around this issue.  We are planning on
> trying IBM's xlc compiler, but we have invested a lot of time in this already
> and would like to avoid xlc licensing costs if possible.
> >
> > Thanks in advance,
> >
> > Regards,
> >
> > Chris Whelan
> >
> 
> -
> 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: Compiling qpid on aix 6.1 with gcc 4.8.2 (or gcc 4.8.3)

[Steve Huston]

Hi Chris,

I don't have any insight into the gcc error. However, I've spent many years 
working on AIX with C++. I've had my share of long and unfruitful nights 
dealing with gcc. IBM has people involved with gcc and it still seems to have 
never-ending problems for some reason.

For my 2 cents, I recommend biting the bullet and going with xlC++.

FWIW,
-Steve Huston

From: Chris Whelan [mailto:chris.whe...@systemsandsoftware.net]
Sent: Tuesday, December 16, 2014 3:54 PM
To: users@qpid.apache.org
Subject: Compiling qpid on aix 6.1 with gcc 4.8.2 (or gcc 4.8.3)

Hello,

We have been struggling mightily to get qpid to compile on aix 6.1 with gcc.  
We have tried both 4.8.2 and 4.8.3 and the error we have run into is:

/home/dbapi/enquesta_5_0/qpid-cpp-0.30/src/qpid/sys/posix/PosixPoller.cpp:796:2:
 internal compiler error: in function_and_variable_visibility, at ipa.c:868
}}
  ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make: 1254-004 The error code from the last command is 1.

This appears to be a problem with gcc itself rather than qpid code, but since 
we are utilizing the latest version of the gcc compiler I could find for aix 
and it still does not work, any help in providing a workaround would be greatly 
appreciated.  My coworker was able to identify the problematic lines.  Two of 
the errors appear to be related to the use of the PollerHandleDeletionManager 
(Line 701 and 712) and  Event (Line 729)

PollerHandleDeletionManager.destroyThreadState();  (2 occurrences)
Event event = impl->eventStream.next(timeout);  (1 occurrence)

When he commented out those lines (and additional affected code in the case of 
the Event line), the compilation of PosixPoller.cpp succeeded.  We surmised 
that it has something to do with gcc handling of namespaces, but could not come 
up with a way to get around this issue.  We are planning on trying IBM's xlc 
compiler, but we have invested a lot of time in this already and would like to 
avoid xlc licensing costs if possible.

Thanks in advance,

Regards,

Chris Whelan

RE: Welcome Dominic Evans as a Qpid committer

[Steve Huston]

Congratulations and welcome, Dominic!

> -Original Message-
> From: Robbie Gemmell [mailto:rob...@apache.org]
> Sent: Monday, December 15, 2014 6:04 AM
> To: users@qpid.apache.org; pro...@qpid.apache.org
> Subject: Welcome Dominic Evans as a Qpid committer
> 
> The Apache Qpid PMC have voted to grant commit rights to Dominic Evans in
> recognition of his contributions to and involvement with Proton.
> 
> Welcome, Dominic!
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional
> commands, e-mail: users-h...@qpid.apache.org

RE: Does RH MRG End of Life have an Effect on QPID?

[Steve Huston]

Hi Tom,

I don't speak for Red Hat, but I can say that Red Hat != Apache Qpid. The 
Apache Qpid future is still bright with plenty of effort behind it on all the 
various facets (C++, Java, proton, dispatch, etc.)

I have customers that have placed large bets on Apache Qpid-based systems. They 
expect returns.

-Steve Huston

> -Original Message-
> From: tom peterson [mailto:2tompeter...@gmail.com]
> Sent: Thursday, December 04, 2014 1:24 PM
> To: users@qpid.apache.org; d...@qpid.apache.org
> Subject: Does RH MRG End of Life have an Effect on QPID?
> 
> It seems RH is EOL'ing MRG and is pushing A-MQ (ActiveMQ underneath) as
> their enterprise messaging solution.  Does this change in direction have an
> effect QPID's status moving forward?   We are looking at using QPID on a
> project but want to make sure that it is not being EOL'd as well.
> 
> Thanks for any advice you can render.
> 
> tom

RE: Qpid client disconnect notification

[Steve Huston]

(Adding users@ to get more input)

> -Original Message-
> From: srodof [mailto:sfodor...@gmail.com]
> Sent: Friday, December 05, 2014 11:16 AM
> To: d...@qpid.apache.org
> Subject: Qpid client disconnect notification
> 
> I have a qpid sender c++ and multiple qpid receivers in Java, using c++
> broker.
> 
> I would like to know in c++ every time a java client disconnect.
> 
> Looking into this forum i found that creating a c++ receiver that listens to
> qmf.default.topic/agent.ind.event.org_apache_qpid_broker.#;
> {node:{type:topic}}
> i get every disconnect msg on the broker.
> 
> The problem is that the disconnect msg doesn't provide the topic name or
> the username. For some reason reports user:anonymous, which is wrong.

What auth mechanism did the Java client use? The username used in that 
authentication is what should be reported.

-Steve


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

Re: iOS Support?

[Steve Huston]

Hi Marcel,

No. The persistence functionality would be a part of the broker, though, not 
the client side. Feel free to reply to explain more about what you are looking 
for in terms of features.

-Steve

> On Nov 26, 2014, at 4:31 AM, Marcel Ruff  wrote:
> 
> Hi,
> 
> does the AMQP C/C++ client library with persistent queueing (sqlite?) work 
> fine on iPhone and iPad?
> 
> Thank you
> Marcel

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

Re: Welcome Ernie Allen as a Qpid committer

[Steve Huston]

Welcome Ernie!

Steve Huston
(sent from my iPhone - please excuse brevity and typos)

> On Nov 21, 2014, at 4:29 AM, Gordon Sim  wrote:
> 
> The Qpid PMC have voted to grant commit rights to Ernie Allen in
> recognition of his contributions to the project.
> 
> Welcome Ernie, and thank you for your continued support for Apache Qpid!
> 
> --Gordon.
> 
> -
> 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: Proton release planning

[Steve Huston]

Great - thanks - I can see it now.

Question on the goals... does the API stabilization item include additional API 
exposed from Proton to detect frame boundaries needed for websockets 
implementations?

Thanks,
-Steve

> -Original Message-
> From: Rafael Schloming [mailto:r...@alum.mit.edu]
> Sent: Tuesday, October 28, 2014 4:23 PM
> To: users@qpid.apache.org
> Subject: Re: Proton release planning
> 
> I'm not sure exactly what's going on. The link seems to randomly work
> sometimes and not work at other times. I did just check it in only a few
> minutes ago, so (random guess) maybe the svnpubsub process has only
> partially updated whatever cluster serves those pages. I hope it will 
> stabilize
> soon, but until then you can read the source for the document here if you
> want:
> 
> 
> http://svn.apache.org/repos/asf/qpid/site/input/proton/development.md
> 
> --Rafael
> 
> On Tue, Oct 28, 2014 at 4:01 PM, Steve Huston 
> wrote:
> 
> > The requested URL /proton/development.html was not found on this
> server.
> >
> > > -Original Message-
> > > From: Rafael Schloming [mailto:r...@alum.mit.edu]
> > > Sent: Tuesday, October 28, 2014 4:00 PM
> > > To: pro...@qpid.apache.org; d...@qpid.apache.org;
> > > users@qpid.apache.org
> > > Subject: Proton release planning
> > >
> > > Hi Everyone,
> > >
> > > I'd like to try to get the proton releases to be a bit more
> > > frequent,
> > and I'm
> > > also trying to get a bit more up front planning into them. To that
> > > end
> > I've put
> > > together a quick description of what I'd propose for timeline and
> > > scope
> > of
> > > the next release here:
> > >
> > >   http://qpid.apache.org/proton/development.html
> > >
> > > Please have a look and let me know what you think.
> > >
> > > --Rafael
> >

RE: Proton release planning

[Steve Huston]

The requested URL /proton/development.html was not found on this server.

> -Original Message-
> From: Rafael Schloming [mailto:r...@alum.mit.edu]
> Sent: Tuesday, October 28, 2014 4:00 PM
> To: pro...@qpid.apache.org; d...@qpid.apache.org; users@qpid.apache.org
> Subject: Proton release planning
> 
> Hi Everyone,
> 
> I'd like to try to get the proton releases to be a bit more frequent, and I'm
> also trying to get a bit more up front planning into them. To that end I've 
> put
> together a quick description of what I'd propose for timeline and scope of
> the next release here:
> 
>   http://qpid.apache.org/proton/development.html
> 
> Please have a look and let me know what you think.
> 
> --Rafael

RE: management compatibilitiy for next release.

[Steve Huston]

I'm in favor of this.
-Steve

> -Original Message-
> From: Alan Conway [mailto:acon...@redhat.com]
> Sent: Monday, October 20, 2014 1:37 PM
> To: users@qpid.apache.org
> Cc: Ted Ross
> Subject: [dispatch] management compatibilitiy for next release.
> 
> I'd like to make some incompatible changes to naming of management
> classes, entities and attributes:
> - consistency: use of camelCase for management attribute and class names
> (currently a mix of foo-bar, foo_bar and fooBar)
> - uniqueness: prefix entity names with type (e.g. link & router names are just
> numbers so use link:0 and router:0 instead of just 0)
> 
> I propose the following for the next release:
> - move to the new management agent by default, release note changes.
> - note that old agent is still available at $cmanagement
> - note that old agent is deprecated and will be removed in the following
> release.
> 
> Any thoughts?
> 
> Cheers,
> Alan.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional
> commands, e-mail: users-h...@qpid.apache.org

RE: Duplicate Messages

[Steve Huston]

Hi Raphael,

> I am new to Qpid, starting to work on an extensive projects code base.

Welcome!

> I am trying to find the spot in the documentation where guarantees of the
> messaging system are discussed. For example: in case of a network problem,
> could it happen that the broker sends the same message twice?

Yes:
http://qpid.apache.org/releases/qpid-0.30/programming/book/acknowledgements.html

> There is some duplicate checking and I would like to confirm it is necessary.

Yes, it is.

-Steve Huston

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

RE: [VOTE] Migrate the repo for the new JMS client work to use Git

[Steve Huston]

+1

> -Original Message-
> From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com]
> Sent: Tuesday, September 16, 2014 12:35 PM
> To: users@qpid.apache.org
> Subject: [VOTE] Migrate the repo for the new JMS client work to use Git
> 
> Hello all,
> 
> I mentioned this briefly in a previous thread, and have decided just to call a
> vote on the subject. I would like to migrate the repo for the new JMS client
> work to use Git rather than Subversion.
> 
> This wont affect the rest of the Qpid codebase, though it could be viewed as
> a test for any such move in future. Only the bits in the following subtree are
> under consideration for migation at this time:
> http://svn.apache.org/repos/asf/qpid/jms/
> 
> I believe it would make things easier for those of us currently working on it,
> and ease future usage of things like the Github integration we can/should
> have Apache infra enable. For anyone still wanting to use a Subversion client
> to check things out, there will still be an option there as e.g. Github repos 
> can
> also be checked out with svn clients, and Apache mirror things to Github.
> 
> Please cast your votes. Even if you don't intend to work on the code in
> question, please vote or at least contribute your thoughts to any discussion
> that pops up. I will tally the votes after this point on Friday, i.e. 72hrs.
> 
> Robbie

RE: REQEST FEEDBACK Re: How to test the performance quid c++ broker

[Steve Huston]

> -Original Message-
> From: Fraser Adams [mailto:fraser.ad...@blueyonder.co.uk]
> Sent: Friday, July 25, 2014 1:22 PM
> To: users@qpid.apache.org
> Subject: Re: REQEST FEEDBACK Re: How to test the performance quid c++
> broker
> 
> On 25/07/14 17:27, Steve Huston wrote:
> >
> > I believe that the person likely to be downloading qpid source is a
> > developer. It is likely a developer that does not want to become
> > intimately familiar with debugging Qpid - they just want it to work
> > without asking questions. But it is a person who may need a sensible
> > stack trace, line numbers, etc. to at least post back here if
> > something goes amiss. They will, after all, need to be testing their
> > own software that uses Qpid and may have occasion to ask things here.
> >
> > When things are all debugged and ready to deploy, the user may want to
> > rebuild w/o debinfo, but if not, it will still perform very well in
> > the field.
> >
> > -Steve
> >
> >
> I don't agree with the assertion "the person likely to be downloading qpid
> source is a developer " - well perhaps a developer of some persuasion, but I
> certainly don't agree that they are necessarily a
> *qpid* developer.

I didn't say *qpid* developer  - but qpid doesn't do anything on its own - 
someone has to write code to do something with qpid.

> The only way I'd feel happy defaulting to a build with debug symbols or
> otherwise unstripped is if the build informed the users that this was the 
> case.
> I truly believe that the most common use case for an average user is to want
> to download, build and enjoy and they should have a reasonable expectation
> of a build that is shipable to a mission critical operational environment
> without having to work out some (likely
> undocumented) magic incantation.
> 
> It's not just about the performance, accidentally shipping operational code
> with debug symbols is bad practice IMHO.

As Andrew said, the debug info is generally a separate file. After you've spent 
some night being called in on a problem and you have _nothing_ to go on but hex 
stack, you will fight to the death to get debug info in all future projects. 
Trust me :-)  Back in the day, as they say, all we had was hex stack and a link 
map. And compile code generation listings. On green bar paper. I ain't goin 
back there.

-Steve

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

Re: REQEST FEEDBACK Re: How to test the performance quid c++ broker

[Steve Huston]

On 7/25/14, 12:13 PM, "Alan Conway"  wrote:

>On Fri, 2014-07-25 at 16:47 +0100, Fraser Adams wrote:
>> 
>> On 25/07/14 15:30, Alan Conway wrote:
>> > On Thu, 2014-07-24 at 17:31 +0100, Fraser Adams wrote:
>> >> On 24/07/14 13:59, Alan Conway wrote:
>> >>> Very important point I forgot to mention: are you doing a release
>> >>> build?
>> >>>
>> >>> cmake -DCMAKE_BUILD_TYPE=Release
>> >>>
>> >>> That makes a big difference. It enables optimization flags for the
>>C++
>> >>> compiler. The default is not optimized.
>> >>>
>> >> Alan,
>> >> I've mentioned this before, but I remain unconvinced that the
>>default 
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>   
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>   
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>   
>>  
>> 
>> >> should be for an unoptimised build. I totally realise that seems to
>>be
>> >> "the CMake way", but it always used to be the case under automake
>>that
>> >> the default was something reasonably optimised.
>> >>
>> >> If it turns out that your suggestion is indeed the cause of the
>> >> discrepancy I think that would back up the view that *at the very
>>least*
>> >> the documentation for doing the build should mention this and if
>>there
>> >> is still a general view to default to the unoptimised I actually
>>think
>> >> that the CMake for qpid and proton should display a warning to remind
>> >> users that they are using an unoptimised build.
>> > I agree (not sure why I didn't before, probably not paying attention.)
>> > The default actually isn't any of the advertised build types (Debug,
>> > Release etc.) it's a "just ignore opt/debug flags" build which is not
>> > especially useful for anything. I never use it.
>> >
>> > So I vote for making the default build type Release. Someone who finds
>> > performance sucks is more likely to leave without asking questions
>>than
>> > someone who has trouble with their debugger (and since the default
>> > doesn't set -g anyway that doesn't appear to be a problem.)
>> >
>> > Any counter opinions? (as always, I assume silence is consent :)
>> >
>> > Cheers,
>> > Alan.
>> >
>> >
>> Thanks for this discussion Alan!
>> 
>> My vote would be to default to the most optimised/operational-quality
>> build possible. My reasoning being that I suspect that *most* people
>>(if 
>> not all) coming in fresh would have a not unreasonable expectation that
>> qpid would "just work" and moreover would "just work" at its best. Your
>> "leave without asking questions" point is something that as a community
>> I believe that we must have high on our list of things to avoid!
>> 
>> If the RelWithDebInfo is exactly as fast then that's probably OK, but
>>if 
>> I'm honest I believe that the default should really be to build
>> something that a user might want to ship in an operational
>> mission-critical system and I'm not personally keen on the idea of
>> shipping with debug symbols or anything else that could potentially
>> increase an attack vector.
>> 
>> I'm more than happy that we supply documentation that tells users how
>>to 
>> enable debugging etc. but all of that is really developer focussed IMHO
>> and I think that the default should be fir

Re: REQEST FEEDBACK Re: How to test the performance quid c++ broker

[Steve Huston]

Exactly - I agree with Andrew.

On 7/25/14, 10:46 AM, "Andrew Stitcher"  wrote:

>On Fri, 2014-07-25 at 10:30 -0400, Alan Conway wrote:
>> ...
>> So I vote for making the default build type Release. Someone who finds
>> performance sucks is more likely to leave without asking questions than
>> someone who has trouble with their debugger (and since the default
>> doesn't set -g anyway that doesn't appear to be a problem.)
>> 
>> Any counter opinions? (as always, I assume silence is consent :)
>
>I think that RelWithDebInfo is more generally useful - it gives you
>nearly all the optimisation you want and debugging symbols for when you
>screw up!
>
>Andrew
>
>


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

FW: [amqp-bindmap] 30-day Public Review for Advanced Message Queuing Protocol (AMQP) WebSocket Binding (WSB) Version 1.0 - ends July 19th

[Steve Huston]

I haven’t seen this come around to the Qpid users list, so am forwarding it 
directly.
-Steve

From: amqp-bind...@lists.oasis-open.org 
[mailto:amqp-bind...@lists.oasis-open.org] On Behalf Of Paul Knight
Sent: Thursday, June 19, 2014 4:10 PM
To: tc-annou...@lists.oasis-open.org; memb...@lists.oasis-open.org; 
amqp-bind...@lists.oasis-open.org; a...@lists.oasis-open.org; 
amqp-bindmap-comm...@lists.oasis-open.org
Subject: [amqp-bindmap] 30-day Public Review for Advanced Message Queuing 
Protocol (AMQP) WebSocket Binding (WSB) Version 1.0 - ends July 19th


OASIS members and other interested stakeholders,

The OASIS Advanced Message Queuing Protocol (AMQP) Bindings and Mappings 
(AMQP-BINDMAP) TC [1] members have recently approved a Committee Specification 
Draft (CSD) and submitted it for 30-day public review:

Advanced Message Queuing Protocol (AMQP) WebSocket Binding (WSB) Version 1.0
Committee Specification Draft 01 / Public Review Draft 01
10 June 2014

Overview:

The AMQP WebSocket Binding specification defines a mechanism for tunneling an 
AMQP connection over a WebSocket transport. It is applicable as an approach for 
general firewall tunneling and for Web browser messaging scenarios.

TC Description:

The purpose of the AMQP Bindings and Mappings (AMQP-BINDMAP) TC is to define 
bindings of AMQP 1.0 core protocol to underlying transports other than TCP, to 
define mappings of the AMQP 1.0 core protocol to existing well-known 
programming APIs, and to define representations of the AMQP 1.0 message format 
in existing well-known languages.

For more information, see the TC Charter and FAQ.

Public Review Period:

The public review starts 20 June 2014 at 00:00 GMT and ends 19 July 2014 at 
23:59 GMT.

This is an open invitation to comment. OASIS solicits feedback from potential 
users, developers and others, whether OASIS members or not, for the sake of 
improving the interoperability and quality of its technical work.

URIs:

The prose specification document and related files are available here:

Editable source (Authoritative):
http://docs.oasis-open.org/amqp-bindmap/amqp-wsb/v1.0/csprd01/amqp-wsb-v1.0-csprd01.doc

HTML:
http://docs.oasis-open.org/amqp-bindmap/amqp-wsb/v1.0/csprd01/amqp-wsb-v1.0-csprd01.html

PDF:
http://docs.oasis-open.org/amqp-bindmap/amqp-wsb/v1.0/csprd01/amqp-wsb-v1.0-csprd01.pdf

ZIP distribution file (complete):

For your convenience, OASIS provides a complete package of the prose document 
and related files in a ZIP distribution file. You can download the ZIP file 
here:

http://docs.oasis-open.org/amqp-bindmap/amqp-wsb/v1.0/csprd01/amqp-wsb-v1.0-csprd01.zip

Additional information about the specification and the OASIS Advanced Message 
Queuing Protocol (AMQP) Bindings and Mappings (AMQP-BINDMAP) TC can be found at 
the TC's public home page:

https://www.oasis-open.org/committees/amqp-bindmap/

Comments may be submitted to the TC by any person through the use of the OASIS 
TC Comment Facility which can be used by following the instructions on the TC's 
"Send A Comment" page, or directly at:

https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=amqp-bindmap

Comments submitted by TC non-members for this work and for other work of this 
TC are publicly archived and can be viewed at:

https://lists.oasis-open.org/archives/amqp-bindmap-comment/

All comments submitted to OASIS are subject to the OASIS Feedback License, 
which ensures that the feedback you provide carries the same obligations at 
least as the obligations of the TC members. In connection with this public 
review of "Advanced Message Queuing Protocol (AMQP) WebSocket Binding (WSB) 
Version 1.0", we call your attention to the OASIS IPR Policy [2] applicable 
especially [3] to the work of this Technical Committee. All members of the TC 
should be familiar with this document, which may create obligations regarding 
the disclosure and availability of a member's patent, copyright, trademark and 
license rights that read on an approved OASIS specification.

OASIS invites any persons who know of any such claims to disclose these if they 
may be essential to the implementation of the above specification, so that 
notice of them may be posted to the notice page for this TC's work.

== Additional references:

[1] OASIS Advanced Message Queuing Protocol (AMQP) Bindings and Mappings 
(AMQP-BINDMAP) TC
https://www.oasis-open.org/committees/amqp-bindmap/

[2] https://www.oasis-open.org/who/intellectualproperty.php

[3] https://www.oasis-open.org/committees/amqp-bindmap/ipr.php
https://www.oasis-open.org/policies-guidelines/ipr#s10.2.2
RF on RAND Mode

--
Paul Knight  - Tel: +1 781-861-1013
OASIS - Advancing open standards for the 
information society
Document Process Analyst

RE: Ruby qpid client + SSL 'Unknown protocol'

[Steve Huston]

Great - thanks for the follow-up Wesley!

> -Original Message-
> From: Wesley Holevinski [mailto:wes...@adaptiveapps.com]
> Sent: Tuesday, March 18, 2014 12:04 PM
> To: users@qpid.apache.org
> Subject: RE: Ruby qpid client + SSL 'Unknown protocol'
> 
> All,
> 
> Found it! After thinking about it more, I was setting those environment
> variables after loading the gem.  Setting the ENV variables (specifically the
> one to load the ssl connector) before requiring the gem did the trick.
> 
> Thanks,
> Wes
> 
> From: Wesley Holevinski [wes...@adaptiveapps.com]
> Sent: Tuesday, March 18, 2014 11:47 AM
> To: users@qpid.apache.org
> Subject: Ruby qpid client + SSL 'Unknown protocol'
> 
> Hi all,
> 
> I'm having issues getting my ruby client to connect over SSL.  I'm getting 
> this
> error:
> 
> irb(main):014:0> c = Qpid::Messaging::Connection.new(:url =>
> 'localhost:1', :options=>{:transport=>'ssl'}) =>
> # @options={"transport"=>"ssl"},
> @connection_impl=#>
> irb(main):015:0> c.open()
> MessagingError: Unknown protocol: ssl (qpid/client/Connector.cpp:52)
> 
> To establish a baseline, I've gotten SSL clients working in python, C++, and
> Java so far.  I'm working with the qpid_messaging 0.18.5 gem.
> 
> I have qpid-cpp-client-ssl and server-ssl installed.  RPM list:
> 
> $ rpm -qa | grep qpid | sort
> python-qpid-0.18-9.el6.noarch
> python-qpid-qmf-0.18-20.el6.x86_64
> qpid-cpp-client-0.18-20.el6.x86_64
> qpid-cpp-client-devel-0.18-20.el6.x86_64
> qpid-cpp-client-ssl-0.18-20.el6.x86_64
> qpid-cpp-server-0.18-20.el6.x86_64
> qpid-cpp-server-ssl-0.18-20.el6.x86_64
> qpid-qmf-0.18-20.el6.x86_64
> qpid-tools-0.18-10.el6.noarch
> 
> I've tried setting the following so that the cqpid extension (and presumably
> the qpid library underneath) would pick these up:
> 
> ENV['QPID_SSL_CERT_DB'] = '/nfs_home/wholevinski/ssl_test/client_db'
> ENV['QPID_SSL_CERT_NAME'] = 'QpidCppClient'
> ENV['QPID_SSL_CERT_PASSWORD_FILE']='/nfs_home/wholevinski/ssl_test/
> qpid-broker-pfile'
> ENV['QPID_LOAD_MODULE'] = '/usr/lib64/qpid/client/sslconnector.so'
> 
> I don't think I've reached a point where the first 3 ENV variables are even
> relevant yet though; my hunch is that the sslconnector.so isn't being loaded,
> and the protocolRegistry inside qpid/client/Connector.cpp isn't updated.
> 
> If anyone has any experience with SSL + a ruby client and has any ideas, or
> insight into what I might be doing wrong, please let me know.
> 
> Thanks!
> Wes
> 
> -
> 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: Does broker federation work with azure service bus?

[Steve Huston]

It won't work.

-Steve

> On Mar 4, 2014, at 9:18 PM, "smartdog"  wrote:
> 
> We need post some messages to Azure Service Bus and figure it would be nice
> (in case Azure service bus is down) to post messages to the local qpid
> broker first and then let the broker propagate messages to Azure. 
> 
> I tried with 
> 
> qpid-route -d queue add azureuser/passw...@namespace.servicebus.windows.net
> 127.0.0.1:5672 amq.fanout brokerqueue 
> 
> and got Failed: VersionError - client: 0-10, server: 0-0 
> 
> It seems related with version conflict (Azure supports amqp 1.0, while
> broker is amqp 0-10) 
> 
> Any idea or this just won't work? Thanks. 
> 
> 
> 
> --
> View this message in context: 
> http://qpid.2158936.n2.nabble.com/Does-broker-federation-work-with-azure-service-bus-tp7605140.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
> 

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

RE: RE: Unable to build SSL component

[Steve Huston]

I _think_ Qpid is packaged by Red Hat for RHEL 6.3 - you may want to check RHN 
or your distro before trying to build it yourself.

If you do need to build it, we need to see the configure output and the make 
output (esp the section that fails).

-Steve

> -Original Message-
> From: coolness_2...@yahoo.com [mailto:coolness_2...@yahoo.com]
> Sent: Thursday, February 20, 2014 7:09 PM
> To: users@qpid.apache.org
> Subject: Re: RE: Unable to build SSL component
> 
> Hello Steve,
> 
> I'm currently using Qpid 0.18 on Red Hat 6.3 with gcc 4.4.6. I'm using the old
> bootstrap and configure method. Nothing special when running configure
> (just setting m32 to the CFLAGS, CXXFLAGS, and LDFLAGS to specify 32-bits
> build as well setting the prefix for the make install). You probably will need
> some more information so please let me know what you need. Hopefully,
> this will help. Thanks.
> 
> Regards,
> Jeremy


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

RE: Unable to build SSL component

[Steve Huston]

Hi Jeremy,

I'm afraid we're going to need more info in order to help you.

What Qpid version, OS/compiler do you have, and what is the complete output 
from cmake?

Thanks,
-Steve

> -Original Message-
> From: coolness_2...@yahoo.com [mailto:coolness_2...@yahoo.com]
> Sent: Thursday, February 20, 2014 6:40 PM
> To: users@qpid.apache.org
> Subject: Re: Unable to build SSL component
> 
> Hello,
> 
> Sorry, I got sidetracked, but I'm now looking into this. I did run the command
> and got the following output:
> 
> -I/usr/include/nss3
> -Wl,-rpath-link,/usr/lib -L/usr/lib -lssl3 -lsmime3 -lnss3 -lnssutil3
> 
> Could I be missing other packages? Thanks!
> 
> Regards,
> Jeremy


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

Re: Qpid website update

[Steve Huston]

Great! Thanks!

-Steve

> On Feb 7, 2014, at 7:38 AM, "Justin Ross"  wrote:
> 
>> On Tue, Feb 4, 2014 at 4:23 PM, Steve Huston  wrote:
>> On the Contributors page, in thanks section, it would be good to mention 
>> Coverity for allowing us use of Coverity Scan to do static analysis.
> 
> You're right, of course!  I've added them to the companies section of
> the contributors page:
> 
>  http://people.apache.org/~jross/transom/head/contributors.html#companies
> 
> Justin
> 
> -
> 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 website update

[Steve Huston]

Cursory check on ipad looks good.

On the Contributors page, in thanks section, it would be good to mention 
Coverity for allowing us use of Coverity Scan to do static analysis.

-Steve

> On Feb 4, 2014, at 4:11 PM, "Justin Ross"  wrote:
> 
> Hi, everyone.  I've got a pending website update up for review.
> 
>  http://people.apache.org/~jross/transom/head/
> 
> There are a number of changes.  I have summarized them below.
> 
> Please take a look and tell me how it works for you.  In particular,
> I'd be interested to know how it functions on any mobile devices you
> have.
> 
> I will be testing the update this week in preparation for committing
> it after the 0.26 vote closes.
> 
> Thanks,
> Justin
> 
> ---
> 
> Navigation
> 
> - Up in the top right there is now a "hamburger menu".  This is
> useful I think in general, but it's particularly important for mobile
> devices, where a lot more scrolling is required to reach any
> navigation further down the page.  The developer center is now linked
> from inside this menu instead of the bottom of the home page.
> - Search is also changed a little: it will pop down without an
> additional HTTP request.
> - I moved the information on notification lists to "Notifications"
> sections on the issues and source code pages.  The source code page
> now holds the "Continuous integration" section as well.
> 
> Mobile
> 
> - The full site is now available in landscape on ~5-inch phones
> - The navigation links at the top progressively disappear to
> accommodate smaller and smaller viewports
> 
> Visual refresh
> 
> - The site handles overlong tables and preformatted content better,
> by using horizontal scrolling when necessary
> - Various minor improvements to the docbook rendering
> - The page now scales to a greater width
> - Avoid awkward column breaks between section headings and content
> - Many other small tweaks
> 
> Page load performance
> 
>   I used Google's PageSpeed tool to analyze page performance.
> 
> - Defer javascript load until after the page is loaded
> - Defer template image loads
> - Minify output CSS using cssmin (note that this introduces a
> dependency on python-cssmin)
> - Where it does not impact above-the-fold layout, defer CSS loading as well
> - Use cache headers that work for older browsers
> - Apply response compression more broadly
> 
> -
> 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: Can you please help to clarify my doubts in HA cluster managing

[Steve Huston]

Hi Xiong,

> Thanks a lot Steve and Alan, appreciate your prompt helps.

You're welcome.

> I guess I have not posted my ideas clearly. Let me describe it below for your
> better information.
> 
> After going through the link provided by Alan, I realize that HA is only to
> group two nodes into a cluster for high availability. Clients or Exchanges 
> need
> to connect to virtual IP for message communication. QPID Messaging Bus
> itself is HA, but Clients or Exchanges connect to QPID are not automatically
> HA ready. Please correct me if my understanding is wrong.

That's basically right, but Exchanges don't connect to Qpid - an Exchange is a 
AMQP 0-10 artifact that is managed by Qpid broker. The client connects to the 
broker and sends messages to an exchange. As such, the Exchange is part of the 
HA broker.

> What we are intended to achieve is that we have two physical boxes, one
> box shall have a server instance, for example a billing utility, running as
> primary service provider, another box shall have an identical billing utility
> running which is a hot-backup of the primary one. Messages passed to
> primary instance will be processed as normal, while messages duplicated to
> backup instance will be processed and update its internal status only. Once
> Primary instance or primary box is down, backup instance or box will take
> over. Is there any existing mechanism provided by QPID to achieve this
> purpose to ease our effort?

First, to run an HA cluster that can continue to function when one dies you 
should have at least 3 nodes. (That's a clustering issue,  not limited to Qpid).

Assuming you have a cluster that can continue to function when one node dies, 
one of the passive brokers will be promoted to primary/active and continue to 
provide service.

Your client (billing utility) would see the connection to the broker go down. 
It could then be re-established when the new broker becomes active. If you are 
running the client on the same node as the broker, you will need to design an 
HA solution for the client as well. You could take advantage of the clustering 
facilities for this. I would recommend you study the RH clustering docs for 
information on your options.

-Steve


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

RE: Ubuntu packages for Qpid 0.24

[Steve Huston]

I have some experience with supporting a customer with fairly demanding 
messaging needs and they were using the active-active cluster mechanism. 
They're very happy to be on active-passive now.

If you'd like to talk further about why you think active-active is a better 
choice, I'd be happy to discuss here or privately - whichever you prefer.

-Steve

> -Original Message-
> From: Listas@Adminlinux [mailto:lis...@adminlinux.com.br]
> Sent: Tuesday, January 07, 2014 9:03 AM
> To: users@qpid.apache.org
> Subject: Re: Ubuntu packages for Qpid 0.24
> 
> 
> In my company we chose Qpid because your active-active cluster feature.
> This is important in our environment. But the Qpid-0.24 only supports active-
> passive cluster.
> 
> Does support for active-active cluster will come back in the future?
> Thanks!
> 
> Em 02-01-2014 17:51, Andrew Stitcher escreveu:
> > On Thu, 2014-01-02 at 16:54 -0200, Listas@Adminlinux wrote:
> >> Hi,
> >>
> >> I'm trying to generate Qpid-0.24 packages for Ubuntu 12.04.
> >>
> >> It was configured as follows:
> >>./configure --with-sasl --with-xml --with-rdma --with-ssl
> >> --with-swig --libexecdir='/usr/lib' --enable-fast-install
> >> --enable-deprecated-autotools
> >>
> >> But some plugins are not compiled: sslconnector.so for client;
> >> acl.so, cluster.so, replicating_listener.so, replication_exchange.so,
> >> ssl.so and watchdog.so for daemon.
> >>
> > These changes are what you should expect for 0.24:
> >
> > The ssl and acl plugins have been directly subsumed by the qpidd
> > executable and so are no longer plugins.
> >
> > The old active-active clustering has been replaced with active-passive
> > in a completely new implementation. This removed the other plugins and
> > added a new plugin - ha.so
> >
> > If you are generating new packages you will need to adjust the
> > packaging specification it to take account of this change in files.
> >
> > 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


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

RE: Can you please help to clarify my doubts in HA cluster managing

[Steve Huston]

Hi Xiong,

> Hi All,
> 
> Here is a newbie to QPID.

Welcome!

> I am planning to setup a HA cluster with the QPID
> as its underlying messaging layer. After going through all Apache QPID online
> documenation, I am unable to find the solution to my following
> question:
> 
>How can an Exchange on the Passive Node in the cluter knows that it
> resides in a passive broker and need to handle incoming messages
> differently that when it has been actived as primary node?

The active broker will receive all the messages.
The usual way this is handled is for a virtual IP address to be assigned for 
the cluster's brokers - the address is assigned to the node where the active 
broker is running. Thus, all connections to the virtual IP address go to the 
active broker.

> Can we get such information with C++ API classes? I have checked class
> Connection, Session and Message. They seem not having such API calls.

The API doesn't know about HA, by design.

> Can you please help?

If this doesn't answer what you need, please ask again.

> Thanks a lot in advance!

You're welcome.

-Steve Huston


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

RE: Windows Mobile 6.5

[Steve Huston]

Hi Ryan,

The users list is the best place for this type of question.

You actually may want to consider the AMQP Messenger API in the Proton kit - 
that would get you AMQP 1.0 via a C API. Again, nobody has tried that on Win 
Mobile that I know of, but it does run on Windows.

-Steve

> -Original Message-
> From: Ryan Finnesey [mailto:r...@finnesey.com]
> Sent: Thursday, December 05, 2013 10:17 PM
> To: users@qpid.apache.org; d...@qpid.apache.org
> Subject: Windows Mobile 6.5
> 
> I was not certain if this should be posted to the Users or Developers list 
> but I
> wanted to get the group(s) thoughts on my options on implementing  AMQP
> 1.0 within a Windows Mobile 6.5 Application.The development
> environment  is .net  CF 3.5.  I need to be able to connect to the Azure
> Service Bus.
> 
> Cheers
> Ryan
> 
> 
> -
> 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: Does Qpid restricts simultaneous access to a queue for two or more applications ?

[Steve Huston]

Thank you for the correction Gordon!

> -Original Message-
> From: Gordon Sim [mailto:g...@redhat.com]
> Sent: Thursday, December 05, 2013 5:09 AM
> To: users@qpid.apache.org
> Subject: Re: Does Qpid restricts simultaneous access to a queue for two or
> more applications ?
> 
> On 12/04/2013 08:01 PM, Steve Huston wrote:
> > No.
> 
> Unless you ask it to(!). There is an exclusive flag on queue to restrict other
> usage where that is important. This is on by default for subscription queues
> (i.e. the queue automatically created by the qpid messaging library when
> receiving messages from an exchange rather than directly from a shared
> queue).
> 
> 
> >> -Original Message-
> >> From: Listas [mailto:lis...@adminlinux.com.br]
> >> Sent: Wednesday, December 04, 2013 2:21 PM
> >> To: users@qpid.apache.org
> >> Subject: Does Qpid restricts simultaneous access to a queue for two
> >> or more applications ?
> >>
> >> Hi,
> >>
> >> Does Qpid restricts simultaneous access to a queue for two or more
> >> applications ?
> >> I have a "ubuntu12.04 + qpidd-0.14-2 + qpidd-msgstore-0.14-1" cluster.
> >>
> >>
> >> Thanks.
> >> --
> >> Thiago Henrique
> >> adminlinux.com.br
> >>
> >> -
> >> 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


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

RE: Does Qpid restricts simultaneous access to a queue for two or more applications ?

[Steve Huston]

No.

> -Original Message-
> From: Listas [mailto:lis...@adminlinux.com.br]
> Sent: Wednesday, December 04, 2013 2:21 PM
> To: users@qpid.apache.org
> Subject: Does Qpid restricts simultaneous access to a queue for two or more
> applications ?
> 
> Hi,
> 
> Does Qpid restricts simultaneous access to a queue for two or more
> applications ?
> I have a "ubuntu12.04 + qpidd-0.14-2 + qpidd-msgstore-0.14-1" cluster.
> 
> 
> Thanks.
> --
> Thiago Henrique
> adminlinux.com.br
> 
> -
> 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 0.14 messaging times

[Steve Huston]

This is a bit of a SWAG but you may be seeing effects of Nagle's algorithm. I 
believe the default for --tcp-nodelay changed to "on" sometime after your 
version. You may want to try that on both the client and broker side.

-Steve

> -Original Message-
> From: Toralf Lund [mailto:toralf.l...@pgs.com]
> Sent: Wednesday, November 27, 2013 9:26 AM
> To: users@qpid.apache.org
> Subject: QPid 0.14 messaging times
> 
> Hi.
> 
> I'm testing pretty standard (I think) request-response type setup for
> communication between two processes, using QPid 0.14 (AMQP 0.10).
> Messaging is implemented via a the C++ Messaging API, and the broker is
> qpidd from qpid-cpp-server. All running under CentOS 6.4. Messages are
> typically quite small - contents are often just 2-3 bytes, but there are 
> couple
> of headers as well.
> 
> Question: What sort of transfer times should I expect for my setup? When
> testing with all processes on the same machine, and a broker used
> exclusively for this purpose, I get a round-trip time of up to 80 ms, or 
> slightly
> more, which is a bit longer than I expected. Furthermore, closer inspection
> seems to reveal that I get either of the following 4
> scenarios:
> 
>  1. (Worst case) The request message takes around 40 ms to reach the
> "server", and the response 40 ms to get back to the client - for a
> total time of around 80 ms.
>  2. The request message takes around 40 ms, but the response is very
> fast, perhaps the transfer time is 1 ms or so. So the total time is
> 40 ms or so.
>  3. As above, only the other way around (fast request, slower response.)  4.
> The request and response are both very fast, giving nearly
> instantaneous feedback.
> 
> 2 and 3 are the most common of these.
> 
> So, is this as expected, or should I expect faster transfers? Where might the
> 40 ms come from?
> 
> I suppose I should provide some code here, but it will take a while to
> prepare, so I thought I might ask some general questions first...
> 
> As for QPid version, I'm using 0.14 simply because it seems to be the most
> recent available on standard software depositories for the system, but
> upgrading to a more recent release may of course be an option.
> 
> Thanks,
> 
> 
> - Toralf
> 
> 
> This e-mail, including any attachments and response string, may contain
> proprietary information which is confidential and may be legally privileged. 
> It
> is for the intended recipient only. If you are not the intended recipient or
> transmission error has misdirected this e-mail, please notify the author by
> return e-mail and delete this message and any attachment immediately. If
> you are not the intended recipient you must not use, disclose, distribute,
> forward, copy, print or rely on this e-mail in any way except as permitted by
> the author.

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

RE: Proof of Concept JavaScript Proton implementation.

[Steve Huston]

+2 :-)

> -Original Message-
> From: Ted Ross [mailto:tr...@redhat.com]
> Sent: Tuesday, November 19, 2013 3:38 PM
> To: users@qpid.apache.org
> Subject: Re: Proof of Concept JavaScript Proton implementation.
> 
> +1
> 
> I'd be very interested in seeing this checked in on a branch.
> 
> -Ted
> 
> On 11/19/2013 03:33 PM, Robbie Gemmell wrote:
> > I think its worth mentioning that branches are ideally suited to this
> > sort of workwhether it actually ends up on trunk or not in the
> > end, theres no need to keep things local until it is actually ready
> > for landing on trunk...
> >
> > Robbie
> >
> > On 19 November 2013 19:56, Fraser Adams
> wrote:
> >
> >> Hey all,
> >> For the last couple of weekends I've been working on a Proof of
> >> Concept JavaScript implementation of Proton.
> >>
> >> The approach that I've taken is (I think) quite interesting/unusual
> >> but it's an approach that offers a high level of synergy with
> >> implementations for other languages that are essentially bindings to
> proton-c.
> >>
> >> The "magic elixir" in this is the downright amazing emscripten
> >> https://github.com/kripken/emscripten/wiki which (believe it or not)
> >> is essentially a cross-compiler that can compile C/C++ to JavaScript.
> >> Moreover the JavaScript that it compiles to is a particular subset
> >> called asm.js http://asmjs.org/ which can be extremely aggressively
> >> optimised and is subject to a lot of research by Mozilla in
> >> particular (the main emscripten maintainer is actually a Mozilla
> >> researcher, though I believe emscripten is something of a side project).
> >>
> >> It's well worth visiting the emscripten page with a modern browser,
> >> the Epic Citadel demo is awesome :-)
> >>
> >> So in a nutshell what I've done is to compile proton-c into
> >> JavaScript
> >>
> >> So I'm underselling it a bit :-) I had to do a fair bit of work to
> >> make it that simple, in particular I had to add/fix a number of
> >> emscripten's library functions (Proton used a few things that weren't
> >> implemented) but the cool thing is that those are now in emscripten for
> everyone's benefit.
> >>
> >> A really nice thing is that I've not actually had to modify any of
> >> the engine/messenger code at all - one I started to figure out what I
> >> was doing wrong that is :-) all I've really needed to to was to
> >> modify send.c/recv.c so that they behave in a non-blocking manner
> >> (you may have seen my mail at the weekend before I finally figured it
> >> out :-))
> >>
> >> I've got CMake able to cross-compile in a repeatable fashion so the
> >> only change to any existing Proton stuff that is required is an
> >> addition to the top-level CMakeLists.txt that detects the presence of
> >> emscripten and its dependencies and if present fires off
> "add_subdirectory(bindings/javascript)"
> >> e.g.
> >>
> >>
> >> # Build the JavaScript language binding.
> >> # This is somewhat different to the other language bindings in that
> >> it does not use swig. It uses a C/C++ to # JavaScript cross-compiler
> >> called emscripten (https://github.com/kripken/ emscripten).
> >> Emscripten takes C/C++ # and "compiles" it into a highly optimisable
> >> subset of JavaScript called asm.js (http://asmjs.org/) that can # be
> >> aggressively optimised and run at near-native speed (usually between
> >> 1.5 to 10 times slower than native C/C++).
> >> option("BUILD_JAVASCRIPT" "Build JavaScript language binding" ON) if
> >> (BUILD_JAVASCRIPT)
> >># First check that Node.js is installed as that is needed by emscripten.
> >>find_program(NODE node)
> >>if (NOT NODE)
> >>  message(STATUS "Node.js (http://nodejs.org) is not installed:
> >> can't build JavaScript binding")
> >>else (NOT NODE)
> >>  # Check that the emscripten C/C++ to JavaScript cross-compiler
> >> is installed.
> >>  find_program(EMCC emcc)
> >>  if (NOT EMCC)
> >>message(STATUS "Emscripten
> >> (https://github.com/kripken/emscripten)
> >> is not installed: can't build JavaScript binding")
> >>  else (NOT EMCC)
> >>add_subdirectory(bindings/javascript)
> >>  endif (NOT EMCC)
> >>endif (NOT NODE)
> >> endif (BUILD_JAVASCRIPT)
> >>
> >>
> >> So the main purpose of this mail is to give a heads up of it and to
> >> ask if it'd be OK to start commiting it and give others some visibility of 
> >> it.
> >>
> >> At this stage it's something of a Proof of Concept, in particular:
> >> * I haven't exported any actual JavaScript bindings so although it's
> >> JavaScript actual JavaScript clients would find it awkward to call
> >> the API as yet.
> >> * As alluded above and at the weekend the demo code I've got calling
> >> messenger isn't especially elegant, I think I know how to get things
> >> behaving more asynchronously, but haven't tried it yet (and my hunch
> >> may be wrong).
> >> * Transport is entirely over WebSockets :-) so I've actually got send
> >> and recv running on Node.js (and also send on 

RE: Proof of Concept JavaScript Proton implementation.

[Steve Huston]

This is great, Fraser! You're certainly an enterprising fellow, eh? :-)

I chair the OASIS AMQP Bindings and Mappings Technical Committee and one of the 
things that TC is doing is developing a spec for AMQP over Websockets. The 
Websockets binding is getting near to a public review committee specification, 
and it would be great to have your input, and maybe participate in a little 
interop work. If you/your employer are an OASIS member, your input on the TC 
would be very welcome now, before the spec goes for public review.

Thanks,
-Steve

> -Original Message-
> From: Fraser Adams [mailto:fraser.ad...@blueyonder.co.uk]
> Sent: Tuesday, November 19, 2013 2:56 PM
> To: users@qpid.apache.org
> Subject: Proof of Concept JavaScript Proton implementation.
> 
> Hey all,
> For the last couple of weekends I've been working on a Proof of Concept
> JavaScript implementation of Proton.
> 
> The approach that I've taken is (I think) quite interesting/unusual but it's 
> an
> approach that offers a high level of synergy with implementations for other
> languages that are essentially bindings to proton-c.
> 
> The "magic elixir" in this is the downright amazing emscripten
> https://github.com/kripken/emscripten/wiki which (believe it or not) is
> essentially a cross-compiler that can compile C/C++ to JavaScript.
> Moreover the JavaScript that it compiles to is a particular subset called 
> asm.js
> http://asmjs.org/ which can be extremely aggressively optimised and is
> subject to a lot of research by Mozilla in particular (the main emscripten
> maintainer is actually a Mozilla researcher, though I believe emscripten is
> something of a side project).
> 
> It's well worth visiting the emscripten page with a modern browser, the Epic
> Citadel demo is awesome :-)
> 
> So in a nutshell what I've done is to compile proton-c into JavaScript
> 
> So I'm underselling it a bit :-) I had to do a fair bit of work to make it 
> that
> simple, in particular I had to add/fix a number of emscripten's library
> functions (Proton used a few things that weren't implemented) but the cool
> thing is that those are now in emscripten for everyone's benefit.
> 
> A really nice thing is that I've not actually had to modify any of the
> engine/messenger code at all - one I started to figure out what I was doing
> wrong that is :-) all I've really needed to to was to modify send.c/recv.c so
> that they behave in a non-blocking manner (you may have seen my mail at
> the weekend before I finally figured it out :-))
> 
> I've got CMake able to cross-compile in a repeatable fashion so the only
> change to any existing Proton stuff that is required is an addition to the 
> top-
> level CMakeLists.txt that detects the presence of emscripten and its
> dependencies and if present fires off
> "add_subdirectory(bindings/javascript)" e.g.
> 
> 
> # Build the JavaScript language binding.
> # This is somewhat different to the other language bindings in that it does
> not use swig. It uses a C/C++ to # JavaScript cross-compiler called emscripten
> (https://github.com/kripken/emscripten). Emscripten takes C/C++ # and
> "compiles" it into a highly optimisable subset of JavaScript called asm.js
> (http://asmjs.org/) that can # be aggressively optimised and run at near-
> native speed (usually between 1.5 to 10 times slower than native C/C++).
> option("BUILD_JAVASCRIPT" "Build JavaScript language binding" ON) if
> (BUILD_JAVASCRIPT)
># First check that Node.js is installed as that is needed by emscripten.
>find_program(NODE node)
>if (NOT NODE)
>  message(STATUS "Node.js (http://nodejs.org) is not installed: can't build
> JavaScript binding")
>else (NOT NODE)
>  # Check that the emscripten C/C++ to JavaScript cross-compiler is 
> installed.
>  find_program(EMCC emcc)
>  if (NOT EMCC)
>message(STATUS "Emscripten
> (https://github.com/kripken/emscripten) is not installed: can't build
> JavaScript binding")
>  else (NOT EMCC)
>add_subdirectory(bindings/javascript)
>  endif (NOT EMCC)
>endif (NOT NODE)
> endif (BUILD_JAVASCRIPT)
> 
> 
> So the main purpose of this mail is to give a heads up of it and to ask if 
> it'd be
> OK to start commiting it and give others some visibility of it.
> 
> At this stage it's something of a Proof of Concept, in particular:
> * I haven't exported any actual JavaScript bindings so although it's 
> JavaScript
> actual JavaScript clients would find it awkward to call the API as yet.
> * As alluded above and at the weekend the demo code I've got calling
> messenger isn't especially elegant, I think I know how to get things behaving
> more asynchronously, but haven't tried it yet (and my hunch may be wrong).
> * Transport is entirely over WebSockets :-) so I've actually got send and recv
> running on Node.js (and also send on a browser) but it'd be useful to have
> them communicate via TCP sockets too - though that'd need a proxy.
> * I still (perhaps amusingly given t

RE: QPID does not compile on mac

[Steve Huston]

Hi Dmitry,

> Hi All !
> 
> I'm new to this list.

Welcome!

> QPID does not compile on mac.

Correct.

> Are there plans to support QPID on OS X platform ?

I'm not immediately aware of any in-progress effort to support Qpid on OS X. If 
you would like to do the work to get Qpid running on OS X, that would be great. 
I encourage you to post any questions here, and any patches to a JIRA that you 
could open to track needed changes.

If you find yourself in a position of desiring outside help to get Qpid running 
on OS X, I'd be pleased to discuss this with you. Please contact me any time.

--
Steve Huston, Riverace Corporation
Total Lifecycle Support for Your Networked Applications
http://www.riverace.com 


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