[jira] [Closed] (QPID-7353) C++ 1.35.0 release tasks

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-7353.
-
Resolution: Done

> C++ 1.35.0 release tasks
> 
>
> Key: QPID-7353
> URL: https://issues.apache.org/jira/browse/QPID-7353
> Project: Qpid
>  Issue Type: Task
>  Components: C++ Broker, C++ Client
>Reporter: Justin Ross
>Assignee: Justin Ross
> Fix For: qpid-cpp-1.35.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Review Request 51638: handle reject and release in qpid::messaging

[Gordon Sim]

> On Sept. 6, 2016, 8:18 p.m., Alan Conway wrote:
> > Mostly nits, one major problem: I see no way to control the frequency or 
> > limit the number of resends. We need the same kind of controls for that as 
> > we have for connection retries, otherwise we will burn CPU on client and 
> > router with constant resends if the back end takes time to recover, or 
> > never recovers, or keeps releasing the same messages.
> 
> Alan Conway wrote:
> Thought: for handling rejection and allowing manual handling of relase: 
> can we throw an exception that carries the message when handling the 
> disposition? At that point the user can do what they like: resend, not 
> resend, send somewhere else etc. etc. When automatic resend is disabled, then 
> I see no difference between release and reject: they're both things the user 
> might need to know about, and in both cases the user may want to do something 
> else with the message.

It would require a new exception type. That's not a big change to the API, but 
I was hoping to avoid it. We already have a MessageRejected exception, which is 
currently used only when doing sync send. I just used that same exception. Also 
at the point we get the rejection, what we have is only the encoded for of the 
message. Again, it's not a big deal to recreate a message object from that. I 
was just looking for a minimalist solution in the first instance.

Thanks for all the great feedback. I'll post another update once I address the 
issues you raise.


> On Sept. 6, 2016, 8:18 p.m., Alan Conway wrote:
> > src/qpid/messaging/amqp/SenderContext.cpp, line 152
> > 
> >
> > Potential infinite loop? We push_back resends on the deliveries list, 
> > so it may never become empty.
> > 
> > Aside from this loop we can get into a bigger infinite loop with a 
> > broker that keeps releasing the same message. We need configurable min/max 
> > timeouts, max retries etc.

In the loop, if delivered() returns false, we break out the loop.

I agree that continually released messages are a potential issue. I say 
potential, because at present the only thing I am aware of that would release 
messages is the router, and it would not do so infinitely. However I could 
probably add a max resend count without too much difficulty.


> On Sept. 6, 2016, 8:18 p.m., Alan Conway wrote:
> > src/qpid/messaging/amqp/SenderContext.cpp, line 181
> > 
> >
> > If we get here there are no deliveries left, so even if there were some 
> > needing resend they're gone now.

No, because we exit the loop once we get to the first unconfirmed message. 
Messages that have been marked for resend will always be undelivered at this 
point, and so will still be on the queue.


> On Sept. 6, 2016, 8:18 p.m., Alan Conway wrote:
> > src/qpid/messaging/amqp/SenderContext.cpp, line 586
> > 
> >
> > Too many warning logs. In a client lib any info that warrants a warning 
> > needs to be returned via the API somehow so the user can deal with it. Text 
> > in a log file is not useful to a running client.

The warnings aren't new. The current behaviour is just to log the warning and 
otherwise ignore things. That behaviour will still be available with the 
appropriate configuration. While I do take your point about the ideal solution, 
I want to improve on the current situation without changing the API and I feel 
in this case that some logging is necessary.


> On Sept. 6, 2016, 8:18 p.m., Alan Conway wrote:
> > src/qpid/messaging/amqp/SenderContext.cpp, line 607
> > 
> >
> > Maybe "name:description", the name might be important.

Agreed, will update.


> On Sept. 6, 2016, 8:18 p.m., Alan Conway wrote:
> > src/qpid/messaging/amqp/SenderContext.cpp, line 651
> > 
> >
> > I don't understand. Any modifed message is not delivered, regardless of 
> > whether it is marked delivery_failed - by my reading there is effectively 
> > no difference betwee modified with no fields set and released.

You're right of course. I'll change that.


> On Sept. 6, 2016, 8:18 p.m., Alan Conway wrote:
> > src/qpid/messaging/ConnectionOptions.cpp, line 56
> > 
> >
> > Nit, I don't like double negatives. What about retryReleased(true), 
> > raiseRefused(true)? To me "do X" is clearer than "don't do nothing (and X 
> > is implied but not stated)

I'll switch to your suggestions.


> On Sept. 6, 2016, 8:18 p.m., Alan Conway wrote:
> > src/qpid/messaging/amqp/ConnectionContext.cpp, line 205
> > 
> >
> > Me

Re: Review Request 51638: handle reject and release in qpid::messaging

[Gordon Sim]

> On Sept. 6, 2016, 2:34 p.m., Alan Conway wrote:
> > src/qpid/messaging/amqp/SenderContext.h, line 44
> > 
> >
> > If we do adopt the exception strategy for communicating relase/reject 
> > then I think we need a clearly marked exception hierarchy so the user can 
> > tell which exceptions destroy the link/session/connection and which don't.
> 
> Gordon Sim wrote:
> None of these destroy the hierachy as viewed by the client.
> 
> Alan Conway wrote:
> Should update the docs to make that clear: Some MessagingExceptions (e.g. 
> SessionError) *do* tear down state, so the docs should make it clear which 
> ones don't.

Unfortunately it also depends on the protocol used.


- Gordon


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/51638/#review147837
---


On Sept. 6, 2016, 4:53 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51638/
> ---
> 
> (Updated Sept. 6, 2016, 4:53 p.m.)
> 
> 
> Review request for qpid and Alan Conway.
> 
> 
> Repository: qpid-cpp
> 
> 
> Description
> ---
> 
> Rejected messages cause an exception to be thrown. However this does not
> invalidate the session in anyway. More messages can be sent after
> catching the exception. The original behaviour - i.e. simply ignoring
> the rejected messages - can be obtained by setting the connection option
> 'ignore_delivery_refused' to true.
> 
> Released messages cause the transport to be aborted, triggering the usual
> resending logic (whether defined by the application or using that defined
> in the library itself). Again, released messages can be simply ignored as
> they were prior to this change by setting 'ignore_undelivered' to true.
> 
> For modified messages, if undeliverable-here is set to true, the message 
> is
> treated as if it had been rejected, otheriwse if delivery-failed is set to
> true it is treated as a released message. If neither is set it is simply
> ignored with a warning (i.e. treated as accepted).
> 
> 
> Diffs
> -
> 
>   src/qpid/messaging/ConnectionOptions.h c8c8798 
>   src/qpid/messaging/ConnectionOptions.cpp d956e9a 
>   src/qpid/messaging/amqp/ConnectionContext.cpp 25dd68d 
>   src/qpid/messaging/amqp/EncodedMessage.cpp cf60046 
>   src/qpid/messaging/amqp/SenderContext.h 467a8e0 
>   src/qpid/messaging/amqp/SenderContext.cpp fe8b4d3 
>   src/qpid/messaging/amqp/SessionContext.h 67b3c1e 
>   src/qpid/messaging/amqp/SessionContext.cpp 92bdea7 
>   src/qpid/messaging/amqp/Transaction.cpp 754b00d 
> 
> Diff: https://reviews.apache.org/r/51638/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>

Review Request 51665: add the ability to have qpid::messaging address string passed through to server when using AMQP 1.0

[Gordon Sim]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/51665/
---

Review request for qpid and Alan Conway.


Repository: qpid-cpp


Description
---

The qpid::messaging address syntax has several AMQP 0-10 specific parts that 
cannot be expressed well in AMQP 1.0. However, these strings could be passed 
through unparsed to the server which might be able to interpret them. This 
would allow different options in trying to move existing applications to the 
1.0 protocol.

This patch provides a new option, address_passthrough, which can be used to 
control this behaviour. If false, the address will never be passed through. If 
true, the address will always be passed through. If not specified, the adress 
will only be passed through on connections where the server has indicated it 
desires this, by setting the 'qpid:messaging:address' capability on the 
connection.


Diffs
-

  src/qpid/messaging/ConnectionOptions.h c8c8798 
  src/qpid/messaging/ConnectionOptions.cpp d956e9a 
  src/qpid/messaging/amqp/ConnectionContext.h ba3220c 
  src/qpid/messaging/amqp/ConnectionContext.cpp 25dd68d 

Diff: https://reviews.apache.org/r/51665/diff/


Testing
---


Thanks,

Gordon Sim

[jira] [Resolved] (QPID-7393) Unavailable buffers in Windows SSL

[Cliff Jansen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cliff Jansen resolved QPID-7393.

Resolution: Fixed

> Unavailable buffers in Windows SSL
> --
>
> Key: QPID-7393
> URL: https://issues.apache.org/jira/browse/QPID-7393
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker, C++ Client
>Affects Versions: qpid-cpp-1.35.0
> Environment: Windows SChannel
>Reporter: Cliff Jansen
>Assignee: Cliff Jansen
> Fix For: qpid-cpp-1.35.0
>
>
> From the user list (acartcat cartwright_and...@cat.com):
> > I get the following error in the broker, looks like the same error as
> > QPID-5033.
> [...]
> > 2016-05-26 05:22:23 [System] error No IO buffers available: getQueuedBuffer
> > with empty queue. Debug data: 0 1 0 3 0 0 1
> [...]
> > This can be triggered on demand using:
> > qpid-send -b ssl:.com:5671 --connection-options {protocol:amqp1.0}
> > -a testerq --content-string=hello --messages 200
> In my testing, qpid-send must also be Windows based.  I do not see the error
> if it is sent from a client running on Linux.
> This error is caused by the SChannel driver generating (valid but
> useless) empty SSL packets when a zero length write is requested from
> the codec on the client side.  On the server side, these are
> processed and empty read callbacks are generated, even after close.
> The WSAENOBUFS happens as a side effect of recursive calls to
> sslDataIn while processing adjacent empty packets.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7393) Unavailable buffers in Windows SSL

[Justin Ross (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15468524#comment-15468524
 ] 

Justin Ross commented on QPID-7393:
---

[~cliffjansen], this is resolved?

> Unavailable buffers in Windows SSL
> --
>
> Key: QPID-7393
> URL: https://issues.apache.org/jira/browse/QPID-7393
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker, C++ Client
>Affects Versions: qpid-cpp-1.35.0
> Environment: Windows SChannel
>Reporter: Cliff Jansen
>Assignee: Cliff Jansen
> Fix For: qpid-cpp-1.35.0
>
>
> From the user list (acartcat cartwright_and...@cat.com):
> > I get the following error in the broker, looks like the same error as
> > QPID-5033.
> [...]
> > 2016-05-26 05:22:23 [System] error No IO buffers available: getQueuedBuffer
> > with empty queue. Debug data: 0 1 0 3 0 0 1
> [...]
> > This can be triggered on demand using:
> > qpid-send -b ssl:.com:5671 --connection-options {protocol:amqp1.0}
> > -a testerq --content-string=hello --messages 200
> In my testing, qpid-send must also be Windows based.  I do not see the error
> if it is sent from a client running on Linux.
> This error is caused by the SChannel driver generating (valid but
> useless) empty SSL packets when a zero length write is requested from
> the codec on the client side.  On the server side, these are
> processed and empty read callbacks are generated, even after close.
> The WSAENOBUFS happens as a side effect of recursive calls to
> sslDataIn while processing adjacent empty packets.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (QPID-7281) Get the tests running on Windows

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross resolved QPID-7281.
---
Resolution: Fixed

> Get the tests running on Windows
> 
>
> Key: QPID-7281
> URL: https://issues.apache.org/jira/browse/QPID-7281
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Broker, C++ Client
>Affects Versions: qpid-cpp-0.34
>Reporter: Justin Ross
>Assignee: Justin Ross
>  Labels: windows
> Fix For: qpid-cpp-1.35.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Closed] (QPID-7354) Python 1.35.0 release tasks

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-7354.
-
Resolution: Done

