[jira] [Created] (PROTON-443) update hawt-dispatch dependency version
Robbie Gemmell created PROTON-443:
-
Summary: update hawt-dispatch dependency version
Key: PROTON-443
URL: https://issues.apache.org/jira/browse/PROTON-443
Project: Qpid Proton
Issue Type: Improvement
Components: proton-j
Reporter: Robbie Gemmell
Priority: Blocker
Fix For: 0.6
PROTON-440 made some seemingly unrelated change to the proton-hawtdispatch
module dependencies, as below.
The snapshot now being used must be updated to a release version before Proton
0.6 can be shipped.
{noformat}
--- qpid/proton/trunk/proton-j/contrib/proton-hawtdispatch/pom.xml
2013/10/12 07:06:05 1531507
+++ qpid/proton/trunk/proton-j/contrib/proton-hawtdispatch/pom.xml
2013/10/12 07:06:45 1531508
@@ -29,7 +29,7 @@
properties
hawtbuf-version1.9/hawtbuf-version
-hawtdispatch-version1.12/hawtdispatch-version
+hawtdispatch-version1.18-SNAPSHOT/hawtdispatch-version
/properties
dependencies
@@ -51,6 +51,15 @@
scopeprovided/scope
/dependency
/dependencies
+
+ repositories
+repository
+ idcom.fusesource.m2.snapshot/id
+
urlhttp://repo.fusesource.com/nexus/content/repositories/snapshots//url
+ releasesenabledfalse/enabled/releases
+ snapshotsenabledtrue/enabled/snapshots
+/repository
+ /repositories
build
/build
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (PROTON-443) update hawt-dispatch dependency version
[
https://issues.apache.org/jira/browse/PROTON-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael H. Schloming resolved PROTON-443.
Resolution: Fixed
Assignee: Rafael H. Schloming
update hawt-dispatch dependency version
---
Key: PROTON-443
URL: https://issues.apache.org/jira/browse/PROTON-443
Project: Qpid Proton
Issue Type: Improvement
Components: proton-j
Reporter: Robbie Gemmell
Assignee: Rafael H. Schloming
Priority: Blocker
Fix For: 0.6
PROTON-440 made some seemingly unrelated change to the proton-hawtdispatch
module dependencies, as below.
The snapshot now being used must be updated to a release version before
Proton 0.6 can be shipped.
{noformat}
--- qpid/proton/trunk/proton-j/contrib/proton-hawtdispatch/pom.xml
2013/10/12 07:06:05 1531507
+++ qpid/proton/trunk/proton-j/contrib/proton-hawtdispatch/pom.xml
2013/10/12 07:06:45 1531508
@@ -29,7 +29,7 @@
properties
hawtbuf-version1.9/hawtbuf-version
-hawtdispatch-version1.12/hawtdispatch-version
+hawtdispatch-version1.18-SNAPSHOT/hawtdispatch-version
/properties
dependencies
@@ -51,6 +51,15 @@
scopeprovided/scope
/dependency
/dependencies
+
+ repositories
+repository
+ idcom.fusesource.m2.snapshot/id
+
urlhttp://repo.fusesource.com/nexus/content/repositories/snapshots//url
+ releasesenabledfalse/enabled/releases
+ snapshotsenabledtrue/enabled/snapshots
+/repository
+ /repositories
build
/build
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (PROTON-432) seg fault when handling error
[
https://issues.apache.org/jira/browse/PROTON-432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13800603#comment-13800603
]
ASF subversion and git services commented on PROTON-432:
Commit 1534130 from r...@apache.org in branch 'proton/trunk'
[ https://svn.apache.org/r1534130 ]
PROTON-432: switched pn_condition_t to use pn_string_t, this fixes the seg fault
seg fault when handling error
-
Key: PROTON-432
URL: https://issues.apache.org/jira/browse/PROTON-432
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.5
Reporter: Gordon Sim
Assignee: Rafael H. Schloming
Priority: Blocker
Fix For: 0.6
{noformat}
$ ./proton-c/examples/messenger/c/send -a
amqp://gordon:gordon@localhost/my-queue
Connected to localhost:5672
- SASL
[0x18b8320:0] - @sasl-init(65) [mechanism=:PLAIN,
initial-response=b\x00gordon\x00gordon]
- SASL
[0x18b8320:0] - @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN, :AMQPLAIN]]
[0x18b8320:0] - @sasl-outcome(68) [code=0]
- AMQP
[0x18b08d0:0] - @open(16)
[container-id=8133b412-5ca8-4359-be9f-e236b87d3528, hostname=localhost]
[0x18b08d0:0] - @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=1]
[0x18b08d0:0] - @attach(18) [name=sender-xxx, handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=my-queue,
durable=0, timeout=0, dynamic=false], target=@target(41) [address=my-queue,
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
- AMQP
[0x18b08d0:0] - @open(16) [container-id=rabbit@GRS-T520,
idle-time-out=60, properties={:copyright=Copyright (C) 2007-2013 VMware,
Inc., :information=Licensed under the MPL. See http://www.rabbitmq.com/;,
:platform=Erlang/OTP, :product=RabbitMQ, :version=3.1.3}]
[0x18b08d0:0] - @open(16) [container-id=rabbit@GRS-T520,
idle-time-out=60, properties={:copyright=Copyright (C) 2007-2013 VMware,
Inc., :information=Licensed under the MPL. See http://www.rabbitmq.com/;,
:platform=Erlang/OTP, :product=RabbitMQ, :version=3.1.3}]
Segmentation fault (core dumped)
{noformat}
#0 0x7f799b10c0e0 in pn_data_rewind () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#1 0x7f799b11555f in pn_do_close () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#2 0x7f799b111554 in pn_dispatch_frame () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#3 0x7f799b1116e7 in pn_dispatcher_input () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#4 0x7f799b1169ee in pn_input_read_amqp () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#5 0x7f799b114855 in transport_consume () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#6 0x7f799b1185e2 in pn_transport_process () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#7 0x7f799b1204fb in pn_connector_process () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#8 0x7f799b11e420 in pn_messenger_tsync () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#9 0x004010f3 in main ()
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (PROTON-323) Regression: Messenger sends null in disposition state after accept
[ https://issues.apache.org/jira/browse/PROTON-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-323. Resolution: Not A Problem The 0.5 behaviour is actually correct. The reason the disposition is null is because the incoming window is zero and so the delivery is settled as soon as get is called. The accept() in this code snippet is actually a noop because the message has already fallen off the zero sized window. If you add the line mng.incoming_window = 1 to the code snippet, then it behaves similarly to 0.4, e.g.: [0x251fe20:0] - @disposition(21) [role=true, first=0, last=0, settled=false, state=@accepted(36) []] Note the state=@accepted(36) above. Regression: Messenger sends null in disposition state after accept Key: PROTON-323 URL: https://issues.apache.org/jira/browse/PROTON-323 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Ted Ross Assignee: Rafael H. Schloming Priority: Blocker Fix For: 0.6 Using the following Python code snippet: from proton import * mng = Messenger() mng.start() mng.subscribe(amqp://0.0.0.0/Queue_1) mng.timeout=100 mng.recv() msg = Message() t = mng.get(msg) mng.accept(t) mng.stop() The following trace is seen after the call to stop: [0xf7f6a0:1] - DISPOSITION @21 [true, 0, 0, true, null] On Proton 0.4, this problem does not exist. The trace is: [0x1087bb0:1] - DISPOSITION @21 [true, 0, 0, true, @36 []] -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (PROTON-278) Messenger - allow the application to control the use of the message reply-to field.
[ https://issues.apache.org/jira/browse/PROTON-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13800737#comment-13800737 ] ASF subversion and git services commented on PROTON-278: Commit 1534224 from r...@apache.org in branch 'proton/trunk' [ https://svn.apache.org/r1534224 ] PROTON-278: fixed reply-to expansion to not expand unset reply-to addresses Messenger - allow the application to control the use of the message reply-to field. --- Key: PROTON-278 URL: https://issues.apache.org/jira/browse/PROTON-278 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4 Reporter: Ken Giusti Assignee: Rafael H. Schloming Priority: Critical Labels: reply-to Fix For: 0.6 Currently, messenger always sets the reply-to field in a sent message. This should be changed to allow the application to set the reply-to field only when a reply is desired. Messenger should be changed to not unconditionally set this field. In order to set this field in the case of a client that has not established a subscription, the client needs to be able to query messenger for the proper value of the reply-to address. A new api would need to be created for this. Proposal: int pn_messenger_set_reply( pn_messenger_t *msgr, pn_message_t *msg ) Set the proper reply-to address in msg. msg would need to have its to address configured in order for this method to succeed. At least, I think the value for the reply-to may depend on the 'to' address... I may be wrong about that Opinions? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (PROTON-442) Running swig generates Warning(451): Setting a const char * variable may leak memory.
[ https://issues.apache.org/jira/browse/PROTON-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13800823#comment-13800823 ] ASF subversion and git services commented on PROTON-442: Commit 1534282 from [~fadams] in branch 'proton/trunk' [ https://svn.apache.org/r1534282 ] JIRA: PROTON-442 PROTON-442: When building proton I get Warning Setting a const char * variable may leak memory. should really strive for a clean build. Running swig generates Warning(451): Setting a const char * variable may leak memory. --- Key: PROTON-442 URL: https://issues.apache.org/jira/browse/PROTON-442 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.5 Reporter: Fraser Adams Priority: Minor When building proton after doing cmake .. the make process is quite noisy generating a number of warnings that ought to be corrected. One such warning is: Warning(451): Setting a const char * variable may leak memory. This relates to the const char *bytes; in the pn_delivery_tag_t struct in engine.h The swig documentation in http://www.swig.org/Doc1.3/Warnings.html suggests how to suppress this warning (due to the way the code works I believe that it's safe to suppress this case) by doing: %warnfilter(451) pn_delivery_tag_t; in the various python.i, perl.i etc. I've make the changes locally and this indeed works. I'll put together a review board request. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (PROTON-442) Running swig generates Warning(451): Setting a const char * variable may leak memory.
[ https://issues.apache.org/jira/browse/PROTON-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13800822#comment-13800822 ] ASF subversion and git services commented on PROTON-442: Commit 1534282 from [~fadams] in branch 'proton/trunk' [ https://svn.apache.org/r1534282 ] JIRA: PROTON-442 PROTON-442: When building proton I get Warning Setting a const char * variable may leak memory. should really strive for a clean build. Running swig generates Warning(451): Setting a const char * variable may leak memory. --- Key: PROTON-442 URL: https://issues.apache.org/jira/browse/PROTON-442 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.5 Reporter: Fraser Adams Priority: Minor When building proton after doing cmake .. the make process is quite noisy generating a number of warnings that ought to be corrected. One such warning is: Warning(451): Setting a const char * variable may leak memory. This relates to the const char *bytes; in the pn_delivery_tag_t struct in engine.h The swig documentation in http://www.swig.org/Doc1.3/Warnings.html suggests how to suppress this warning (due to the way the code works I believe that it's safe to suppress this case) by doing: %warnfilter(451) pn_delivery_tag_t; in the various python.i, perl.i etc. I've make the changes locally and this indeed works. I'll put together a review board request. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (PROTON-442) Running swig generates Warning(451): Setting a const char * variable may leak memory.
[ https://issues.apache.org/jira/browse/PROTON-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fraser Adams resolved PROTON-442. - Resolution: Fixed Running swig generates Warning(451): Setting a const char * variable may leak memory. --- Key: PROTON-442 URL: https://issues.apache.org/jira/browse/PROTON-442 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.5 Reporter: Fraser Adams Priority: Minor When building proton after doing cmake .. the make process is quite noisy generating a number of warnings that ought to be corrected. One such warning is: Warning(451): Setting a const char * variable may leak memory. This relates to the const char *bytes; in the pn_delivery_tag_t struct in engine.h The swig documentation in http://www.swig.org/Doc1.3/Warnings.html suggests how to suppress this warning (due to the way the code works I believe that it's safe to suppress this case) by doing: %warnfilter(451) pn_delivery_tag_t; in the various python.i, perl.i etc. I've make the changes locally and this indeed works. I'll put together a review board request. -- This message was sent by Atlassian JIRA (v6.1#6144)
