---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3595/#review4540
---
/trunk/qpid/python/qpid/delegates.py
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3595/#review4544
---
Ship it!
Looks good to me.
- Rafael
On 2012-01-23 22:53:40, Alan
Seems reasonable to me. I don't know offhand if the python will work
with floats currently, but it should be trivial to make that work if it
doesn't already.
--Rafael
On 02/01/2012 10:21 AM, Alan Conway wrote:
Presently the C++ client takes options for reconnecting
(reconnect-timeout,
Hi Everyone,
As I'm sure a number of you are aware, there has been some early
prototyping/devel work going on by a few qpid developers on a 1.0
protocol implementation. Because of the early/experimental nature of the
work we've not yet pulled it into the qpid tree, but things are far
enough
Hi Everyone,
As some of you may know I've been working on AMQP 1.0 support in the
form of the proton library. I've taken the liberty of putting up a draft
web site here:
http://qpid.apache.org/proton/
It's very much in the spirit of having something to show is better than
nothing, so please
On Mon, 2012-06-25 at 10:07 -0400, Darryl L. Pierce wrote:
On Fri, Jun 22, 2012 at 07:07:38PM -0400, Rafael Schloming wrote:
Regarding (2), I believe this would require an official vote, so I'd
like to throw it out there for discussion. Currently the need for such a
list is being filled
On Mon, 2012-06-25 at 19:33 +0200, Rob Godfrey wrote:
On 25 June 2012 19:26, Gordon Sim g...@redhat.com wrote:
On 06/25/2012 05:37 PM, Rob Godfrey wrote:
when we are talking about Qpid Proton, it may be
integrated in the (imaginary) XXXMQ broker, and XXXMQ's relationship
to Qpid Proton
On Mon, 2012-06-25 at 14:06 -0400, Justin Ross wrote:
On Mon, 25 Jun 2012, Rafael Schloming wrote:
The fundamental issue here is that Qpid now needs to serve two
audiences. A very horizontal audience made up of pretty much anything
that might ever want to speak AMQP, and a more
On Tue, 2012-06-26 at 16:48 +0100, Gordon Sim wrote:
On 06/25/2012 06:45 PM, Rob Godfrey wrote:
I'm not sure that there is an overall write/wrong API to use... what
is important is that we properly define APIs, document them and then
support them.
Exactly. So far we have defined and
On Tue, 2012-06-26 at 16:48 +0100, Gordon Sim wrote:
On 06/25/2012 11:55 PM, Rafael Schloming wrote:
It makes sense that the people who are interested in using proton also
want to see a simplified API to get their users started with AMQP 1.0.
It really gives them an immediate ROI
That most likely means the TCP connection is being terminated without
waiting for the proper protocol close handshake to occur. To debug this
try setting the environment variable PN_TRACE_FRM to 1 when you run the
client and/or server. That will let you see exactly what frames are
being exchanged.
I took a quick look at this. I believe you're hitting a particularly
unfriendly issue with the way the java decoder works. Obviously it's
telling you a mandatory field is missing, but not which one. I know Rob
is planning on fixing that to be more friendly, however he is (or will
shortly be) on a
Hi Hiram,
I just checked a C proton-dump utility that I wrote in order to validate
the C codec against the files you posted. If you have any interest in
donating the test data and java version of the dump utility, I could
wire it all into the test suite so that we can make sure there are no
not (pn_connection_state(sender.conn) PN_REMOTE_CLOSED):
sender.wait()
--Rafael
On Tue, 2012-07-03 at 08:51 -0400, Darryl L. Pierce wrote:
On Mon, Jul 02, 2012 at 04:07:53PM -0400, Rafael Schloming wrote:
That most likely means the TCP connection is being terminated without
waiting
-0400, Darryl L. Pierce wrote:
On Tue, Jul 03, 2012 at 05:13:17PM -0400, Rafael Schloming wrote:
Can you post the ruby code you're using? I took a look at the original
python example you're transcoding and based on the trace it's likely
something is messed up around this part:
# we're
What was the source of these warnings? If it's the generated swig code,
we should probably fix this by excluding these macros from the swigged
interface as they are useless in the target language anyways.
--Rafael
On Fri, 2012-07-06 at 13:47 -0400, Darryl L. Pierce wrote:
From: Darryl L. Pierce
On Tue, 2012-07-10 at 15:04 -0400, Andrew Stitcher wrote:
On Tue, 2012-07-10 at 13:34 -0400, Rafael Schloming wrote:
What was the source of these warnings? If it's the generated swig code,
we should probably fix this by excluding these macros from the swigged
interface as they are useless
On Thu, 2012-07-12 at 18:10 +0200, Rob Godfrey wrote:
So, this thread seemed to stop without us ever actually taking a
concrete action to create a mailing list :-)
I know there were a couple of conversations off-list that happened
after this to try to articulate more clearly what we thought
On Thu, 2012-07-12 at 23:26 +0200, Rob Godfrey wrote:
There are two reasons why I think amqp-libraries@ is strictly superior
to proton@.
Firstly, while you may consider proton as a distinct stream of work,
I'm not sure how that works with something like the messaging API
which fits in with
Since the start of AMQP 1.0 implementation work I've posted several
times on the design of the work as it's evolved, and a bit on the source
code layout as that work was pulled into qpid. After recent discussions
I thought it would be good to post a bit more about the motivation and
strategy
On Wed, 2012-07-18 at 19:05 +0100, Gordon Sim wrote:
On 07/18/2012 05:40 PM, Rafael Schloming wrote:
So while the Proton mission is in many ways compatible with the
original Qpid charter, the de facto Qpid mission of today is really
quite different from Proton's.
I tend to disagree
On Wed, 2012-07-18 at 16:43 -0400, Rajith Attapattu wrote:
First of all, we as a community needs to collectively decide what our
charter is and more importantly *HOW TO GET THERE*.
While the majority *agrees* that our charter is promoting the
adoption of AMQP and being the premier ecosystem
On Wed, 2012-07-18 at 20:37 -0400, Carl Trieloff wrote:
I think the problem is that were we to reform Qpid in today's world, the
best way to support adoption of AMQP would not be to build yet another
broker, but rather to build a library that makes it easy to adapt all of
the many existing
On Thu, 2012-07-19 at 07:52 +0200, Rob Godfrey wrote:
I'm about to head out on vacation for 10 days or so, and haven't had a
chance to read Rafi's document yet, but for the avoidance of doubt I'd
just like to make clear that I completely concur with the position
Gordon outlined below.
In my
On Thu, 2012-07-19 at 15:59 +0100, Gordon Sim wrote:
3. This is the second hardest question for me!
I've personally invested a lot of time and effort in the qpid messaging
API. It was specifically geared to transitioning to 1.0. I personally
feel there is much to recommend it still. My
On Fri, 2012-07-20 at 11:20 +0100, Gordon Sim wrote:
On 07/19/2012 07:03 PM, Alan Conway wrote:
On the blocking front, a good messaging API should support both blocking
and non-blocking use. The messaging API can certainly be extended in a
backward compatible way to do so.
Yes, I agree.
On Thu, 2012-07-19 at 14:03 -0400, Alan Conway wrote:
On Thu, 2012-07-19 at 15:59 +0100, Gordon Sim wrote:
I've personally invested a lot of time and effort in the qpid messaging
API. It was specifically geared to transitioning to 1.0. I personally
feel there is much to recommend it
On Mon, 2012-07-23 at 15:20 +, Steve Huston wrote:
Forgive my naiveté wrt Maven, but Qpid C++ currently uses cmake (and
autoconf, but that's got a limited lifespan). It would be nice to limit
the number of build systems we need to maintain. I know proton is not
Qpid, but the knowledge and
We don't actually try to build all the source code with a single build
system. In the interests of being as friendly as possible to various
different user communities, we have multiple points in the tree that can
be viewed as top level entry points:
The proton/proton-c directory is the top level
On Mon, 2012-07-23 at 12:04 -0400, Rafael Schloming wrote:
The proton/proton-j directory is the top level entry point for Java and
it's laid out pretty much as any Java developer would expect. (At least
that is the idea modulo ant vs maven.) If you only care about the Java
code you can check
Sorry to jump in late on this thread. I'm totally for making proton as
easy to consume as possible, so I definitely support making maven
artifacts available, but I also had a very bad experience with maven
last time I was exposed to it.
As I recall there were two major issues, one being non
Hi Everyone,
I believe this has been mentioned in a few threads now, but in order to
release Proton, it needs to have it's own JIRA project. (I tried
managing this with a component within the Qpid JIRA project, but
versions are scoped to projects not components, so this simply won't
work.) As I'd
On Wed, 2012-07-25 at 12:50 -0400, Joseph Ottinger wrote:
Well, as far as I could tell, there *are* no tests yet - which worries
me. But that's part of what motivated my desire to move to Maven; we
can configure Arquillian to crank up a Qpid instance so that we can
run tests as part of the
Hi Everyone,
There's been a lot of good discussion about proton on the dev list,
however, despite my encouragement, many interested parties do not follow
the qpid dev list and instead email me directly as a matter of
convenience. It's my belief that a proton mailing list would help
encourage
This looks like a patch for a commit I made on trunk a while back. Did
something go awry with creating the patch set?
--Rafael
On Wed, 2012-07-25 at 14:05 -0400, Darryl L. Pierce wrote:
From: rhs rhs@13f79535-47bb-0310-9956-ffa450edef68
git-svn-id:
This thread is mixing a number of issues together. First off, there are
at least three audiences being discussed here and they all have a
distinct set of requirements:
1. Core Proton Developers
These are the people that actually spend every day writing, testing, and
debugging proton code. They
vote.
--Rafael
On Wed, 2012-07-25 at 13:34 -0400, Rafael Schloming wrote:
Hi Everyone,
I believe this has been mentioned in a few threads now, but in order to
release Proton, it needs to have it's own JIRA project. (I tried
managing this with a component within the Qpid JIRA project
:
https://reviews.apache.org/r/6302/
---
(Updated Aug. 6, 2012, 8:16 p.m.)
Review request for qpid, Andrew Stitcher, Kenneth Giusti, Steve Huston, and
Rafael Schloming.
Description
---
This patch set works with a recent
to substitute
socket for fd? I think that makes it's intent clearer. E.g:
pn_connector_socket( pn_driver_t *driver, pn_socket_t sock, void
*context)
Just wonderin'
Rafael Schloming wrote:
Sorry if I'm missing some context here, still catching up on the details
Giusti, Steve Huston, and
Rafael Schloming.
Description
---
This patch set works with a recent mingw32, cmake 2.8.1, python 2.5, swig
2.0.7.
A push-button build is still a ways off. The custom_commands in the cmake
script to generate the protocol headers don't work yet
Hi Everyone,
The proton mailing list and jira instance are both set up now. I've
updated the web site with the relevant info, here are the shortcuts:
Web: http://qpid.apache.org/proton
Subscribe with an email to: proton-subscr...@qpid.apache.org
The jira project is here:
/trunk/proton-c/src/sys/windows/driver.c
https://reviews.apache.org/r/6302/#comment21433
Is this just a wholesale copy + mod of src/driver.c?
- Rafael Schloming
On Aug. 6, 2012, 8:16 p.m., Cliff Jansen wrote
On Thu, 2012-08-30 at 15:57 -0400, Darryl L. Pierce wrote:
On Thu, Aug 30, 2012 at 03:13:42PM -0400, Darryl L. Pierce wrote:
I was asked to take on a JIRA task, but unfortunately it can't be
assigned to me. Can someone take care of adding me to JIRA so I can own
tickets?
Thanks.
.
- Rafael Schloming
On Sept. 19, 2012, 4:11 p.m., Kenneth Giusti wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7171
isolated and we
should get it on trunk ASAP and work on getting it integrated into messenger
and building up some more tests for it.
- Rafael Schloming
On Sept. 19, 2012, 4:11 p.m., Kenneth Giusti wrote:
---
This is an automatically
On Sept. 19, 2012, 4:43 p.m., Rafael Schloming wrote:
/proton/trunk/proton-c/src/ssl/openssl.c, line 385
https://reviews.apache.org/r/7171/diff/1/?file=158481#file158481line385
For sasl I actually just return the existing one here. My thinking was
that it would be convenient
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7171/#review11720
---
Ship it!
Ship It!
- Rafael Schloming
On Sept. 19, 2012, 9:40 p.m
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/8021/#review13432
---
Ship it!
Ship It!
- Rafael Schloming
On Nov. 13, 2012, 5:02 p.m
on
windows.
- Rafael Schloming
On Dec. 10, 2012, 10:06 p.m., Kenneth Giusti wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/8449
and session-id?
- Rafael Schloming
On Dec. 10, 2012, 7:56 p.m., Kenneth Giusti wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/8331
it now though and tweak the
names later.
- Rafael Schloming
On Dec. 13, 2012, 10:51 p.m., Kenneth Giusti wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/8449
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/8331/#review14669
---
Ship it!
Ship It!
- Rafael Schloming
On Dec. 18, 2012, 4:27 p.m
I think you raise a good point about the goals of the project being
confused, but don't think the cause here is mailing lists. As we've seen,
recent threads have asked about qpid vs proton, and to a lot of us this
is an odd thing to ask about because we think of proton as part of qpid.
However we
It's really about architecture and audience and how they interact. The
architecture we are currently developing is closely modelled on the
existing architecture of the internet. At the lowest layer the TCP stack
provides a very general purpose protocol to a very wide range of
applications. This is
On Mon, Jan 21, 2013 at 1:42 PM, Gordon Sim g...@redhat.com wrote:
On 01/21/2013 05:22 PM, Rafael Schloming wrote:
The users of a piece of software inherently shape its
direction, and forcing two pieces of software that need to be quite
independent to have a single user group is going
On Mon, Jan 21, 2013 at 3:10 PM, Gordon Sim g...@redhat.com wrote:
On 01/21/2013 07:39 PM, Rafael Schloming wrote:
Calling it an analogy is not really being fair. Getting closer to the
level
of generality I've described has been one of if not the primary design
goal
behind AMQP 1.0 since
I have directly experienced some of the opportunity cost that Justin speaks
of. I once observed someone (a director level decision maker) being very
surprised to be informed that qpid is actually *two* brokers. He had ruled
it out as an option entirely until he found out that we actualy have a
://reviews.apache.org/r/9123/#comment33913
extraneous whitespace
/proton/trunk/tests/proton_tests/common.py
https://reviews.apache.org/r/9123/#comment33914
more extraneous whitespace here
- Rafael Schloming
On Jan. 28, 2013, 5:33 p.m., Kenneth Giusti wrote
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/9123/#review15758
---
Ship it!
Ship It!
- Rafael Schloming
On Jan. 28, 2013, 5:33 p.m
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/8805/#review15765
---
Ship it!
Ship It!
- Rafael Schloming
On Jan. 28, 2013, 4:18 p.m
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/8223/#review15766
---
Ship it!
Ship It!
- Rafael Schloming
On Jan. 24, 2013, 8:14 a.m
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/9086/#review15769
---
Ship it!
Ship It!
- Rafael Schloming
On Jan. 24, 2013, 8:30 a.m
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/9085/#review15775
---
Ship it!
Ship It!
- Rafael Schloming
On Jan. 24, 2013, 8:24 a.m
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/9124/#review16019
---
Ship it!
Ship It!
- Rafael Schloming
On Jan. 28, 2013, 7:59 p.m
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/9169/#review16020
---
Ship it!
Ship It!
- Rafael Schloming
On Jan. 31, 2013, 3:28 a.m
languages we get the
additional coverage. Edgecases are a pretty common place where subtle mapping
issues creep in. It's easy to confuse binary, string, and symbol and map them
all into the same thing if you don't have sample values that exercise their
differences.
- Rafael Schloming
On Feb. 12
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/9447/#review16590
---
Ship it!
Ship It!
- Rafael Schloming
On Feb. 14, 2013, 2:11 p.m
the implementation can ignore close_head, however I think
we should have it in the interface and have the driver call it.
- Rafael Schloming
On Feb. 13, 2013, 8:08 p.m., Kenneth Giusti wrote:
---
This is an automatically generated e-mail
or not.
I'd suggest maybe bool pn_transport_quiesced(...).
- Rafael Schloming
On Feb. 14, 2013, 6:41 p.m., Kenneth Giusti wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/9450
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/9450/#review16647
---
Ship it!
Ship It!
- Rafael Schloming
On Feb. 15, 2013, 2:55 p.m
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/9299/#review16682
---
Ship it!
Ship It!
- Rafael Schloming
On Feb. 5, 2013, 2:33 a.m
when unlimited is set to true?
I'd restructure this code to calculate prior to the loop how many credits
each link should have and then simply distribute those. If we're in the
unlimited case we can then just choose a reasonable per/link default.
- Rafael Schloming
On Feb. 18, 2013, 8
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/9516/#review16749
---
Ship it!
Ship It!
- Rafael Schloming
On Feb. 19, 2013, 9:16 p.m
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/9503/#review16765
---
Ship it!
Ship It!
- Rafael Schloming
On Feb. 20, 2013, 2:51 a.m
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/9489/#review16766
---
Ship it!
Ship It!
- Rafael Schloming
On Feb. 19, 2013, 3:59 p.m
Where's the attachment?
--Rafael
On Wed, Feb 20, 2013 at 7:15 AM, Alan Conway acon...@redhat.com wrote:
Attached a brief proposal for an initial prototype for proton routing.
No attempt is made to enumerate all the uses cases we should/couuld
cover. Instead it proposes a basic framework and
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/9526/#review16770
---
Ship it!
Ship It!
- Rafael Schloming
On Feb. 20, 2013, 5:10 p.m
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/9825/#review17611
---
Ship it!
Ship It!
- Rafael Schloming
On March 8, 2013, 3:53 p.m
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/9802/#review17613
---
Ship it!
Ship It!
- Rafael Schloming
On March 7, 2013, 3:51 p.m
I haven't been following this discussion all that closely, but I did notice
two things I wanted to comment on:
(1) The fact that the JMS client maps all topics into the singular
amq.topic exchange is kind of weird and very different from the way the
other messaging clients behave.
Using
On Mon, Mar 25, 2013 at 3:13 PM, Rajith Attapattu rajit...@gmail.comwrote:
On Mon, Mar 25, 2013 at 2:53 PM, Rafael Schloming r...@alum.mit.edu
wrote:
This is not the case since the time we implemented the addressing stuff.
(used to be the case before that).
The JMS client behaves the same
On Mon, Mar 25, 2013 at 4:45 PM, Rob Godfrey rob.j.godf...@gmail.comwrote:
On 25 March 2013 21:32, Rajith Attapattu rajit...@gmail.com wrote:
On Mon, Mar 25, 2013 at 2:50 PM, Rajith Attapattu rajit...@gmail.com
wrote:
Actually I'd like to take a step back and ask what are our plans for
On Tue, Mar 26, 2013 at 8:10 AM, Robbie Gemmell robbie.gemm...@gmail.comwrote:
On 25 March 2013 18:53, Rafael Schloming r...@alum.mit.edu wrote:
I haven't been following this discussion all that closely, but I did
notice
two things I wanted to comment on:
(1) The fact that the JMS
On Tue, Mar 26, 2013 at 10:05 AM, Justin Ross jr...@apache.org wrote:
Also, for fun, an alternate logo. This one's probably better for a
t-shirt:
http://people.apache.org/~jross/transom/2013-03-26/images/logo-2-300-300.png
I think the T-shirt version should have horns. ;-)
--Rafael
+1 from me as well
I'm also skeptical that separate releases will prove workable without
separate JIRAs, however I think we can cross that bridge when we come to it.
There may also be a bit of a middle ground here. One of the reasons a
separate JIRA instance for Proton was an easy decision is
Hi,
I believe the XML files are available only under the AMQP license, so this
would indeed seem to be a problem for you if that license is unacceptable.
Fortunately, the AMQP PMC voted a while ago to allow the creation of
stripped down BSD licensed variants of the XML files suitable for machine
Some of you may recall that I ranted a bit just prior to the freeze for
the 0.6 release about how lots of non-client related stuff has been
accumulating in the python directory as of late. It was a bit too late
to do anything about it at the time, but as the freeze is over now, I'd
like to
Rafael Schloming wrote:
Some of you may recall that I ranted a bit just prior to the freeze for
the 0.6 release about how lots of non-client related stuff has been
accumulating in the python directory as of late. It was a bit too late
to do anything about it at the time, but as the freeze
Rajith Attapattu wrote:
On Tue, Feb 2, 2010 at 4:23 PM, Rafael Schloming rafa...@redhat.com wrote:
Some of you may recall that I ranted a bit just prior to the freeze for the
0.6 release about how lots of non-client related stuff has been accumulating
in the python directory as of late
Ken Giusti wrote:
Hi,
I've no problem with a cleanup reorg, but I'd like to keep the qmf version in
the dirname (wherever it may end up). e.g.:
qmf/ --- qpid/extras/qmf/
qmf2/ --- qpid/extras/qmf2/
Ah, I was a bit unclear in my notation, I was
Ken Giusti wrote:
Ah, yes - I see now. I'm ok with extras/qmf/qmf[2], but that begs the question - what about non-python QMF stuff, like other language bindings and cross-implementation interopt tests?
If we end up moving all qmf-related stuff into extras, then we'd probably need
flesh out
Alan Conway wrote:
On 02/02/2010 04:23 PM, Rafael Schloming wrote:
Some of you may recall that I ranted a bit just prior to the freeze for
the 0.6 release about how lots of non-client related stuff has been
accumulating in the python directory as of late. It was a bit too late
to do anything
While doing a few greps recently I noticed that a number of the newly
imported documentation files have spaces in their names. This can be a
bit of a pain for some scripting exercises. I noticed some of the other
files in the directory use - as a seperator and others use _.
Unless there is a
Jonathan Robie wrote:
On 02/05/2010 07:55 AM, Rafael Schloming wrote:
While doing a few greps recently I noticed that a number of the newly
imported documentation files have spaces in their names. This can be a
bit of a pain for some scripting exercises. I noticed some of the
other files
Robert Godfrey wrote:
On a related note what does Priority Delivery in Client Features mean?
This is the ability for the client to reorder messages in its prefetch
queue based on message priority. It's not the same as server-side
priority queues, although obviously it is a complimentary
Robert Godfrey wrote:
On a related note what does Priority Delivery in Client Features mean?
This is the ability for the client to reorder messages in its prefetch
queue based on message priority. It's not the same as server-side
priority queues, although obviously it is a complimentary
Robert Godfrey wrote:
On 11 February 2010 20:11, Rafael Schloming rafa...@redhat.com wrote:
Robert Godfrey wrote:
On a related note what does Priority Delivery in Client Features mean?
This is the ability for the client to reorder messages in its prefetch queue
based on message priority. It's
I was recently building the cpp broker on a freshly installed machine,
and it kept reporting missing boost header files. This was rather
confusing since I had boost-devel installed and the header files it was
complaining about were exactly where they should be.
After being confused for a
Steve Huston wrote:
I was recently building the cpp broker on a freshly installed
machine,
and it kept reporting missing boost header files. This was rather
confusing since I had boost-devel installed and the header
files it was
complaining about were exactly where they should be.
After
Andrew Stitcher wrote:
I'm interested in opinions as to the correct behaviour for QPID-2395:
https://issues.apache.org/jira/browse/QPID-2395
The real question IMO hinges on whether copying a Connection is
allowed/makes sense.
If copying a connection isn't allowed then closing the underlying
1 - 100 of 439 matches
Mail list logo