> Python 1.35.0 release tasks
> ---
>
> Key: QPID-7354
> URL: https://issues.apache.org/jira/browse/QPID-7354
> Project: Qpid
>  Issue Type: Task
>  Components: Python Client, Python Test Suite
>Reporter: Justin Ross
>Assignee: Justin Ross
> Fix For: qpid-python-1.35.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (QPID-7173) Include qpid_tests.broker_1_0 in list of modules installed by tests/setup.py

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross resolved QPID-7173.
---
Resolution: Fixed

Implicitly accepted - it went into 1.35.0

> Include qpid_tests.broker_1_0 in list of modules installed by tests/setup.py
> 
>
> Key: QPID-7173
> URL: https://issues.apache.org/jira/browse/QPID-7173
> Project: Qpid
>  Issue Type: Test
>  Components: Python Test Suite
>Reporter: Keith Wall
>Assignee: Alex Rudyy
> Fix For: qpid-python-1.35.0
>
>
> {{tests/setup.py}} doesn't currently install the {{broker_1_0}} module.  This 
> was probably an oversight.  Installing it too will simplify test automation 
> steps.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Closed] (QPID-4643) In ping_broker, by way of ssl_test, broker.echo returns None

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-4643.
-
Resolution: Unresolved

> In ping_broker, by way of ssl_test, broker.echo returns None
> 
>
> Key: QPID-4643
> URL: https://issues.apache.org/jira/browse/QPID-4643
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
> Environment: Fedora 16 x86-64
>Reporter: Justin Ross
>
> I fiddled with ping_broker to properly handle what looks like an unexpected 
> state: the .echo call returns false.
> I was not able to determine why it returned None.
> Index: ping_broker
> ===
> --- ping_broker   (revision 1455242)
> +++ ping_broker   (working copy)
> @@ -101,7 +101,7 @@
>  def Ping(self, args):
>  for sequence in range(10):
>  result = self.broker.echo(sequence, "ECHO BODY")
> -if result['sequence'] != sequence:
> +if not result or result['sequence'] != sequence:
>  raise Exception("Invalid Sequence")



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Closed] (QPID-4723) Compile qmf-agent failed on qpid-0.20

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-4723.
-
Resolution: Unresolved

Stale issue - we're now on cmake

> Compile qmf-agent failed on qpid-0.20
> -
>
> Key: QPID-4723
> URL: https://issues.apache.org/jira/browse/QPID-4723
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: 0.20
> Environment: centos 6.3 x86_64
>Reporter: jim yefeng
>Priority: Blocker
>
> [jim@dev-1 examples]$ cd qmf-agent/
> [jim@dev-1 qmf-agent]$ ls
> example.cpp  example.d  example_gen.mak  gen  Makefile  qmf_agent.vcproj  
> schema.xml
> [jim@dev-1 qmf-agent]$ make
> ../../../cpp/managementgen/qmf-gen -o ./gen/qmf ./schema.xml
> make[1]: Entering directory 
> `/home/jim/packages/qpid-0.20/cpp/examples/qmf-agent'
> make[2]: Entering directory 
> `/home/jim/packages/qpid-0.20/cpp/examples/qmf-agent'
> gcc -c -g -O3 -I. -I../../../cpp/include -I./gen -o example.o example.cpp
> example.cpp:71: error: conflicting return type specified for ‘virtual 
> qpid::management::ManagementObject* CoreClass::GetManagementObject() const’
> ../../../cpp/include/qpid/management/Manageable.h:58: error:   overriding 
> ‘virtual qpid::management::ManagementObject::shared_ptr 
> qpid::management::Manageable::GetManagementObject() const’
> example.cpp:89: error: conflicting return type specified for ‘virtual 
> qpid::management::ManagementObject* ChildClass::GetManagementObject() const’
> ../../../cpp/include/qpid/management/Manageable.h:58: error:   overriding 
> ‘virtual qpid::management::ManagementObject::shared_ptr 
> qpid::management::Manageable::GetManagementObject() const’
> make[2]: *** [example.o] Error 1
> make[2]: Leaving directory 
> `/home/jim/packages/qpid-0.20/cpp/examples/qmf-agent'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory 
> `/home/jim/packages/qpid-0.20/cpp/examples/qmf-agent'
> make: *** [all] Error 2
> [jim@dev-1 qmf-agent]$ 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-5208) Improve documentation for enabling persistence

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-5208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-5208:
--
Issue Type: Improvement  (was: Bug)

> Improve documentation for enabling persistence
> --
>
> Key: QPID-5208
> URL: https://issues.apache.org/jira/browse/QPID-5208
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Broker, Documentation
>Reporter: Gordon Sim
>Priority: Critical
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-5208) Improve documentation for enabling persistence

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-5208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-5208:
--
Priority: Critical  (was: Blocker)

> Improve documentation for enabling persistence
> --
>
> Key: QPID-5208
> URL: https://issues.apache.org/jira/browse/QPID-5208
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker, Documentation
>Reporter: Gordon Sim
>Priority: Critical
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Review Request 51638: handle reject and release in qpid::messaging

[Alan Conway]

> On Sept. 6, 2016, 8:18 p.m., Alan Conway wrote:
> > Mostly nits, one major problem: I see no way to control the frequency or 
> > limit the number of resends. We need the same kind of controls for that as 
> > we have for connection retries, otherwise we will burn CPU on client and 
> > router with constant resends if the back end takes time to recover, or 
> > never recovers, or keeps releasing the same messages.

Thought: for handling rejection and allowing manual handling of relase: can we 
throw an exception that carries the message when handling the disposition? At 
that point the user can do what they like: resend, not resend, send somewhere 
else etc. etc. When automatic resend is disabled, then I see no difference 
between release and reject: they're both things the user might need to know 
about, and in both cases the user may want to do something else with the 
message.


- Alan


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/51638/#review147907
---


On Sept. 6, 2016, 4:53 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51638/
> ---
> 
> (Updated Sept. 6, 2016, 4:53 p.m.)
> 
> 
> Review request for qpid and Alan Conway.
> 
> 
> Repository: qpid-cpp
> 
> 
> Description
> ---
> 
> Rejected messages cause an exception to be thrown. However this does not
> invalidate the session in anyway. More messages can be sent after
> catching the exception. The original behaviour - i.e. simply ignoring
> the rejected messages - can be obtained by setting the connection option
> 'ignore_delivery_refused' to true.
> 
> Released messages cause the transport to be aborted, triggering the usual
> resending logic (whether defined by the application or using that defined
> in the library itself). Again, released messages can be simply ignored as
> they were prior to this change by setting 'ignore_undelivered' to true.
> 
> For modified messages, if undeliverable-here is set to true, the message 
> is
> treated as if it had been rejected, otheriwse if delivery-failed is set to
> true it is treated as a released message. If neither is set it is simply
> ignored with a warning (i.e. treated as accepted).
> 
> 
> Diffs
> -
> 
>   src/qpid/messaging/ConnectionOptions.h c8c8798 
>   src/qpid/messaging/ConnectionOptions.cpp d956e9a 
>   src/qpid/messaging/amqp/ConnectionContext.cpp 25dd68d 
>   src/qpid/messaging/amqp/EncodedMessage.cpp cf60046 
>   src/qpid/messaging/amqp/SenderContext.h 467a8e0 
>   src/qpid/messaging/amqp/SenderContext.cpp fe8b4d3 
>   src/qpid/messaging/amqp/SessionContext.h 67b3c1e 
>   src/qpid/messaging/amqp/SessionContext.cpp 92bdea7 
>   src/qpid/messaging/amqp/Transaction.cpp 754b00d 
> 
> Diff: https://reviews.apache.org/r/51638/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>

Re: Review Request 51638: handle reject and release in qpid::messaging

[Alan Conway]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/51638/#review147907
---



Mostly nits, one major problem: I see no way to control the frequency or limit 
the number of resends. We need the same kind of controls for that as we have 
for connection retries, otherwise we will burn CPU on client and router with 
constant resends if the back end takes time to recover, or never recovers, or 
keeps releasing the same messages.


src/qpid/messaging/ConnectionOptions.cpp (line 56)


Nit, I don't like double negatives. What about retryReleased(true), 
raiseRefused(true)? To me "do X" is clearer than "don't do nothing (and X is 
implied but not stated)



src/qpid/messaging/amqp/ConnectionContext.cpp (line 205)


Message should say why: "could not sync session because a message was 
rejected"



src/qpid/messaging/amqp/EncodedMessage.cpp (line 54)


Why memmove? Is it legal for two EncodedMessages to have overlapping 
buffers? If not this might be clearer:

if (data != other.data) memcpy(...)



src/qpid/messaging/amqp/SenderContext.cpp (line 152)


Potential infinite loop? We push_back resends on the deliveries list, so it 
may never become empty.

Aside from this loop we can get into a bigger infinite loop with a broker 
that keeps releasing the same message. We need configurable min/max timeouts, 
max retries etc.



src/qpid/messaging/amqp/SenderContext.cpp (line 165)


This looks right but the user has no idea it is happening. Often that is 
good, but do we need a way for people to know? We had the same problem with 
excessivly transparent reconnects before.



src/qpid/messaging/amqp/SenderContext.cpp (line 181)


If we get here there are no deliveries left, so even if there were some 
needing resend they're gone now.



src/qpid/messaging/amqp/SenderContext.cpp (line 585)


Too many warning logs. In a client lib any info that warrants a warning 
needs to be returned via the API somehow so the user can deal with it. Text in 
a log file is not useful to a running client.



src/qpid/messaging/amqp/SenderContext.cpp (line 606)


Maybe "name:description", the name might be important.



src/qpid/messaging/amqp/SenderContext.cpp (line 650)


I don't understand. Any modifed message is not delivered, regardless of 
whether it is marked delivery_failed - by my reading there is effectively no 
difference betwee modified with no fields set and released.


- Alan Conway


On Sept. 6, 2016, 4:53 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51638/
> ---
> 
> (Updated Sept. 6, 2016, 4:53 p.m.)
> 
> 
> Review request for qpid and Alan Conway.
> 
> 
> Repository: qpid-cpp
> 
> 
> Description
> ---
> 
> Rejected messages cause an exception to be thrown. However this does not
> invalidate the session in anyway. More messages can be sent after
> catching the exception. The original behaviour - i.e. simply ignoring
> the rejected messages - can be obtained by setting the connection option
> 'ignore_delivery_refused' to true.
> 
> Released messages cause the transport to be aborted, triggering the usual
> resending logic (whether defined by the application or using that defined
> in the library itself). Again, released messages can be simply ignored as
> they were prior to this change by setting 'ignore_undelivered' to true.
> 
> For modified messages, if undeliverable-here is set to true, the message 
> is
> treated as if it had been rejected, otheriwse if delivery-failed is set to
> true it is treated as a released message. If neither is set it is simply
> ignored with a warning (i.e. treated as accepted).
> 
> 
> Diffs
> -
> 
>   src/qpid/messaging/ConnectionOptions.h c8c8798 
>   src/qpid/messaging/ConnectionOptions.cpp d956e9a 
>   src/qpid/messaging/amqp/ConnectionContext.cpp 25dd68d 
>   src/qpid/messaging/amqp/EncodedMessage.cpp cf60046 
>   src/qpid/messaging/amqp/SenderContext.h 467a8e0 
>   src/qpid/messaging/amqp/SenderContext.cpp fe8b4d3 
>   src/qpid/messaging/amqp/SessionContext.h 67b3c1e 
>   src/qpid/messaging/amqp/SessionContext.cpp 92bdea7 
>   src/qpid/messaging/amqp/Transaction.cpp 754b00d 
> 
> Diff:

Re: Review Request 51638: handle reject and release in qpid::messaging

[Alan Conway]

> On Sept. 6, 2016, 2:34 p.m., Alan Conway wrote:
> > src/qpid/messaging/amqp/SenderContext.h, line 44
> > 
> >
> > If we do adopt the exception strategy for communicating relase/reject 
> > then I think we need a clearly marked exception hierarchy so the user can 
> > tell which exceptions destroy the link/session/connection and which don't.
> 
> Gordon Sim wrote:
> None of these destroy the hierachy as viewed by the client.

Should update the docs to make that clear: Some MessagingExceptions (e.g. 
SessionError) *do* tear down state, so the docs should make it clear which ones 
don't.


- Alan


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/51638/#review147837
---


On Sept. 6, 2016, 4:53 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51638/
> ---
> 
> (Updated Sept. 6, 2016, 4:53 p.m.)
> 
> 
> Review request for qpid and Alan Conway.
> 
> 
> Repository: qpid-cpp
> 
> 
> Description
> ---
> 
> Rejected messages cause an exception to be thrown. However this does not
> invalidate the session in anyway. More messages can be sent after
> catching the exception. The original behaviour - i.e. simply ignoring
> the rejected messages - can be obtained by setting the connection option
> 'ignore_delivery_refused' to true.
> 
> Released messages cause the transport to be aborted, triggering the usual
> resending logic (whether defined by the application or using that defined
> in the library itself). Again, released messages can be simply ignored as
> they were prior to this change by setting 'ignore_undelivered' to true.
> 
> For modified messages, if undeliverable-here is set to true, the message 
> is
> treated as if it had been rejected, otheriwse if delivery-failed is set to
> true it is treated as a released message. If neither is set it is simply
> ignored with a warning (i.e. treated as accepted).
> 
> 
> Diffs
> -
> 
>   src/qpid/messaging/ConnectionOptions.h c8c8798 
>   src/qpid/messaging/ConnectionOptions.cpp d956e9a 
>   src/qpid/messaging/amqp/ConnectionContext.cpp 25dd68d 
>   src/qpid/messaging/amqp/EncodedMessage.cpp cf60046 
>   src/qpid/messaging/amqp/SenderContext.h 467a8e0 
>   src/qpid/messaging/amqp/SenderContext.cpp fe8b4d3 
>   src/qpid/messaging/amqp/SessionContext.h 67b3c1e 
>   src/qpid/messaging/amqp/SessionContext.cpp 92bdea7 
>   src/qpid/messaging/amqp/Transaction.cpp 754b00d 
> 
> Diff: https://reviews.apache.org/r/51638/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>

[jira] [Created] (DISPATCH-498) memory leak in _configure_ssl_profile error path

[Chuck Rolke (JIRA)]

Chuck Rolke created DISPATCH-498:


 Summary: memory leak in _configure_ssl_profile error path
 Key: DISPATCH-498
 URL: https://issues.apache.org/jira/browse/DISPATCH-498
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Management Agent
Affects Versions: 0.6.1
Reporter: Chuck Rolke


As ssl_profile is constructed the CHECK() macro might jump to the error 
handler. There the ssl_profile is simply freed. Any strings referenced by 
ssl_profile are orphaned. Call qd_config_ssl_profile_free() instead of simple 
free().



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-7409) Support preview of maps/list message content

[Alex Rudyy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-7409:
-
Attachment: 0001-QPID-7409-WIP-add-support-for-getting-of-message-con.patch

> Support preview of maps/list message content
> 
>
> Key: QPID-7409
> URL: https://issues.apache.org/jira/browse/QPID-7409
> Project: Qpid
>  Issue Type: Improvement
>Reporter: Keith Wall
>Assignee: Alex Rudyy
> Fix For: qpid-java-6.1
>
> Attachments: 
> 0001-QPID-7409-WIP-add-support-for-getting-of-message-con.patch
>
>
> When viewing messages through the web management console, if the message is 
> of type such as a list or map currently the user sees the bytes of the 
> underlying AMQP datastructure.  Instead, the preview area should display the 
> data in a human friendly way.
> The managed operation {{Queue#getMessageContent}} will be enhanced to be 
> capable of returning a message in JSON format if possible with an optional 
> parameter {{returnJson}}.  If rather than returning the message's content 
> bytes directly, it should first convert the message to an {{InternalMessage}} 
> (MessageConverterRegistry.getConverter(serverMessage.getClass, 
> InternalMessage.class).convert(...)) then use the JSON serialiser to serial 
> the MessageBody of the resulting internal message.
> Within the WMC, if the resulting object is of a previewable type (string, 
> map, list etc) and the content is not too long, the content should be added 
> to a scrollable preview pane of the message dialogue by traversing the object 
> tree and producing a human readable representation of its structure and 
> content.  (Perhaps an approach such as 
> https://stackoverflow.com/questions/13341373/render-arbitrary-json-in-html 
> will help)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Review Request 51638: handle reject and release in qpid::messaging

[Gordon Sim]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/51638/
---

(Updated Sept. 6, 2016, 4:53 p.m.)


Review request for qpid and Alan Conway.


Changes
---

Missed a bit in previous update!


Repository: qpid-cpp


Description
---

Rejected messages cause an exception to be thrown. However this does not
invalidate the session in anyway. More messages can be sent after
catching the exception. The original behaviour - i.e. simply ignoring
the rejected messages - can be obtained by setting the connection option
'ignore_delivery_refused' to true.

Released messages cause the transport to be aborted, triggering the usual
resending logic (whether defined by the application or using that defined
in the library itself). Again, released messages can be simply ignored as
they were prior to this change by setting 'ignore_undelivered' to true.

For modified messages, if undeliverable-here is set to true, the message is
treated as if it had been rejected, otheriwse if delivery-failed is set to
true it is treated as a released message. If neither is set it is simply
ignored with a warning (i.e. treated as accepted).


Diffs (updated)
-

  src/qpid/messaging/ConnectionOptions.h c8c8798 
  src/qpid/messaging/ConnectionOptions.cpp d956e9a 
  src/qpid/messaging/amqp/ConnectionContext.cpp 25dd68d 
  src/qpid/messaging/amqp/EncodedMessage.cpp cf60046 
  src/qpid/messaging/amqp/SenderContext.h 467a8e0 
  src/qpid/messaging/amqp/SenderContext.cpp fe8b4d3 
  src/qpid/messaging/amqp/SessionContext.h 67b3c1e 
  src/qpid/messaging/amqp/SessionContext.cpp 92bdea7 
  src/qpid/messaging/amqp/Transaction.cpp 754b00d 

Diff: https://reviews.apache.org/r/51638/diff/


Testing
---


Thanks,

Gordon Sim

Re: Review Request 51638: handle reject and release in qpid::messaging

[Gordon Sim]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/51638/
---

(Updated Sept. 6, 2016, 4:43 p.m.)


Review request for qpid and Alan Conway.


Changes
---

I agree, the abort is ugly and unnecessary. This new diff just resends 
'released' messages over the existing link/connection.

The problem with informing the user of the release is that the current API 
doesn't allow that to be done in a way that is helpful to the application, 
should the application wish to resend. For released messages, resending is 
(probably) the most sensible option.

For rejected messages on the other hand, the application should *not* resend. 
So while we are still limited in being able to communicate the result of 
asynchronous sends, it is slightly less of an issue, since they would not want 
to resend anyway.


Repository: qpid-cpp


Description
---

Rejected messages cause an exception to be thrown. However this does not
invalidate the session in anyway. More messages can be sent after
catching the exception. The original behaviour - i.e. simply ignoring
the rejected messages - can be obtained by setting the connection option
'ignore_delivery_refused' to true.

Released messages cause the transport to be aborted, triggering the usual
resending logic (whether defined by the application or using that defined
in the library itself). Again, released messages can be simply ignored as
they were prior to this change by setting 'ignore_undelivered' to true.

For modified messages, if undeliverable-here is set to true, the message is
treated as if it had been rejected, otheriwse if delivery-failed is set to
true it is treated as a released message. If neither is set it is simply
ignored with a warning (i.e. treated as accepted).


Diffs (updated)
-

  src/qpid/messaging/ConnectionOptions.h c8c8798 
  src/qpid/messaging/ConnectionOptions.cpp d956e9a 
  src/qpid/messaging/amqp/ConnectionContext.cpp 25dd68d 
  src/qpid/messaging/amqp/EncodedMessage.cpp cf60046 
  src/qpid/messaging/amqp/SenderContext.h 467a8e0 
  src/qpid/messaging/amqp/SenderContext.cpp fe8b4d3 
  src/qpid/messaging/amqp/SessionContext.h 67b3c1e 
  src/qpid/messaging/amqp/SessionContext.cpp 92bdea7 
  src/qpid/messaging/amqp/Transaction.cpp 754b00d 

Diff: https://reviews.apache.org/r/51638/diff/


Testing
---


Thanks,

Gordon Sim

[jira] [Closed] (QPID-6771) Can't compile qpidbroker with vc2008

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-6771.
-

> Can't compile qpidbroker with vc2008
> 
>
> Key: QPID-6771
> URL: https://issues.apache.org/jira/browse/QPID-6771
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: qpid-cpp-0.34
> Environment: Windows xp sp3, VC2008 no sp,boost 1.59.0
>Reporter: sxf
> Fix For: qpid-cpp-1.36.0
>
>
> 1) qpid-cpp-0.34\src\qpid\sys\regex.h
> qpid-cpp-0.34\src\qpid/sys/regex.h(27) : fatal error C1083: 无法打开包括文件:"regex": 
> No such file or directory
> from:
> #if defined(_POSIX_SOURCE) || defined(__unix__)
> # include 
> # include 
> # include 
> #elif defined(_MSC_VER)
> # include 
> #else
> #error "No known regex implementation"
> #endif
> to:
> #if defined(_POSIX_SOURCE) || defined(__unix__)
> # include 
> # include 
> # include 
> #elif (_MSC_VER > 1500)
> # include 
> #elif (_MSC_VER <= 1500)
> # include 
> #else
> #error "No known regex implementation"
> #endif
> 2)qpid-cpp-0.34\src\qpid\sys\unordered_map.h
> qpid-cpp-0.34\src\qpid/sys/unordered_map.h(25) : fatal error C1083: 
> 无法打开包括文件:"unordered_map": No such file or directory
> from:
> #if defined(_MSC_VER) || defined(_LIBCPP_VERSION) || __cplusplus >= 201103L
> #  include 
> #elif defined(__SUNPRO_CC) || defined(__IBMCPP__)
> #  include 
> #else
> #  include 
> #endif /* _MSC_VER */
> to:
> #if (_MSC_VER > 1500) || defined(_LIBCPP_VERSION) || __cplusplus >= 201103L
> #  include 
> #elif (_MSC_VER <= 1500) || defined(__SUNPRO_CC) || defined(__IBMCPP__)
> #  include 
> #else
> #  include 
> #endif /* _MSC_VER */
> 3)..\..\..\src\tests\exception_test.cpp(66) : error C3861: "BOOST_MESSAGE": 
> 找不到标识符
> from:
> void run() {
> try {
> ScopedSuppressLogging sl; // Suppress messages for expected 
> errors.
> f();
> }
> catch(const Ex& e) {
> caught=true;
> BOOST_MESSAGE(string("Caught expected exception: 
> ")+e.what()+"["+typeid(e).name()+"]");
> to:
> void run() {
> try {
> ScopedSuppressLogging sl; // Suppress messages for expected 
> errors.
> f();
> }
> catch(const Ex& e) {
> caught=true;
> BOOST_ERROR(string("Caught expected exception: 
> ")+e.what()+"["+typeid(e).name()+"]");



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-6491) qpid-route map does not use any authentication when querying other brokers

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-6491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-6491:
--
Fix Version/s: (was: qpid-tools-next)
   qpid-cpp-1.35.0

> qpid-route map does not use any authentication when querying other brokers
> --
>
> Key: QPID-6491
> URL: https://issues.apache.org/jira/browse/QPID-6491
> Project: Qpid
>  Issue Type: Bug
>  Components: Python Tools
>Affects Versions: 0.30
>Reporter: Pavel Moravec
>Assignee: Pavel Moravec
>Priority: Minor
> Fix For: qpid-cpp-1.35.0
>
> Attachments: QPID-6491.patch
>
>
> "qpid-route route map" during generating the federation topology connects to 
> each and every broker in the federation to query it's federation peers. All 
> such connections (except for the very first broker) are made as anonymous 
> user only.
> It is requested the tool passes username, password and optionally also 
> --client-sasl-mechanism parameter to all other brokers as well.
> (another option to this would be the tool gets the credentials info from the 
> broker, but currently QMF response to links does not contain such info. This 
> option would need much more code change also on broker side)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-6767) qpidd tools don't allow sasl service name to be changed

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-6767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-6767:
--
Fix Version/s: (was: qpid-tools-next)
   (was: qpid-python-next)
   qpid-cpp-1.35.0

> qpidd tools don't allow sasl service name to be changed
> ---
>
> Key: QPID-6767
> URL: https://issues.apache.org/jira/browse/QPID-6767
> Project: Qpid
>  Issue Type: Bug
>  Components: Python Tools
>Affects Versions: 0.32
>Reporter: Gordon Sim
>Assignee: Ken Giusti
> Fix For: qpid-cpp-1.35.0
>
> Attachments: sasl-service-name-full.patch
>
>
> QPID-6532 made the sasl service name that qpidd uses configurable. However if 
> this is changed then the python based cli tools are unable to use mechanisms 
> that rely on it (e.g. DIGEST-MD5, GSSAPI) as they have no way to configure 
> the service name used from the 'qpidd' default.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Assigned] (QPID-7409) Support preview of maps/list message content

[Alex Rudyy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy reassigned QPID-7409:


Assignee: Alex Rudyy

> Support preview of maps/list message content
> 
>
> Key: QPID-7409
> URL: https://issues.apache.org/jira/browse/QPID-7409
> Project: Qpid
>  Issue Type: Improvement
>Reporter: Keith Wall
>Assignee: Alex Rudyy
> Fix For: qpid-java-6.1
>
>
> When viewing messages through the web management console, if the message is 
> of type such as a list or map currently the user sees the bytes of the 
> underlying AMQP datastructure.  Instead, the preview area should display the 
> data in a human friendly way.
> The managed operation {{Queue#getMessageContent}} will be enhanced to be 
> capable of returning a message in JSON format if possible with an optional 
> parameter {{returnJson}}.  If rather than returning the message's content 
> bytes directly, it should first convert the message to an {{InternalMessage}} 
> (MessageConverterRegistry.getConverter(serverMessage.getClass, 
> InternalMessage.class).convert(...)) then use the JSON serialiser to serial 
> the MessageBody of the resulting internal message.
> Within the WMC, if the resulting object is of a previewable type (string, 
> map, list etc) and the content is not too long, the content should be added 
> to a scrollable preview pane of the message dialogue by traversing the object 
> tree and producing a human readable representation of its structure and 
> content.  (Perhaps an approach such as 
> https://stackoverflow.com/questions/13341373/render-arbitrary-json-in-html 
> will help)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Review Request 51638: handle reject and release in qpid::messaging

[Gordon Sim]

> On Sept. 6, 2016, 2:34 p.m., Alan Conway wrote:
> > src/qpid/messaging/amqp/SenderContext.h, line 44
> > 
> >
> > If we do adopt the exception strategy for communicating relase/reject 
> > then I think we need a clearly marked exception hierarchy so the user can 
> > tell which exceptions destroy the link/session/connection and which don't.

None of these destroy the hierachy as viewed by the client.


- Gordon


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/51638/#review147837
---


On Sept. 5, 2016, 7:58 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51638/
> ---
> 
> (Updated Sept. 5, 2016, 7:58 p.m.)
> 
> 
> Review request for qpid and Alan Conway.
> 
> 
> Repository: qpid-cpp
> 
> 
> Description
> ---
> 
> Rejected messages cause an exception to be thrown. However this does not
> invalidate the session in anyway. More messages can be sent after
> catching the exception. The original behaviour - i.e. simply ignoring
> the rejected messages - can be obtained by setting the connection option
> 'ignore_delivery_refused' to true.
> 
> Released messages cause the transport to be aborted, triggering the usual
> resending logic (whether defined by the application or using that defined
> in the library itself). Again, released messages can be simply ignored as
> they were prior to this change by setting 'ignore_undelivered' to true.
> 
> For modified messages, if undeliverable-here is set to true, the message 
> is
> treated as if it had been rejected, otheriwse if delivery-failed is set to
> true it is treated as a released message. If neither is set it is simply
> ignored with a warning (i.e. treated as accepted).
> 
> 
> Diffs
> -
> 
>   src/qpid/messaging/ConnectionOptions.h c8c8798 
>   src/qpid/messaging/ConnectionOptions.cpp d956e9a 
>   src/qpid/messaging/amqp/ConnectionContext.cpp 25dd68d 
>   src/qpid/messaging/amqp/SenderContext.h 467a8e0 
>   src/qpid/messaging/amqp/SenderContext.cpp fe8b4d3 
>   src/qpid/messaging/amqp/SessionContext.h 67b3c1e 
>   src/qpid/messaging/amqp/SessionContext.cpp 92bdea7 
>   src/qpid/messaging/amqp/Transaction.cpp 754b00d 
> 
> Diff: https://reviews.apache.org/r/51638/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>

[jira] [Resolved] (QPID-7381) [Java Broker] Support consumer priorities

[Alex Rudyy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy resolved QPID-7381.
--
Resolution: Fixed

> [Java Broker] Support consumer priorities
> -
>
> Key: QPID-7381
> URL: https://issues.apache.org/jira/browse/QPID-7381
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Broker
>Reporter: Rob Godfrey
> Fix For: qpid-java-6.1
>
>
> Support the concept of consumer priorities.  A consumer of a lower priority 
> should only receive a message if there exists no consumer on the queue of a 
> higher priority which has credit and would accept the message if offered it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7381) [Java Broker] Support consumer priorities

[Alex Rudyy (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15467653#comment-15467653
 ] 

Alex Rudyy commented on QPID-7381:
--

The changes look good to me

> [Java Broker] Support consumer priorities
> -
>
> Key: QPID-7381
> URL: https://issues.apache.org/jira/browse/QPID-7381
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Broker
>Reporter: Rob Godfrey
> Fix For: qpid-java-6.1
>
>
> Support the concept of consumer priorities.  A consumer of a lower priority 
> should only receive a message if there exists no consumer on the queue of a 
> higher priority which has credit and would accept the message if offered it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7381) [Java Broker] Support consumer priorities

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15467639#comment-15467639
 ] 

ASF subversion and git services commented on QPID-7381:
---

Commit 1759442 from [~godfrer] in branch 'java/trunk'
[ https://svn.apache.org/r1759442 ]

QPID-7381 : Address review comments

> [Java Broker] Support consumer priorities
> -
>
> Key: QPID-7381
> URL: https://issues.apache.org/jira/browse/QPID-7381
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Broker
>Reporter: Rob Godfrey
> Fix For: qpid-java-6.1
>
>
> Support the concept of consumer priorities.  A consumer of a lower priority 
> should only receive a message if there exists no consumer on the queue of a 
> higher priority which has credit and would accept the message if offered it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7381) [Java Broker] Support consumer priorities

[Alex Rudyy (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15467617#comment-15467617
 ] 

Alex Rudyy commented on QPID-7381:
--

Rob,
Here are my review comments for changes made under revision 
[r1758900|https://svn.apache.org/r1758900]:
# The existing implementation of SendingLinkEndpoint overrides the priority 
value specified as part of properties in attach with Integer.MAX_VALUE
{code}
if (_priority < Integer.MAX_VALUE)
{
_priority = Integer.MAX_VALUE;
}
{code}
# Additionally, I am wondering whether SendingLinkEndpoint#_priority should be 
initialized to Integer.MAX_VALUE. When attach properties are missing the 
priority will be set to 0. I think that changing _priority field type to 
java.lang.Integer would be more correct and inline with other protocol 
implementations.

Documentation looks good to me.

> [Java Broker] Support consumer priorities
> -
>
> Key: QPID-7381
> URL: https://issues.apache.org/jira/browse/QPID-7381
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Broker
>Reporter: Rob Godfrey
> Fix For: qpid-java-6.1
>
>
> Support the concept of consumer priorities.  A consumer of a lower priority 
> should only receive a message if there exists no consumer on the queue of a 
> higher priority which has credit and would accept the message if offered it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-6308) [C++ Messaging] Server example never sends utf8 responses

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-6308:
--
Fix Version/s: qpid-cpp-1.35.0

> [C++ Messaging] Server example never sends utf8 responses
> -
>
> Key: QPID-6308
> URL: https://issues.apache.org/jira/browse/QPID-6308
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Client
>Affects Versions: 0.30
> Environment: Qpid trunk on Fedora 19 Linux. 
> Running C++ Broker and C++ Messaging Server example.
> Amqp.Net Lite Client example
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
> Fix For: qpid-cpp-1.35.0
>
>
> Qpid C++ Messaging and Amqp.Net Lite have some issues interoperating.
> * Amqp.Net Lite encodes/decodes strings with binary encoding primitive 
> ** str8-utf8 0xA1
> * Qpid C++ Server decodes received str8-utf8 0xA1 strings ok but sends all 
> replies with
> ** vbin8 0xA0
> * Qpid C++ Client always sends strings as
> ** vbin8 0xA0
> Modifying the Server example to:
> {noformat}
> Message response;
> response.setContentObject( request.getContentObject() );
> sender.send(response);
> {noformat}
> preserves the str8-utf8 encoding in the response but doesn't process the 
> message.
> The server example would be improved if it generated utf8 replies to utf8 
> requests.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Closed] (QPID-6355) [linearstore] Installation error

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-6355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-6355.
-

> [linearstore] Installation error
> 
>
> Key: QPID-6355
> URL: https://issues.apache.org/jira/browse/QPID-6355
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: 0.31
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>
> During installation of the linearstore, the following error message is 
> observed:
> {{error: can't copy 'src/py/qlslibs/anal.py': doesn't exist or not a regular 
> file}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Closed] (QPID-6320) Detaching and re-attaching a link with the same name fails

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-6320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-6320.
-

> Detaching and re-attaching a link with the same name fails
> --
>
> Key: QPID-6320
> URL: https://issues.apache.org/jira/browse/QPID-6320
> Project: Qpid
>  Issue Type: Bug
>Affects Versions: 0.30
>Reporter: Ted Ross
>Assignee: Gordon Sim
>Priority: Minor
>
> When synchronously attaching a sender, transferring a message, detaching the 
> sender, then attaching another sender with the same name as the first, the 
> second attach is not answered by the broker.
> The following code hangs on the second call to create_sender().
> {noformat}
> from proton import Message
> from proton.utils import BlockingConnection
> connection = BlockingConnection('amqp://localhost')
>  
> for n in range(10):
> sender = connection.create_sender('queue')
> message = Message(body='text')
> sender.send_msg(message)
> sender.close()
> print '%d - sent' % n
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-6320) Detaching and re-attaching a link with the same name fails

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-6320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-6320:
--
Component/s: (was: C++ Broker)

> Detaching and re-attaching a link with the same name fails
> --
>
> Key: QPID-6320
> URL: https://issues.apache.org/jira/browse/QPID-6320
> Project: Qpid
>  Issue Type: Bug
>Affects Versions: 0.30
>Reporter: Ted Ross
>Assignee: Gordon Sim
>Priority: Minor
>
> When synchronously attaching a sender, transferring a message, detaching the 
> sender, then attaching another sender with the same name as the first, the 
> second attach is not answered by the broker.
> The following code hangs on the second call to create_sender().
> {noformat}
> from proton import Message
> from proton.utils import BlockingConnection
> connection = BlockingConnection('amqp://localhost')
>  
> for n in range(10):
> sender = connection.create_sender('queue')
> message = Message(body='text')
> sender.send_msg(message)
> sender.close()
> print '%d - sent' % n
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-6391) [C++ Broker] [AMQP 1.0] add support for a 'no-local' filter

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-6391:
--
Fix Version/s: qpid-cpp-1.35.0

> [C++ Broker] [AMQP 1.0] add support for a 'no-local' filter
> ---
>
> Key: QPID-6391
> URL: https://issues.apache.org/jira/browse/QPID-6391
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Broker
>Affects Versions: 0.31
>Reporter: Robbie Gemmell
>Assignee: Gordon Sim
>Priority: Minor
> Fix For: qpid-cpp-1.35.0
>
>
> The JMS clients support the idea of 'no-local' on topic 
> subscriptions/consumers. This means that that subscribers/consumers dont 
> receive messages published by the same connection or, in the case of durable 
> subscriptions, by any connections with the same ClientID.
> Both the JMS clients currently use the following filter (from \[1\]) to 
> denote this:
> {noformat}
>  provides="filter">
>  code="0x468C:0x0003"/>
> 
> {noformat}
> It is likely that the AMQP JMS Mapping will eventually define its own filter 
> for this, but the expected behaviour should be the same.
> \[1\] 
> https://svn.apache.org/repos/asf/qpid/trunk/qpid/specs/apache-filters.xml#type-no-local-filter



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Closed] (QPID-5376) --socket-fd option not supported on windows broker

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-5376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-5376.
-

> --socket-fd option not supported on windows broker
> --
>
> Key: QPID-5376
> URL: https://issues.apache.org/jira/browse/QPID-5376
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Reporter: Alan Conway
>
> The unix  broker can use existing socket fds, see:
> QPID-4615: Allow unix qpidd to pass in existing socket fds on cmdline.
> The windows broker does not provide the socket-fd option.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-6757) [linearstore] Add qpid-txtest mode to qpid-qls-analyze which extracts message number from message body

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-6757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-6757:
--
Fix Version/s: qpid-cpp-1.35.0

> [linearstore] Add qpid-txtest mode to qpid-qls-analyze which extracts message 
> number from message body
> --
>
> Key: QPID-6757
> URL: https://issues.apache.org/jira/browse/QPID-6757
> Project: Qpid
>  Issue Type: Improvement
>  Components: Python Tools
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Minor
> Fix For: qpid-cpp-1.35.0
>
>
> When analysing linearstore journals using qpid-qls-analyze, it would be 
> useful to be able to see the message number which this test inserts into the 
> message body. When qpid-txtest fails, it reports these message numbers when 
> they are either missing or duplicated.
> To be able to usefully analyze a journal from this test, it is necessary to 
> be able to view this message number. However, qpid-qls-analyze does not have 
> any mechanism to display the message content except as part of a binary dump 
> of which only the first and last 10 bytes are displayed with an ellipsis:
> {{data(164)='\00\00\00p\0b\01\00\15\00\01 ... MNOPQRSTUV'}}
> By adding a command-line flag {{\-\-txtest}}, qpid-qls-analyze would search 
> the data for the string "msg-" and display the message number:
> {{data(164)='msg-1086'}}
> which is embedded in the binary and would normally be difficult to recover.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-5789) Cannot connect to broker if max-negotiate-time is set to zero

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-5789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-5789:
--
Fix Version/s: (was: qpid-cpp-next)

> Cannot connect to broker if max-negotiate-time is set to zero
> -
>
> Key: QPID-5789
> URL: https://issues.apache.org/jira/browse/QPID-5789
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: 0.28
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Trivial
>
> The broker accepts zero (0) as a valid setting for the max-negotiation-time 
> configuration parameter.  However, setting this to zero prevents clients from 
> connecting.
> A "more-sane" lower bound should be set for this parameter, or at least a 
> warning should be issued if set to zero.
> $ qpidd --max-negotiate-time 0 --auth no
> 2014-05-27 11:10:22 [Security] notice SSL plugin not enabled, you must set 
> --ssl-cert-db to enable it.
> 2014-05-27 11:10:22 [Broker] notice SASL disabled: No Authentication Performed
> 2014-05-27 11:10:22 [Network] notice Listening on TCP/TCP6 port 5672
> 2014-05-27 11:10:22 [Broker] notice Broker running
> 2014-05-27 11:10:37 [System] error Connection qpid.[::1]:5672-[::1]:34525 No 
> protocol received closing
> 2014-05-27 11:10:56 [System] error Connection qpid.[::1]:5672-[::1]:34529 No 
> protocol received closing
> Both failures occurred as a result of trying to run 'qpid-config'



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-2549) Port qpid to FreeBSD

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-2549:
--
Fix Version/s: qpid-cpp-1.35.0

> Port qpid to FreeBSD
> 
>
> Key: QPID-2549
> URL: https://issues.apache.org/jira/browse/QPID-2549
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Broker
>Affects Versions: 0.6
> Environment: FreeBSD 8-CURRENT on amd64 (64 bit)
> $ g++ -v
> Using built-in specs.
> Target: amd64-undermydesk-freebsd
> Configured with: FreeBSD/amd64 system compiler
> Thread model: posix
> gcc version 4.2.1 20070719  [FreeBSD]
> $ python -V
> Python 2.6.1
> $ pkg_info | grep boost
> boost-python-1.37.0 Free peer-reviewed portable C++ source libraries
> svn trunk version, checked out now (r765092)
> ./configure CPPFLAGS="-I/usr/local/include -L/usr/local/lib" 
> LDFLAGS="-L/usr/local/lib" --with-poller=poll
>Reporter: Andrew Stitcher
>  Labels: freebsd, porting
> Fix For: qpid-cpp-1.35.0
>
>
> For qpid to work on FreeBSD it needs a version of the low level Poller code 
> that works there:
> [Comments from original reporter below]
> g++ -Werror -pedantic -Wall -Wextra -Wno-shadow -Wpointer-arith -Wcast-qual 
> -Wcast-align -Wno-long-long -Wvolatile-register-var -Winvalid-pch 
> -Wno-system-headers -Woverloaded-virtual 
> -DMODULE_DIR=\"/usr/local/lib/qpid/daemon\" 
> -DCONF_FILE=\"/usr/local/etc/qpidd.conf\" -g -O2 -o .libs/qpidd qpidd-qpidd.o 
> posix/qpidd-QpiddBroker.o  -L/usr/local/lib -L/usr/lib/openais 
> -L/usr/lib64/openais -L/usr/lib/corosync -L/usr/lib64/corosync 
> ./.libs/libqpidbroker.so /test/qpid/qpid/cpp/src/.libs/libqpidcommon.so 
> ./.libs/libqpidcommon.so -lboost_program_options -lboost_filesystem -luuid 
> -Wl,--rpath -Wl,/usr/local/lib
> /test/qpid/qpid/cpp/src/.libs/libqpidcommon.so: undefined reference to 
> `qpid::sys::Poller::interrupt(qpid::sys::PollerHandle&)'
> /test/qpid/qpid/cpp/src/.libs/libqpidcommon.so: undefined reference to 
> `typeinfo for qpid::sys::PollerHandle'
> ./.libs/libqpidbroker.so: undefined reference to 
> `qpid::sys::Poller::shutdown()'
> /test/qpid/qpid/cpp/src/.libs/libqpidcommon.so: undefined reference to 
> `qpid::sys::PollerHandle::~PollerHandle()'
> ./.libs/libqpidbroker.so: undefined reference to `qpid::sys::Poller::Poller()'
> /test/qpid/qpid/cpp/src/.libs/libqpidcommon.so: undefined reference to 
> `qpid::sys::Poller::addFd(qpid::sys::PollerHandle&, 
> qpid::sys::Poller::Direction)'
> /test/qpid/qpid/cpp/src/.libs/libqpidcommon.so: undefined reference to 
> `qpid::sys::Poller::delFd(qpid::sys::PollerHandle&)'
> /test/qpid/qpid/cpp/src/.libs/libqpidcommon.so: undefined reference to 
> `qpid::sys::PollerHandle::PollerHandle(qpid::sys::IOHandle const&)'
> /test/qpid/qpid/cpp/src/.libs/libqpidcommon.so: undefined reference to 
> `qpid::sys::Poller::modFd(qpid::sys::PollerHandle&, 
> qpid::sys::Poller::Direction)'
> I think it would be nice to have at least a standard select/poll interface. 
> Going straight with (and only with) the specialised OS-dependent interfaces 
> seem to be a bad idea for the poor people, not running Linux (or Solaris, or 
> Windows, if they work correctly).
> BTW, shouldn't using libevent or libev would be more logical?
> [Comments from AStitcher:]
> There are two essential options here write a Poller using the kqueue which 
> has very similar capability to the Linux epoll, or write a less functional 
> (and probably performant) but far more portable version using the posix poll.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-7406) release doesn't reset cursors for active consumers on LVQ

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-7406:
--
Fix Version/s: qpid-cpp-1.36.0

> release doesn't reset cursors for active consumers on LVQ
> -
>
> Key: QPID-7406
> URL: https://issues.apache.org/jira/browse/QPID-7406
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: qpid-cpp-1.35.0
>Reporter: Gordon Sim
>Assignee: Gordon Sim
> Fix For: qpid-cpp-1.36.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-7406) release doesn't reset cursors for active consumers on LVQ

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-7406:
--
Affects Version/s: (was: qpid-cpp-next)
   qpid-cpp-1.35.0

> release doesn't reset cursors for active consumers on LVQ
> -
>
> Key: QPID-7406
> URL: https://issues.apache.org/jira/browse/QPID-7406
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: qpid-cpp-1.35.0
>Reporter: Gordon Sim
>Assignee: Gordon Sim
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-7100) qpid-perftest divide by zero when mode is shared and nsubs is zero

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-7100:
--
Fix Version/s: qpid-cpp-1.35.0

> qpid-perftest divide by zero when mode is shared and nsubs is zero
> --
>
> Key: QPID-7100
> URL: https://issues.apache.org/jira/browse/QPID-7100
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Client
>Affects Versions: qpid-cpp-0.34
>Reporter: ylg
>Assignee: Gordon Sim
>Priority: Minor
> Fix For: qpid-cpp-1.35.0
>
> Attachments: qpid-perftest-fix-divide-by-zero.patch
>
>
> when test mode is shared mode, qpid-perftest divides by zero when nsubs is 
> zero.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-7373) memory leak in broker with idle worker threads

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-7373:
--
Fix Version/s: qpid-cpp-1.35.0

> memory leak in broker with idle worker threads
> --
>
> Key: QPID-7373
> URL: https://issues.apache.org/jira/browse/QPID-7373
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: qpid-cpp-0.34
> Environment: linux epoll and perhaps PosixPoller and Solaris ECFPoller
>Reporter: Cliff Jansen
>Assignee: Cliff Jansen
> Fix For: qpid-cpp-1.35.0
>
>
> If a C++ broker is lightly loaded with many short lived connections such that 
> at least one worker thread remains unwoken from the epoll_wait, its 
> DeletionManager::ThreadStatus::handles grows without bound and the associated 
> handles retain a shared_ptr ref and never go away.
> To reproduce check RSS from ps (or malloc_stats) when running a simple 
> program that creates a connection and nothing else:
> hex5:  cat foo.cpp
> {code}
> #include 
> #include 
> using namespace qpid::messaging;
> int main(int argc, char** argv) {
> std::string broker = argc > 1 ? argv[1] : "127.0.0.1:5672";
> Connection connection(broker);
> try {
> connection.open();
> connection.close();
> return 0;
> } catch(const std::exception& error) {
> std::cerr << error.what() << std::endl;
> connection.close();
> return 1;   
> }
> }
> {code}
> hex5:  while true; do LD_LIBRARY_PATH=../rt/b/amqp/b/q35x/rt/lib64 ./foo ; 
> done



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Closed] (QPID-7090) qpidd should not use root as user

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-7090.
-

> qpidd should not use root as user
> -
>
> Key: QPID-7090
> URL: https://issues.apache.org/jira/browse/QPID-7090
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Broker
>Affects Versions: qpid-cpp-0.34
> Environment: Debian/Ubuntu
>Reporter: Morgan Lindqvist
>Assignee: Irina Boverman
>Priority: Minor
>  Labels: features, packaging, security
>
> When using the testing PPA on https://launchpad.net/~qpid to install qpidd 
> the daemon is executed using the user id and group id "root".
> The user id and group id that should be used is "qpidd".
> This will significantly reduce the risk the the daemon can be used to get 
> root access on the server.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (QPID-6771) Can't compile qpidbroker with vc2008

[Andrew Stitcher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Stitcher resolved QPID-6771.
---
Resolution: Not A Bug

> Can't compile qpidbroker with vc2008
> 
>
> Key: QPID-6771
> URL: https://issues.apache.org/jira/browse/QPID-6771
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: qpid-cpp-0.34
> Environment: Windows xp sp3, VC2008 no sp,boost 1.59.0
>Reporter: sxf
> Fix For: qpid-cpp-1.36.0
>
>
> 1) qpid-cpp-0.34\src\qpid\sys\regex.h
> qpid-cpp-0.34\src\qpid/sys/regex.h(27) : fatal error C1083: 无法打开包括文件:"regex": 
> No such file or directory
> from:
> #if defined(_POSIX_SOURCE) || defined(__unix__)
> # include 
> # include 
> # include 
> #elif defined(_MSC_VER)
> # include 
> #else
> #error "No known regex implementation"
> #endif
> to:
> #if defined(_POSIX_SOURCE) || defined(__unix__)
> # include 
> # include 
> # include 
> #elif (_MSC_VER > 1500)
> # include 
> #elif (_MSC_VER <= 1500)
> # include 
> #else
> #error "No known regex implementation"
> #endif
> 2)qpid-cpp-0.34\src\qpid\sys\unordered_map.h
> qpid-cpp-0.34\src\qpid/sys/unordered_map.h(25) : fatal error C1083: 
> 无法打开包括文件:"unordered_map": No such file or directory
> from:
> #if defined(_MSC_VER) || defined(_LIBCPP_VERSION) || __cplusplus >= 201103L
> #  include 
> #elif defined(__SUNPRO_CC) || defined(__IBMCPP__)
> #  include 
> #else
> #  include 
> #endif /* _MSC_VER */
> to:
> #if (_MSC_VER > 1500) || defined(_LIBCPP_VERSION) || __cplusplus >= 201103L
> #  include 
> #elif (_MSC_VER <= 1500) || defined(__SUNPRO_CC) || defined(__IBMCPP__)
> #  include 
> #else
> #  include 
> #endif /* _MSC_VER */
> 3)..\..\..\src\tests\exception_test.cpp(66) : error C3861: "BOOST_MESSAGE": 
> 找不到标识符
> from:
> void run() {
> try {
> ScopedSuppressLogging sl; // Suppress messages for expected 
> errors.
> f();
> }
> catch(const Ex& e) {
> caught=true;
> BOOST_MESSAGE(string("Caught expected exception: 
> ")+e.what()+"["+typeid(e).name()+"]");
> to:
> void run() {
> try {
> ScopedSuppressLogging sl; // Suppress messages for expected 
> errors.
> f();
> }
> catch(const Ex& e) {
> caught=true;
> BOOST_ERROR(string("Caught expected exception: 
> ")+e.what()+"["+typeid(e).name()+"]");



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Review Request 51638: handle reject and release in qpid::messaging

[Alan Conway]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/51638/#review147837
---



I don't think this is the right fix.

Aborting the connection is a nasty hack for backwards compatibility with *old 
clients* that don't have any features for re-sending released messages. It 
doesn't make sense to put this feature in the client, that doesn't help with 
*old* clients. The abort hack is a job for the router. Ideally the router would 
check connection properties for "I-can-resend-released-messages", and if it 
doesn't find that, abort instead of sending a release. We also probably want 
config to enable/disable the feature per listner/connector. That means 
unmodified old clients (and clients from other vendors) can work with dispatch.

I'm not sure that we even want to touch messaging clients with the above router 
fix. The desirable behavior for new clients is to *not* tear down the 
connection or link on a released message, but just to re-send the released 
messages. We'll need a new set of configuration controls for how this works and 
we'll need to track re-sending per-link, not per-connection or session. I think 
we should allow the following configured possibilities:

1. same behavior as now
2. inform the user of the release, similar to what you propose for reject.
3. auto re-send on the same link according to configured intervals, retry 
limits etc.

1+2 are essential, we can take more time to design 3 since 2 allows the user to 
implement their own strategy till we have a good general-purpose automated 
strategy. Message retry config will likely be similar to connection retry but I 
expect we'll find some important differences when we start to design it.


src/qpid/messaging/amqp/SenderContext.h (line 44)


If we do adopt the exception strategy for communicating relase/reject then 
I think we need a clearly marked exception hierarchy so the user can tell which 
exceptions destroy the link/session/connection and which don't.


- Alan Conway


On Sept. 5, 2016, 7:58 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51638/
> ---
> 
> (Updated Sept. 5, 2016, 7:58 p.m.)
> 
> 
> Review request for qpid and Alan Conway.
> 
> 
> Repository: qpid-cpp
> 
> 
> Description
> ---
> 
> Rejected messages cause an exception to be thrown. However this does not
> invalidate the session in anyway. More messages can be sent after
> catching the exception. The original behaviour - i.e. simply ignoring
> the rejected messages - can be obtained by setting the connection option
> 'ignore_delivery_refused' to true.
> 
> Released messages cause the transport to be aborted, triggering the usual
> resending logic (whether defined by the application or using that defined
> in the library itself). Again, released messages can be simply ignored as
> they were prior to this change by setting 'ignore_undelivered' to true.
> 
> For modified messages, if undeliverable-here is set to true, the message 
> is
> treated as if it had been rejected, otheriwse if delivery-failed is set to
> true it is treated as a released message. If neither is set it is simply
> ignored with a warning (i.e. treated as accepted).
> 
> 
> Diffs
> -
> 
>   src/qpid/messaging/ConnectionOptions.h c8c8798 
>   src/qpid/messaging/ConnectionOptions.cpp d956e9a 
>   src/qpid/messaging/amqp/ConnectionContext.cpp 25dd68d 
>   src/qpid/messaging/amqp/SenderContext.h 467a8e0 
>   src/qpid/messaging/amqp/SenderContext.cpp fe8b4d3 
>   src/qpid/messaging/amqp/SessionContext.h 67b3c1e 
>   src/qpid/messaging/amqp/SessionContext.cpp 92bdea7 
>   src/qpid/messaging/amqp/Transaction.cpp 754b00d 
> 
> Diff: https://reviews.apache.org/r/51638/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>

[jira] [Updated] (QPID-7171) Allow disable-auto-decode to be set via env var or conf file

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-7171:
--
Fix Version/s: qpid-cpp-1.35.0

> Allow disable-auto-decode to be set via env var or conf file
> 
>
> Key: QPID-7171
> URL: https://issues.apache.org/jira/browse/QPID-7171
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Client
>Affects Versions: qpid-cpp-0.34
>Reporter: Gordon Sim
>Assignee: Gordon Sim
> Fix For: qpid-cpp-1.35.0
>
>
> The 0-10 path in qpid::messaging now automatically decodes AMQP 0-10 maps and 
> lists (identified by their content type) in order to populate the 
> content-object of the message and give similar behaviour to the 1.0 path.
> This is however a change in behaviour and may not be desired by all legacy 
> users. There is a connection level option to disable this feature. However 
> requiring every connection to be explicitly configured is not always 
> desirable either. It would be preferable to allow the behaviour to be 
> controlled as a client option, via environment variables or through the 
> client config file.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-6771) Can't compile qpidbroker with vc2008

[Andrew Stitcher (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15467565#comment-15467565
 ] 

Andrew Stitcher commented on QPID-6771:
---

[~jr...@redhat.com] This is not a problem with VC2008 in general as this code 
has compiled with 2008sp1. The reporter has not confirmed a bug in the latest 
service opack of 2008. So I'll close this as not a bug.

> Can't compile qpidbroker with vc2008
> 
>
> Key: QPID-6771
> URL: https://issues.apache.org/jira/browse/QPID-6771
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: qpid-cpp-0.34
> Environment: Windows xp sp3, VC2008 no sp,boost 1.59.0
>Reporter: sxf
> Fix For: qpid-cpp-1.36.0
>
>
> 1) qpid-cpp-0.34\src\qpid\sys\regex.h
> qpid-cpp-0.34\src\qpid/sys/regex.h(27) : fatal error C1083: 无法打开包括文件:"regex": 
> No such file or directory
> from:
> #if defined(_POSIX_SOURCE) || defined(__unix__)
> # include 
> # include 
> # include 
> #elif defined(_MSC_VER)
> # include 
> #else
> #error "No known regex implementation"
> #endif
> to:
> #if defined(_POSIX_SOURCE) || defined(__unix__)
> # include 
> # include 
> # include 
> #elif (_MSC_VER > 1500)
> # include 
> #elif (_MSC_VER <= 1500)
> # include 
> #else
> #error "No known regex implementation"
> #endif
> 2)qpid-cpp-0.34\src\qpid\sys\unordered_map.h
> qpid-cpp-0.34\src\qpid/sys/unordered_map.h(25) : fatal error C1083: 
> 无法打开包括文件:"unordered_map": No such file or directory
> from:
> #if defined(_MSC_VER) || defined(_LIBCPP_VERSION) || __cplusplus >= 201103L
> #  include 
> #elif defined(__SUNPRO_CC) || defined(__IBMCPP__)
> #  include 
> #else
> #  include 
> #endif /* _MSC_VER */
> to:
> #if (_MSC_VER > 1500) || defined(_LIBCPP_VERSION) || __cplusplus >= 201103L
> #  include 
> #elif (_MSC_VER <= 1500) || defined(__SUNPRO_CC) || defined(__IBMCPP__)
> #  include 
> #else
> #  include 
> #endif /* _MSC_VER */
> 3)..\..\..\src\tests\exception_test.cpp(66) : error C3861: "BOOST_MESSAGE": 
> 找不到标识符
> from:
> void run() {
> try {
> ScopedSuppressLogging sl; // Suppress messages for expected 
> errors.
> f();
> }
> catch(const Ex& e) {
> caught=true;
> BOOST_MESSAGE(string("Caught expected exception: 
> ")+e.what()+"["+typeid(e).name()+"]");
> to:
> void run() {
> try {
> ScopedSuppressLogging sl; // Suppress messages for expected 
> errors.
> f();
> }
> catch(const Ex& e) {
> caught=true;
> BOOST_ERROR(string("Caught expected exception: 
> ")+e.what()+"["+typeid(e).name()+"]");



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Closed] (QPID-6837) update the 'tested proton version' message prior to next release

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-6837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-6837.
-
Resolution: Duplicate

> update the 'tested proton version' message prior to next release
> 
>
> Key: QPID-6837
> URL: https://issues.apache.org/jira/browse/QPID-6837
> Project: Qpid
>  Issue Type: Task
>  Components: C++ Broker, C++ Client
>Reporter: Robbie Gemmell
>Priority: Trivial
>
> When building against the Proton 0.11.0 RC, the qpid-cpp trunk currently logs 
> out "Qpid proton 0.11.0 is not a tested version and might not be compatible, 
> 0.9 is highest tested; build may not work". That is because 0.9 was the 
> latest available when qpid-cpp 0.34 went out, we should update the message 
> before the next cpp release occurs to whatever the latest tested proton 
> version is at the time.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-6837) update the 'tested proton version' message prior to next release

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-6837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-6837:
--
Fix Version/s: (was: qpid-cpp-next)

> update the 'tested proton version' message prior to next release
> 
>
> Key: QPID-6837
> URL: https://issues.apache.org/jira/browse/QPID-6837
> Project: Qpid
>  Issue Type: Task
>  Components: C++ Broker, C++ Client
>Reporter: Robbie Gemmell
>Priority: Trivial
>
> When building against the Proton 0.11.0 RC, the qpid-cpp trunk currently logs 
> out "Qpid proton 0.11.0 is not a tested version and might not be compatible, 
> 0.9 is highest tested; build may not work". That is because 0.9 was the 
> latest available when qpid-cpp 0.34 went out, we should update the message 
> before the next cpp release occurs to whatever the latest tested proton 
> version is at the time.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (QPID-6856) Move the qpid-cpp components to their own source tree

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-6856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross resolved QPID-6856.
---
Resolution: Done

> Move the qpid-cpp components to their own source tree
> -
>
> Key: QPID-6856
> URL: https://issues.apache.org/jira/browse/QPID-6856
> Project: Qpid
>  Issue Type: Task
>  Components: C++ Broker, C++ Client, C++ Clustering, Tools, WCF/C++ 
> Client
>Affects Versions: qpid-cpp-0.34
>Reporter: Ken Giusti
>Assignee: Justin Ross
> Fix For: qpid-cpp-next, qpid-tools-next
>
>
> See 
> http://qpid.2158936.n2.nabble.com/VOTE-Use-semantic-versioning-for-the-qpid-cpp-components-td7633540.html#a7633588



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-6771) Can't compile qpidbroker with vc2008

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-6771:
--
Fix Version/s: (was: qpid-cpp-next)
   qpid-cpp-1.36.0

> Can't compile qpidbroker with vc2008
> 
>
> Key: QPID-6771
> URL: https://issues.apache.org/jira/browse/QPID-6771
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: qpid-cpp-0.34
> Environment: Windows xp sp3, VC2008 no sp,boost 1.59.0
>Reporter: sxf
> Fix For: qpid-cpp-1.36.0
>
>
> 1) qpid-cpp-0.34\src\qpid\sys\regex.h
> qpid-cpp-0.34\src\qpid/sys/regex.h(27) : fatal error C1083: 无法打开包括文件:"regex": 
> No such file or directory
> from:
> #if defined(_POSIX_SOURCE) || defined(__unix__)
> # include 
> # include 
> # include 
> #elif defined(_MSC_VER)
> # include 
> #else
> #error "No known regex implementation"
> #endif
> to:
> #if defined(_POSIX_SOURCE) || defined(__unix__)
> # include 
> # include 
> # include 
> #elif (_MSC_VER > 1500)
> # include 
> #elif (_MSC_VER <= 1500)
> # include 
> #else
> #error "No known regex implementation"
> #endif
> 2)qpid-cpp-0.34\src\qpid\sys\unordered_map.h
> qpid-cpp-0.34\src\qpid/sys/unordered_map.h(25) : fatal error C1083: 
> 无法打开包括文件:"unordered_map": No such file or directory
> from:
> #if defined(_MSC_VER) || defined(_LIBCPP_VERSION) || __cplusplus >= 201103L
> #  include 
> #elif defined(__SUNPRO_CC) || defined(__IBMCPP__)
> #  include 
> #else
> #  include 
> #endif /* _MSC_VER */
> to:
> #if (_MSC_VER > 1500) || defined(_LIBCPP_VERSION) || __cplusplus >= 201103L
> #  include 
> #elif (_MSC_VER <= 1500) || defined(__SUNPRO_CC) || defined(__IBMCPP__)
> #  include 
> #else
> #  include 
> #endif /* _MSC_VER */
> 3)..\..\..\src\tests\exception_test.cpp(66) : error C3861: "BOOST_MESSAGE": 
> 找不到标识符
> from:
> void run() {
> try {
> ScopedSuppressLogging sl; // Suppress messages for expected 
> errors.
> f();
> }
> catch(const Ex& e) {
> caught=true;
> BOOST_MESSAGE(string("Caught expected exception: 
> ")+e.what()+"["+typeid(e).name()+"]");
> to:
> void run() {
> try {
> ScopedSuppressLogging sl; // Suppress messages for expected 
> errors.
> f();
> }
> catch(const Ex& e) {
> caught=true;
> BOOST_ERROR(string("Caught expected exception: 
> ")+e.what()+"["+typeid(e).name()+"]");



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-7236) Uninitialised values in AclRule

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-7236:
--
Fix Version/s: (was: qpid-cpp-next)
   qpid-cpp-1.36.0

> Uninitialised values in AclRule
> ---
>
> Key: QPID-7236
> URL: https://issues.apache.org/jira/browse/QPID-7236
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Reporter: Gordon Sim
>Assignee: Gordon Sim
> Fix For: qpid-cpp-1.36.0
>
>
> Valgrind shows reads of uninitialised action/object.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-6774) Can't compile unit_test with boost 1.59.0

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-6774:
--
Fix Version/s: (was: qpid-cpp-next)
   qpid-cpp-1.36.0

> Can't compile unit_test with boost 1.59.0
> -
>
> Key: QPID-6774
> URL: https://issues.apache.org/jira/browse/QPID-6774
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: qpid-cpp-0.34
> Environment: Windows xp sp3, VC2008 no sp,boost 1.59.0
>Reporter: sxf
> Fix For: qpid-cpp-1.36.0
>
>
> QPID-6771:
> 3)..\..\..\src\tests\exception_test.cpp(66) : error C3861: "BOOST_MESSAGE": 
> 找不到标识符
> BOOST_MESSAGE was removed from boost 1.59.0, we should add it.
>  
> from:
> namespace tests {
> QPID_AUTO_TEST_SUITE(exception_test)
> to:
> namespace tests {
> #ifndef BOOST_MESSAGE
> #define BOOST_MESSAGE( M )  BOOST_TEST_MESSAGE( M )
> #endif
> QPID_AUTO_TEST_SUITE(exception_test)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-6307) Link starvation may occur when multiple links within a connection consume from the same queue

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-6307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-6307:
--
Fix Version/s: (was: qpid-cpp-next)

> Link starvation may occur when multiple links within a connection consume 
> from the same queue
> -
>
> Key: QPID-6307
> URL: https://issues.apache.org/jira/browse/QPID-6307
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: 0.30
>Reporter: Ken Giusti
> Attachments: recv-order.py
>
>
> When multiple links on the same connection are competing for messages on the 
> same queue, if the messages arrive at a slow rate one link will end up 
> consuming all the messages.  
> Messages should be load balanced across all the consuming links within the 
> connection.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-6699) Improve/clarify the qpid::sys::Time interface

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-6699:
--
Fix Version/s: (was: qpid-cpp-next)

> Improve/clarify the qpid::sys::Time interface
> -
>
> Key: QPID-6699
> URL: https://issues.apache.org/jira/browse/QPID-6699
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Broker, C++ Client
>Affects Versions: qpid-cpp-0.34
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>
> Gordon Sim raised a suggestion during a review of a patch for QPID-6698:
> "I do also think that the Time.h should be modified/augmented somehow to make 
> issues like this clearer. E.g. a Duration::FromZero() alongside the FromEpoch 
> with clear advice as to which to use when? The AbsTime::epoch() method 
> subtracts a FromEpoch duration, computed using the realtime clock, from the 
> now() which is computed from the monotonic clock. Is that even valid? These 
> are arguably separate issues though, just raising tnem for debate."
> I'd like to see the interface changed as per Gordon's description.  Clarify 
> which APIs deal with realtime (wall clock) and monotonic clocks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-5628) Build fails when both python 2.7 and 3 are installed

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-5628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-5628:
--
Fix Version/s: (was: qpid-cpp-next)

> Build fails when both python 2.7 and 3 are installed
> 
>
> Key: QPID-5628
> URL: https://issues.apache.org/jira/browse/QPID-5628
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker, C++ Client
>Affects Versions: 0.26
> Environment: Ubuntu Saucy
>Reporter: Sébastien GALLET
>Assignee: Ken Giusti
>  Labels: patch
> Attachments: python2.patch
>
>
> When python 2.7 and python 3 are installed, the cmake scripts use python 3 to 
> build bindings ... and it fails
> [ 97%] Building CXX object 
> bindings/qpid/python/CMakeFiles/_qpid_messaging.dir/pythonPYTHON_wrap.cxx.o
> cd 
> /home/sebastien/devel/admin-repository/qpid-cpp/qpid-cpp-0.26/obj-x86_64-linux-gnu/bindings/qpid/python
>  && /usr/bin/c++   -D_qpid_messaging_EXPORTS -g -O2 -fstack-protector 
> --param=ssp-buffer-size=4 -Wformat -Werror=format-security 
> -Wno-error=cast-qual -Wno-error=cast-align -D_FORTIFY_SOURCE=2  -O2 -g 
> -DNDEBUG -fPIC -I/usr/include/python3.3m 
> -I/home/sebastien/devel/admin-repository/qpid-cpp/qpid-cpp-0.26/include 
> -I/home/sebastien/devel/admin-repository/qpid-cpp/qpid-cpp-0.26/bindings
> -fno-strict-aliasing -o 
> CMakeFiles/_qpid_messaging.dir/pythonPYTHON_wrap.cxx.o -c 
> /home/sebastien/devel/admin-repository/qpid-cpp/qpid-cpp-0.26/obj-x86_64-linux-gnu/bindings/qpid/python/pythonPYTHON_wrap.cxx
> /home/sebastien/devel/admin-repository/qpid-cpp/qpid-cpp-0.26/obj-x86_64-linux-gnu/bindings/qpid/python/pythonPYTHON_wrap.cxx:
>  In function ‘qpid::types::Variant PyToVariant(PyObject*)’:
> /home/sebastien/devel/admin-repository/qpid-cpp/qpid-cpp-0.26/obj-x86_64-linux-gnu/bindings/qpid/python/pythonPYTHON_wrap.cxx:3620:88:
>  error: ‘PyInt_AS_LONG’ was not declared in this scope
>  if (PyBool_Check(value))   return 
> qpid::types::Variant(bool(PyInt_AS_LONG(value) ? true : false));
>   
>   ^
> /home/sebastien/devel/admin-repository/qpid-cpp/qpid-cpp-0.26/obj-x86_64-linux-gnu/bindings/qpid/python/pythonPYTHON_wrap.cxx:3622:91:
>  error: ‘PyInt_AS_LONG’ was not declared in this scope
>  if (PyInt_Check(value))return 
> qpid::types::Variant(int64_t(PyInt_AS_LONG(value)));
>   
>  ^
> /home/sebastien/devel/admin-repository/qpid-cpp/qpid-cpp-0.26/obj-x86_64-linux-gnu/bindings/qpid/python/pythonPYTHON_wrap.cxx:756:52:
>  error: ‘PyUnicode_AS_STRING’ was not declared in this scope
>  #define PyString_AS_STRING(x) PyUnicode_AS_STRING(x)
> ^
> /home/sebastien/devel/admin-repository/qpid-cpp/qpid-cpp-0.26/obj-x86_64-linux-gnu/bindings/qpid/python/pythonPYTHON_wrap.cxx:3624:76:
>  note: in expansion of macro ‘PyString_AS_STRING’
>  if (PyString_Check(value)) return 
> qpid::types::Variant(std::string(PyString_AS_STRING(value)));
> ^
> /home/sebastien/devel/admin-repository/qpid-cpp/qpid-cpp-0.26/obj-x86_64-linux-gnu/bindings/qpid/python/pythonPYTHON_wrap.cxx:
>  In function ‘PyObject* VariantToPy(const qpid::types::Variant*)’:
> /home/sebastien/devel/admin-repository/qpid-cpp/qpid-cpp-0.26/obj-x86_64-linux-gnu/bindings/qpid/python/pythonPYTHON_wrap.cxx:3688:80:
>  error: ‘PyString_FromStringAndSize’ was not declared in this scope
>  result = PyString_FromStringAndSize(val.c_str(), 
> val.size());
>   
>   ^
> /home/sebastien/devel/admin-repository/qpid-cpp/qpid-cpp-0.26/obj-x86_64-linux-gnu/bindings/qpid/python/pythonPYTHON_wrap.cxx:
>  In function ‘PyObject* MapToPy(const Map*)’:
> /home/sebastien/devel/admin-repository/qpid-cpp/qpid-cpp-0.26/obj-x86_64-linux-gnu/bindings/qpid/python/pythonPYTHON_wrap.cxx:3721:86:
>  error: ‘PyString_FromStringAndSize’ was not declared in this scope
>  PyDict_SetItem(result, PyString_FromStringAndSize(key.c_str(), 
> key.size()), pyval);
>   
> ^
> /home/sebastien/devel/admin-repository/qpid-cpp/qpid-cpp-0.26/obj-x86_64-linux-gnu/bindings/qpid/python/pythonPYTHON_wrap.cxx:
>  In function ‘PyObject* UuidToPy(const qpid::types::Uuid*)’:
> /home/sebastien/devel/admin-repository/qpid-cpp/qpid-cpp-0.26/obj-x86_64-linux-gnu/bindings/qpid/python/pythonPYTHON_wrap.cxx:3750:42:
>  error: ‘PyString_FromStringAndSize’ was not declared in this scope
>(const char*)(uuid->data()), 16);
>

[jira] [Closed] (QPID-6857) Adopt semantic versioning. Set major release # to 1

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-6857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-6857.
-

> Adopt semantic versioning.  Set major release # to 1
> 
>
> Key: QPID-6857
> URL: https://issues.apache.org/jira/browse/QPID-6857
> Project: Qpid
>  Issue Type: Task
>  Components: C++ Broker, C++ Client, C++ Clustering, Tools
>Affects Versions: qpid-cpp-0.34
>Reporter: Ken Giusti
>Assignee: Justin Ross
> Fix For: qpid-cpp-1.35.0
>
>
> See
> http://qpid.2158936.n2.nabble.com/VOTE-Use-semantic-versioning-for-the-qpid-cpp-components-td7633540.html#a7633588



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (QPID-6857) Adopt semantic versioning. Set major release # to 1

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-6857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross resolved QPID-6857.
---
Resolution: Done

> Adopt semantic versioning.  Set major release # to 1
> 
>
> Key: QPID-6857
> URL: https://issues.apache.org/jira/browse/QPID-6857
> Project: Qpid
>  Issue Type: Task
>  Components: C++ Broker, C++ Client, C++ Clustering, Tools
>Affects Versions: qpid-cpp-0.34
>Reporter: Ken Giusti
>Assignee: Justin Ross
> Fix For: qpid-cpp-1.35.0
>
>
> See
> http://qpid.2158936.n2.nabble.com/VOTE-Use-semantic-versioning-for-the-qpid-cpp-components-td7633540.html#a7633588



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-6857) Adopt semantic versioning. Set major release # to 1

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-6857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-6857:
--
Fix Version/s: (was: qpid-tools-next)
   (was: qpid-cpp-next)
   qpid-cpp-1.35.0

> Adopt semantic versioning.  Set major release # to 1
> 
>
> Key: QPID-6857
> URL: https://issues.apache.org/jira/browse/QPID-6857
> Project: Qpid
>  Issue Type: Task
>  Components: C++ Broker, C++ Client, C++ Clustering, Tools
>Affects Versions: qpid-cpp-0.34
>Reporter: Ken Giusti
>Assignee: Justin Ross
> Fix For: qpid-cpp-1.35.0
>
>
> See
> http://qpid.2158936.n2.nabble.com/VOTE-Use-semantic-versioning-for-the-qpid-cpp-components-td7633540.html#a7633588



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Closed] (QPID-6856) Move the qpid-cpp components to their own source tree

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-6856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-6856.
-

> Move the qpid-cpp components to their own source tree
> -
>
> Key: QPID-6856
> URL: https://issues.apache.org/jira/browse/QPID-6856
> Project: Qpid
>  Issue Type: Task
>  Components: C++ Broker, C++ Client, C++ Clustering, Tools, WCF/C++ 
> Client
>Affects Versions: qpid-cpp-0.34
>Reporter: Ken Giusti
>Assignee: Justin Ross
> Fix For: qpid-cpp-1.35.0
>
>
> See 
> http://qpid.2158936.n2.nabble.com/VOTE-Use-semantic-versioning-for-the-qpid-cpp-components-td7633540.html#a7633588



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-6856) Move the qpid-cpp components to their own source tree

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-6856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-6856:
--
Fix Version/s: (was: qpid-tools-next)
   (was: qpid-cpp-next)
   qpid-cpp-1.35.0

> Move the qpid-cpp components to their own source tree
> -
>
> Key: QPID-6856
> URL: https://issues.apache.org/jira/browse/QPID-6856
> Project: Qpid
>  Issue Type: Task
>  Components: C++ Broker, C++ Client, C++ Clustering, Tools, WCF/C++ 
> Client
>Affects Versions: qpid-cpp-0.34
>Reporter: Ken Giusti
>Assignee: Justin Ross
> Fix For: qpid-cpp-1.35.0
>
>
> See 
> http://qpid.2158936.n2.nabble.com/VOTE-Use-semantic-versioning-for-the-qpid-cpp-components-td7633540.html#a7633588



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (PROTON-1296) IllegalStateException on reconnect

[Mark Soderquist (JIRA)]

Mark Soderquist created PROTON-1296:
---

 Summary: IllegalStateException on reconnect
 Key: PROTON-1296
 URL: https://issues.apache.org/jira/browse/PROTON-1296
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Affects Versions: 0.10
Reporter: Mark Soderquist


We are using Mule ESB to integrate with several Qpid message servers. On 
occasion, an IllegalStateException is thrown while reconnecting resulting in an 
endless loop of reconnection attempts. The full exception message indicates 
that the max frame size cannot be set after transport has been initialised. 
Unfortunately, throwing an exception in this circumstance simply results in an 
endless loop.

It is understandable that the max frame size should not be set again after the 
transport has been initialized, but would it be reasonable to log it as a 
warning and not throw an exception?

Here is an example of the exception we see:
ERROR 2016-09-01 08:21:41,145 [[emxrouter-core].Mule.02] 
org.mule.retry.notifiers.ConnectNotifier: Failed to connect/reconnect: 
jms://emx-router. Root Exception was: Cannot set max frame size after transport 
has been initialised. Type: class java.lang.IllegalStateException




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (QPID-7416) [Java Broker] Modification of secure attributes and creation of configured objects with specifying secure attributes should not be permitted by default on insecure connect

[Alex Rudyy (JIRA)]

Alex Rudyy created QPID-7416:


 Summary: [Java Broker] Modification of secure attributes and 
creation of configured objects with specifying secure attributes should not be 
permitted by default on insecure connections
 Key: QPID-7416
 URL: https://issues.apache.org/jira/browse/QPID-7416
 Project: Qpid
  Issue Type: Improvement
  Components: Java Broker
Reporter: Alex Rudyy


With changes in QPID-7380 the REST layer prevents performing of secure 
operations (both modifying and non-modifying) on insecure connections. It seems 
that modification of secure attributes and creation of configured object with 
secure attributes should not be allowed by default on insecure connections as 
well, in order to avoid interception of such sensitive data as passwords, 
private keys, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7380) [Java Broker] Managed Operations returning potentially confidential information should not be permitted by default on insecure connections

[Alex Rudyy (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15467399#comment-15467399
 ] 

Alex Rudyy commented on QPID-7380:
--

The changes committed under revision [r1759209|https://svn.apache.org/r1759209] 
look reasonable to me. Although, I agree that caching of headers inclusion flag 
would be beneficial. Thus, I made the change under revision 
[r1759431|https://svn.apache.org/r1759431].
Keith, could you review that?

As a side from changes in  [r1759209|https://svn.apache.org/r1759209] I am 
wondering whether we can also change the following:
# dumpHeap operation is not marked as secure. It seems that dumped heap might 
contains sensitive data (for example, message headers). I think that dumpHeap 
should be annotated as secure operation.
# I am wondering whether port UI should be changed to allow changing 
allowConfidentialOperationsOnInsecureChannels? That could be useful for users 
already have some tooling around operations marked as being secure in 6.1 but 
might not be able to change their tooling on upgrade.


> [Java Broker] Managed Operations returning potentially confidential 
> information should not be permitted by default on insecure connections
> --
>
> Key: QPID-7380
> URL: https://issues.apache.org/jira/browse/QPID-7380
> Project: Qpid
>  Issue Type: Improvement
>Reporter: Rob Godfrey
>Assignee: Keith Wall
> Fix For: qpid-java-6.1
>
>
> Operations such as getting message content or extracting config or message 
> data may contain confidential information.  As such one would not normally 
> wish these operations to be permitted on insecure (non-TLS) connections.  We 
> should enhance the meta data for managed operations to allow for declaring 
> them "secure", we should then change the REST servlet to prevent the 
> operation of "secure" operations on insecure connections.  To allow those who 
> are aware of the risks, but accept them, we should add an attribute to the 
> (Http)Port to allow secure operations to be performed on that port even where 
> the connection is insecure.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7380) [Java Broker] Managed Operations returning potentially confidential information should not be permitted by default on insecure connections

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15467388#comment-15467388
 ] 

ASF subversion and git services commented on QPID-7380:
---

Commit 1759431 from oru...@apache.org in branch 'java/trunk'
[ https://svn.apache.org/r1759431 ]

QPID-7380: [Java Broker, WMC] Cache header inclusion flag on message viewing

> [Java Broker] Managed Operations returning potentially confidential 
> information should not be permitted by default on insecure connections
> --
>
> Key: QPID-7380
> URL: https://issues.apache.org/jira/browse/QPID-7380
> Project: Qpid
>  Issue Type: Improvement
>Reporter: Rob Godfrey
>Assignee: Keith Wall
> Fix For: qpid-java-6.1
>
>
> Operations such as getting message content or extracting config or message 
> data may contain confidential information.  As such one would not normally 
> wish these operations to be permitted on insecure (non-TLS) connections.  We 
> should enhance the meta data for managed operations to allow for declaring 
> them "secure", we should then change the REST servlet to prevent the 
> operation of "secure" operations on insecure connections.  To allow those who 
> are aware of the risks, but accept them, we should add an attribute to the 
> (Http)Port to allow secure operations to be performed on that port even where 
> the connection is insecure.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7415) [AMQP 1.0]: reject, release & modified ignored by qpid::messaging

[Gordon Sim (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15466851#comment-15466851
 ] 

Gordon Sim commented on QPID-7415:
--

https://reviews.apache.org/r/51638/

> [AMQP 1.0]: reject, release & modified ignored by qpid::messaging
> -
>
> Key: QPID-7415
> URL: https://issues.apache.org/jira/browse/QPID-7415
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Client
>Affects Versions: qpid-cpp-1.35.0
>Reporter: Gordon Sim
>Assignee: Gordon Sim
>
> At present the client only logs warnings as it has no good way to communicate 
> the status in the asynchronous model.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7408) REST API streams compressed message content without a Content-Encoding header

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15466792#comment-15466792
 ] 

ASF subversion and git services commented on QPID-7408:
---

Commit 1759379 from oru...@apache.org in branch 'java/trunk'
[ https://svn.apache.org/r1759379 ]

QPID-7408: [Java Broker] Prevent double compression and decompress compressed 
message content if compression is unsupported on REST client

> REST API streams compressed message content without a Content-Encoding header
> -
>
> Key: QPID-7408
> URL: https://issues.apache.org/jira/browse/QPID-7408
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.30, 0.32, qpid-java-6.0, qpid-java-6.1
>Reporter: Keith Wall
>Assignee: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-6.1
>
> Attachments: new-compression-tests.diff
>
>
> The Broker for Java supports compressed messages.  If I view a compressed 
> message through the management console, the Broker sends the content to the 
> client without a {{Content-Encoding}} header, so the client treats the bytes 
> as if they were uncompressed.  If the message's mime type is {{text/*}}, I 
> see seeming garbage instead of the inlined text content.  If the message's 
> mime type is something else the browser handles the content as if it were 
> uncompressed.  This could confused applications associated with the Browser.
> This could potentially hinder an operator.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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