[jira] [Updated] (PROTON-21) Extract the logical AMQP frame handling to an AbstractConnectionHandler

2012-10-16 Thread Rafael H. Schloming (JIRA)

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

Rafael H. Schloming updated PROTON-21:
--

Component/s: proton-j
 proton-c

 Extract the logical AMQP frame handling to an AbstractConnectionHandler
 ---

 Key: PROTON-21
 URL: https://issues.apache.org/jira/browse/PROTON-21
 Project: Qpid Proton
  Issue Type: Improvement
  Components: proton-c, proton-j
Reporter: Hiram Chirino
Assignee: Rob Godfrey
  Labels: api
 Attachments: PROTON-21-v3.patch


 Right now all the logic that handles logical AMQP frame events is inside of 
 the TransportImpl class.  That interface only allows you to pump bytes in and 
 out of the connection.  If we extract all the handling logic to an 
 AbstractConnectionHandler you should be able to use that directly and pump 
 logical AMQP frames and avoid the frame encoding/decoding phase that the 
 TransportImpl also does.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (PROTON-21) Extract the logical AMQP frame handling to an AbstractConnectionHandler

2012-10-16 Thread Rafael H. Schloming (JIRA)

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

Rafael H. Schloming updated PROTON-21:
--

Labels: api  (was: )

 Extract the logical AMQP frame handling to an AbstractConnectionHandler
 ---

 Key: PROTON-21
 URL: https://issues.apache.org/jira/browse/PROTON-21
 Project: Qpid Proton
  Issue Type: Improvement
  Components: proton-c, proton-j
Reporter: Hiram Chirino
Assignee: Rob Godfrey
  Labels: api
 Attachments: PROTON-21-v3.patch


 Right now all the logic that handles logical AMQP frame events is inside of 
 the TransportImpl class.  That interface only allows you to pump bytes in and 
 out of the connection.  If we extract all the handling logic to an 
 AbstractConnectionHandler you should be able to use that directly and pump 
 logical AMQP frames and avoid the frame encoding/decoding phase that the 
 TransportImpl also does.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (PROTON-22) Add optional module that provides HawtDispatch integration.

2012-10-16 Thread Rafael H. Schloming (JIRA)

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

Rafael H. Schloming updated PROTON-22:
--

Component/s: proton-j

 Add optional module that provides HawtDispatch integration.
 ---

 Key: PROTON-22
 URL: https://issues.apache.org/jira/browse/PROTON-22
 Project: Qpid Proton
  Issue Type: New Feature
  Components: proton-j
Reporter: Hiram Chirino
 Attachments: PROTON-22-v3.patch, PROTON-22-v4.patch


 HawtDispatch is a GCD style threading and IO handling framework.  Would be 
 nice if proton had nice integration /w it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (PROTON-25) Connection doesn't transistion to PN_REMOTE_CLOSED when socket is closed.

2012-10-16 Thread Rafael H. Schloming (JIRA)

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

Rafael H. Schloming updated PROTON-25:
--

Assignee: Ken Giusti

 Connection doesn't transistion to PN_REMOTE_CLOSED when socket is closed.
 -

 Key: PROTON-25
 URL: https://issues.apache.org/jira/browse/PROTON-25
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Reporter: Ted Ross
Assignee: Ken Giusti
Priority: Blocker

 After a connection has been established and opened both remotely and locally, 
 if that connection is closed uncleanly (i.e. the socket is closed without any 
 handshake), the connection object will not transition to PN_REMOTE_CLOSED.
 The closed connection is awakened and processed by the driver, but its state 
 is not changed.  Any state the application has associated with the 
 connection, its sessions, and its links will not be cleaned up.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (PROTON-33) Provide API for user managed pn_message_t payload/memory

2012-10-16 Thread Rafael H. Schloming (JIRA)

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

Rafael H. Schloming updated PROTON-33:
--

Labels: api  (was: )

 Provide API for user managed pn_message_t payload/memory
 

 Key: PROTON-33
 URL: https://issues.apache.org/jira/browse/PROTON-33
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Reporter: William Henry
  Labels: api

 Some users will have their own frameworks and methods of managing the data 
 received.
 Currently in the pn_message_t the only way to get at the payload/data is to 
 call pn_message_save with a pre-allocated buffer of data.  pn_message_save 
 copies to that data buffer and returns the actual size. (so for example if I 
 passed an allocated buffer of 1028 I might be returned 8 bytes).
 In many situations this alloc is expensive - especially when integrating with 
 established frameworks that already do the copy - now there are two allocs. 
 I suggest an API call that returns the message payload as a pointer.  There 
 is a risk that this might get deleted and a pn_message_t should check that 
 it's buffer is still valid (I assume it would.) In the case I'm looking at 
 the other framework is merely making it's own copy but doesn't free the 
 memory (but, as I said, there is a risk it could).
 I'm willing to debate pn_message_t having an API that returns a copy but I 
 imagine many users will any up complaining about the alloc in the that API 
 call.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (PROTON-39) Implement pn_offer for sender links

2012-10-16 Thread Rafael H. Schloming (JIRA)

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

Rafael H. Schloming updated PROTON-39:
--

Labels: api  (was: )

 Implement pn_offer for sender links
 ---

 Key: PROTON-39
 URL: https://issues.apache.org/jira/browse/PROTON-39
 Project: Qpid Proton
  Issue Type: New Feature
  Components: proton-c, proton-j
Reporter: Ted Ross
  Labels: api
 Attachments: proton-39.patch


 The proposed patch adds two functions to the engine API:
 void pn_offer(link, credit)
 bool pn_connection_links_writeable(conn)
 pn_offer is used by the attached node to indicate to the engine that it has 
 messages available for immediate transfer over the link.
 pn_connection_links_writable returns true if the connection has at least one 
 outgoing link with both receiver credit and offered credit.  This is used by 
 the driver to ensure that the connection's FD (or equivalent) is in the set 
 of writable FDs to be processed it the outgoing transport is writable.
 Note that pn_offer is absolute (not cumulative).  The attached node is 
 responsible for keeping the offer vaule up-to-date as messages are sent and 
 received.
 The patch does not make any changes to the protocol exchange.  Additional 
 work is needed to communicate the offer information to the remote receiver so 
 the receiver can intelligently manage its credits.
 The driving need for this change is for driver functionality.  pn_offer is 
 the cleanest mechanism for a node to tell the driver that an outbound link's 
 connection should be processed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (PROTON-40) Batching of message IDs in Disposition frames not supported

2012-10-16 Thread Rafael H. Schloming (JIRA)

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

Rafael H. Schloming updated PROTON-40:
--

Priority: Major  (was: Minor)

 Batching of message IDs in Disposition frames not supported
 ---

 Key: PROTON-40
 URL: https://issues.apache.org/jira/browse/PROTON-40
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Reporter: Ted Ross

 If a proton client calls pn_disposition on more than one received delivery 
 between the sending of disposition frames, the next disposition frame will 
 reference only the first message in the batch.
 Ref:  This code fragment from pn_post_disp which uses the same value for 
 first and last id:
 return pn_post_frame(transport-disp, ssn_state-local_channel, 
 DL[oIIo?DL[]], DISPOSITION,
  link-endpoint.type == RECEIVER, state-id, 
 state-id,
  delivery-local_settled,
  (bool)code, code);
 The result of this is that dispositions for messages are lost and senders 
 hang if there are credit windows of greater than one.  It would be ok, but 
 inefficient, to send multiple singleton dispositions.  In fact, proton simply 
 skips one or more disposition so the settlement of messages is incomplete.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (PROTON-40) Batching of message IDs in Disposition frames not supported

2012-10-16 Thread Rafael H. Schloming (JIRA)

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

Rafael H. Schloming updated PROTON-40:
--

Priority: Minor  (was: Major)

 Batching of message IDs in Disposition frames not supported
 ---

 Key: PROTON-40
 URL: https://issues.apache.org/jira/browse/PROTON-40
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Reporter: Ted Ross
Priority: Minor

 If a proton client calls pn_disposition on more than one received delivery 
 between the sending of disposition frames, the next disposition frame will 
 reference only the first message in the batch.
 Ref:  This code fragment from pn_post_disp which uses the same value for 
 first and last id:
 return pn_post_frame(transport-disp, ssn_state-local_channel, 
 DL[oIIo?DL[]], DISPOSITION,
  link-endpoint.type == RECEIVER, state-id, 
 state-id,
  delivery-local_settled,
  (bool)code, code);
 The result of this is that dispositions for messages are lost and senders 
 hang if there are credit windows of greater than one.  It would be ok, but 
 inefficient, to send multiple singleton dispositions.  In fact, proton simply 
 skips one or more disposition so the settlement of messages is incomplete.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (PROTON-40) Batching of message IDs in Disposition frames not supported

2012-10-16 Thread Rafael H. Schloming (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13477220#comment-13477220
 ] 

Rafael H. Schloming commented on PROTON-40:
---

We can add error detection for the case when a delivery is accessed after 
settle is called.

 Batching of message IDs in Disposition frames not supported
 ---

 Key: PROTON-40
 URL: https://issues.apache.org/jira/browse/PROTON-40
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Reporter: Ted Ross
Priority: Minor

 If a proton client calls pn_disposition on more than one received delivery 
 between the sending of disposition frames, the next disposition frame will 
 reference only the first message in the batch.
 Ref:  This code fragment from pn_post_disp which uses the same value for 
 first and last id:
 return pn_post_frame(transport-disp, ssn_state-local_channel, 
 DL[oIIo?DL[]], DISPOSITION,
  link-endpoint.type == RECEIVER, state-id, 
 state-id,
  delivery-local_settled,
  (bool)code, code);
 The result of this is that dispositions for messages are lost and senders 
 hang if there are credit windows of greater than one.  It would be ok, but 
 inefficient, to send multiple singleton dispositions.  In fact, proton simply 
 skips one or more disposition so the settlement of messages is incomplete.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (PROTON-43) Provides messenger send/receive examples in C

2012-10-16 Thread Rafael H. Schloming (JIRA)

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

Rafael H. Schloming updated PROTON-43:
--

Assignee: Rafael H. Schloming

 Provides messenger send/receive examples in C
 -

 Key: PROTON-43
 URL: https://issues.apache.org/jira/browse/PROTON-43
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Reporter: Darryl L. Pierce
Assignee: Rafael H. Schloming
Priority: Blocker
 Attachments: 0001-New-C-language-examples-for-send-and-receive.patch


 Provides a send.c, recv.c and CMake file to build them.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (PROTON-44) pn_message_t group_sequence doesn't set

2012-10-16 Thread Rafael H. Schloming (JIRA)

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

Rafael H. Schloming updated PROTON-44:
--

Assignee: Rafael H. Schloming

 pn_message_t group_sequence doesn't set
 ---

 Key: PROTON-44
 URL: https://issues.apache.org/jira/browse/PROTON-44
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Reporter: William Henry
Assignee: Rafael H. Schloming
Priority: Blocker

 I've tried setting group_sequence in a python example and it always returns 0.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (PROTON-46) No way to get at a message's subscription using pn_messenger_t and pn_message_t APIs

2012-10-16 Thread Rafael H. Schloming (JIRA)

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

Rafael H. Schloming updated PROTON-46:
--

Labels: api  (was: )

 No way to get at a message's subscription using pn_messenger_t and 
 pn_message_t APIs 
 -

 Key: PROTON-46
 URL: https://issues.apache.org/jira/browse/PROTON-46
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Reporter: William Henry
  Labels: api

 Motivation: 
 Integrate with another messaging API.  That other API may handle incoming 
 messages differently based on their notion of a subscription.  There is no 
 way to know which subscription a message came in on when using the messenger 
 API.
 It would be handier if I could just get something back form the API to help 
 me track/lookup.
 What would be nice is two API additions. 
 int pn_messenger_context_subscribe(pn_messenger_t *messenger, const char 
 *source, void* context);
 int pn_messenger_context_get(pn_messenger_t *messenger, pn_message_t *msg, 
 void* context);
 The get would return the context for that message based on the subscription.
 Alternatively what would be better is:
 int pn_messenger_subscribe(pn_messenger_t *messenger, const char *source,
 void* context);
 void *pn_message_subscribe_context(pn_message_t *msg);
 For C we can just leave it as NULL if we don't care about it and in the
 idiomatic APIs we can turn it into an optional argument.
 An incoming message would have it's subscription context stored with it when 
 it arrives.  No extra lookup required on the: void 
 *pn_message_subscribe_context(pn_message_t *msg);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (PROTON-47) Script to generate release tarballs

2012-10-16 Thread Rafael H. Schloming (JIRA)

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

Rafael H. Schloming updated PROTON-47:
--

Component/s: proton-j

 Script to generate release tarballs
 ---

 Key: PROTON-47
 URL: https://issues.apache.org/jira/browse/PROTON-47
 Project: Qpid Proton
  Issue Type: Improvement
  Components: proton-c, proton-j
Reporter: Darryl L. Pierce
 Attachments: 
 0001-Provides-a-script-for-generated-source-tarballs.patch


 The script takes as input a version, and option subversion repository and 
 branch. It then generates a tarball for use in packaging and distribution.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (PROTON-47) Script to generate release tarballs

2012-10-16 Thread Rafael H. Schloming (JIRA)

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

Rafael H. Schloming updated PROTON-47:
--

Priority: Blocker  (was: Major)

 Script to generate release tarballs
 ---

 Key: PROTON-47
 URL: https://issues.apache.org/jira/browse/PROTON-47
 Project: Qpid Proton
  Issue Type: Improvement
  Components: proton-c, proton-j
Reporter: Darryl L. Pierce
Priority: Blocker
 Attachments: 
 0001-Provides-a-script-for-generated-source-tarballs.patch


 The script takes as input a version, and option subversion repository and 
 branch. It then generates a tarball for use in packaging and distribution.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (PROTON-54) Installs README, TODO, user documentation and related files

2012-10-16 Thread Rafael H. Schloming (JIRA)

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

Rafael H. Schloming updated PROTON-54:
--

Priority: Blocker  (was: Major)

 Installs README, TODO, user documentation and related files
 ---

 Key: PROTON-54
 URL: https://issues.apache.org/jira/browse/PROTON-54
 Project: Qpid Proton
  Issue Type: Improvement
  Components: proton-c
Reporter: Darryl L. Pierce
Priority: Blocker
 Attachments: 
 0001-Installs-the-README-LICENSE-TODO-musings.txt-and-dev.patch


 Adds a new Cmake macro, PROTON_INSTALL_DATADIR, and installs the files 
 README, TODO, LICENSE, musings.txt as well as the developer documentation 
 into that directory.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (PROTON-58) NullPointerException on receiver.recv(...)

2012-10-16 Thread Rafael H. Schloming (JIRA)

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

Rafael H. Schloming updated PROTON-58:
--

Labels: api  (was: )

 NullPointerException on receiver.recv(...)
 --

 Key: PROTON-58
 URL: https://issues.apache.org/jira/browse/PROTON-58
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Hiram Chirino
  Labels: api

 Caused by: java.lang.NullPointerException
   at 
 org.apache.qpid.proton.engine.impl.ReceiverImpl.recv(ReceiverImpl.java:73)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (PROTON-59) Max frame size is not being respected.

2012-10-16 Thread Rafael H. Schloming (JIRA)

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

Rafael H. Schloming updated PROTON-59:
--

Priority: Blocker  (was: Major)

 Max frame size is not being respected.
 --

 Key: PROTON-59
 URL: https://issues.apache.org/jira/browse/PROTON-59
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Hiram Chirino
Priority: Blocker

 When a large message is sent to a switfmq client, the following error is 
 reported:
 com.swiftmq.amqp.v100.client.ConnectionClosedException: 
 amqp:connection:framing-error / Frame size (10332)  max frame size (4096)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (PROTON-60) Support configuring the max frame size.

2012-10-16 Thread Rafael H. Schloming (JIRA)

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

Rafael H. Schloming updated PROTON-60:
--

Labels: api  (was: )

 Support configuring the max frame size.
 ---

 Key: PROTON-60
 URL: https://issues.apache.org/jira/browse/PROTON-60
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c, proton-j
Reporter: Hiram Chirino
  Labels: api



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (PROTON-59) Max frame size is not being respected.

2012-10-16 Thread Rafael H. Schloming (JIRA)

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

Rafael H. Schloming updated PROTON-59:
--

Assignee: Rob Godfrey

 Max frame size is not being respected.
 --

 Key: PROTON-59
 URL: https://issues.apache.org/jira/browse/PROTON-59
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Hiram Chirino
Assignee: Rob Godfrey
Priority: Blocker

 When a large message is sent to a switfmq client, the following error is 
 reported:
 com.swiftmq.amqp.v100.client.ConnectionClosedException: 
 amqp:connection:framing-error / Frame size (10332)  max frame size (4096)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (PROTON-62) Proton(-j) does not support attaching to the transaction coordinator

2012-10-16 Thread Rafael H. Schloming (JIRA)

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

Rafael H. Schloming updated PROTON-62:
--

Component/s: proton-c

 Proton(-j) does not support attaching to the transaction coordinator
 

 Key: PROTON-62
 URL: https://issues.apache.org/jira/browse/PROTON-62
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c, proton-j
Reporter: Hiram Chirino
  Labels: api

 Got at:
 Caused by: java.lang.ClassCastException: 
 org.apache.qpid.proton.type.transaction.Coordinator cannot be cast to 
 org.apache.qpid.proton.type.messaging.Target
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.handleAttach(TransportImpl.java:977)
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.handleAttach(TransportImpl.java:59)
   at org.apache.qpid.proton.type.transport.Attach.invoke(Attach.java:389)
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.input(TransportImpl.java:1090)
   at 
 org.apache.qpid.proton.engine.impl.FrameParser.input(FrameParser.java:409)
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.input(TransportImpl.java:156)
   at 
 org.apache.activemq.transport.amqp.AmqpProtocolConverter.onAMQPData(AmqpProtocolConverter.java:120)
   ... 5 more
 and I think the frame being processed was the following (hex):
 00 00 00 6a 02 00 00 01 00 53 12 c0 5d 0a a1 11 74 78 6e 43 
 6f 6e 74 72 6f 6c 6c 65 72 4c 69 6e 6b 43 42 50 00 50 00 00 
 53 28 c0 01 00 00 53 30 c0 35 01 e0 32 02 a3 17 61 6d 71 70 
 3a 6c 6f 63 61 6c 2d 74 72 61 6e 73 61 63 74 69 6f 6e 73 17 
 61 6d 71 70 3a 6d 75 6c 74 69 2d 74 78 6e 73 2d 70 65 72 2d 
 73 73 6e 40 40 43 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (PROTON-62) Proton(-j) does not support attaching to the transaction coordinator

2012-10-16 Thread Rafael H. Schloming (JIRA)

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

Rafael H. Schloming updated PROTON-62:
--

Labels: api  (was: )

 Proton(-j) does not support attaching to the transaction coordinator
 

 Key: PROTON-62
 URL: https://issues.apache.org/jira/browse/PROTON-62
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c, proton-j
Reporter: Hiram Chirino
  Labels: api

 Got at:
 Caused by: java.lang.ClassCastException: 
 org.apache.qpid.proton.type.transaction.Coordinator cannot be cast to 
 org.apache.qpid.proton.type.messaging.Target
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.handleAttach(TransportImpl.java:977)
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.handleAttach(TransportImpl.java:59)
   at org.apache.qpid.proton.type.transport.Attach.invoke(Attach.java:389)
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.input(TransportImpl.java:1090)
   at 
 org.apache.qpid.proton.engine.impl.FrameParser.input(FrameParser.java:409)
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.input(TransportImpl.java:156)
   at 
 org.apache.activemq.transport.amqp.AmqpProtocolConverter.onAMQPData(AmqpProtocolConverter.java:120)
   ... 5 more
 and I think the frame being processed was the following (hex):
 00 00 00 6a 02 00 00 01 00 53 12 c0 5d 0a a1 11 74 78 6e 43 
 6f 6e 74 72 6f 6c 6c 65 72 4c 69 6e 6b 43 42 50 00 50 00 00 
 53 28 c0 01 00 00 53 30 c0 35 01 e0 32 02 a3 17 61 6d 71 70 
 3a 6c 6f 63 61 6c 2d 74 72 61 6e 73 61 63 74 69 6f 6e 73 17 
 61 6d 71 70 3a 6d 75 6c 74 69 2d 74 78 6e 73 2d 70 65 72 2d 
 73 73 6e 40 40 43 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (PROTON-62) Proton(-j) does not support attaching to the transaction coordinator

2012-10-16 Thread Rafael H. Schloming (JIRA)

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

Rafael H. Schloming updated PROTON-62:
--

Assignee: Rafael H. Schloming

 Proton(-j) does not support attaching to the transaction coordinator
 

 Key: PROTON-62
 URL: https://issues.apache.org/jira/browse/PROTON-62
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c, proton-j
Reporter: Hiram Chirino
Assignee: Rafael H. Schloming
  Labels: api

 Got at:
 Caused by: java.lang.ClassCastException: 
 org.apache.qpid.proton.type.transaction.Coordinator cannot be cast to 
 org.apache.qpid.proton.type.messaging.Target
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.handleAttach(TransportImpl.java:977)
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.handleAttach(TransportImpl.java:59)
   at org.apache.qpid.proton.type.transport.Attach.invoke(Attach.java:389)
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.input(TransportImpl.java:1090)
   at 
 org.apache.qpid.proton.engine.impl.FrameParser.input(FrameParser.java:409)
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.input(TransportImpl.java:156)
   at 
 org.apache.activemq.transport.amqp.AmqpProtocolConverter.onAMQPData(AmqpProtocolConverter.java:120)
   ... 5 more
 and I think the frame being processed was the following (hex):
 00 00 00 6a 02 00 00 01 00 53 12 c0 5d 0a a1 11 74 78 6e 43 
 6f 6e 74 72 6f 6c 6c 65 72 4c 69 6e 6b 43 42 50 00 50 00 00 
 53 28 c0 01 00 00 53 30 c0 35 01 e0 32 02 a3 17 61 6d 71 70 
 3a 6c 6f 63 61 6c 2d 74 72 61 6e 73 61 63 74 69 6f 6e 73 17 
 61 6d 71 70 3a 6d 75 6c 74 69 2d 74 78 6e 73 2d 70 65 72 2d 
 73 73 6e 40 40 43 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (PROTON-74) Fix the mailbox example.

2012-10-16 Thread Rafael H. Schloming (JIRA)

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

Rafael H. Schloming updated PROTON-74:
--

Priority: Blocker  (was: Minor)

 Fix the mailbox example.
 

 Key: PROTON-74
 URL: https://issues.apache.org/jira/browse/PROTON-74
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Reporter: Ken Giusti
Assignee: Ken Giusti
Priority: Blocker

 Doesn't work - needs to be brought up to date with current engine API.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (PROTON-74) Fix the mailbox example.

2012-10-16 Thread Rafael H. Schloming (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13477256#comment-13477256
 ] 

Rafael H. Schloming commented on PROTON-74:
---

Let's convert it to messenger.

 Fix the mailbox example.
 

 Key: PROTON-74
 URL: https://issues.apache.org/jira/browse/PROTON-74
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Reporter: Ken Giusti
Assignee: Ken Giusti
Priority: Blocker

 Doesn't work - needs to be brought up to date with current engine API.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (PROTON-75) Implement support for more delivery states

2012-10-16 Thread Rafael H. Schloming (JIRA)

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

Rafael H. Schloming updated PROTON-75:
--

Labels: api  (was: )

 Implement support for more delivery states
 --

 Key: PROTON-75
 URL: https://issues.apache.org/jira/browse/PROTON-75
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c, proton-j
Reporter: Hiram Chirino
  Labels: api
 Attachments: PROTON-75.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (PROTON-75) Implement support for more delivery states

2012-10-16 Thread Rafael H. Schloming (JIRA)

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

Rafael H. Schloming updated PROTON-75:
--

Assignee: Rob Godfrey

 Implement support for more delivery states
 --

 Key: PROTON-75
 URL: https://issues.apache.org/jira/browse/PROTON-75
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c, proton-j
Reporter: Hiram Chirino
Assignee: Rob Godfrey
  Labels: api
 Attachments: PROTON-75.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (PROTON-76) Suspiciously insufficient looking buffer allocation in messenger.c

2012-10-16 Thread Rafael H. Schloming (JIRA)

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

Rafael H. Schloming updated PROTON-76:
--

Priority: Blocker  (was: Major)

 Suspiciously insufficient looking buffer allocation in messenger.c
 --

 Key: PROTON-76
 URL: https://issues.apache.org/jira/browse/PROTON-76
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Reporter: Rob Godfrey
Priority: Blocker

 Lines 541-549:
   if (len  1  address[0] == '~'  address[1] == '/') {
 char buf[len + strlen(mng-name) + 4];
 sprintf(buf, amqp://%s/%s, mng-name, address);
 pn_message_set_reply_to(msg, buf);
   } else if (len == 0) {
 char buf[strlen(mng-name) + 4];
 sprintf(buf, amqp://%s, mng-name);
 pn_message_set_reply_to(msg, buf);
   }
 should the first 4 not be an 8 and the second a 7?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (PROTON-76) Suspiciously insufficient looking buffer allocation in messenger.c

2012-10-16 Thread Rafael H. Schloming (JIRA)

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

Rafael H. Schloming updated PROTON-76:
--

Assignee: Rafael H. Schloming

 Suspiciously insufficient looking buffer allocation in messenger.c
 --

 Key: PROTON-76
 URL: https://issues.apache.org/jira/browse/PROTON-76
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Reporter: Rob Godfrey
Assignee: Rafael H. Schloming
Priority: Blocker

 Lines 541-549:
   if (len  1  address[0] == '~'  address[1] == '/') {
 char buf[len + strlen(mng-name) + 4];
 sprintf(buf, amqp://%s/%s, mng-name, address);
 pn_message_set_reply_to(msg, buf);
   } else if (len == 0) {
 char buf[strlen(mng-name) + 4];
 sprintf(buf, amqp://%s, mng-name);
 pn_message_set_reply_to(msg, buf);
   }
 should the first 4 not be an 8 and the second a 7?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (PROTON-77) pn_transport_input api should declare the bytes parameter as constant.

2012-10-16 Thread Rafael H. Schloming (JIRA)

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

Rafael H. Schloming updated PROTON-77:
--

Priority: Blocker  (was: Trivial)

 pn_transport_input api should declare the bytes parameter as constant.
 --

 Key: PROTON-77
 URL: https://issues.apache.org/jira/browse/PROTON-77
 Project: Qpid Proton
  Issue Type: Improvement
  Components: proton-c
Reporter: Ken Giusti
Assignee: Rafael H. Schloming
Priority: Blocker

 The method should not modify the caller's data buffer.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (PROTON-77) pn_transport_input api should declare the bytes parameter as constant.

2012-10-16 Thread Ken Giusti (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13477540#comment-13477540
 ] 

Ken Giusti commented on PROTON-77:
--

Pushed the const-ness of the argument as far down the call chain as I could.  
I got as far as the codec.c, where the changes started to get complex - that's 
where I punted and used the cast ala Rafi's comment.

 pn_transport_input api should declare the bytes parameter as constant.
 --

 Key: PROTON-77
 URL: https://issues.apache.org/jira/browse/PROTON-77
 Project: Qpid Proton
  Issue Type: Improvement
  Components: proton-c
Reporter: Ken Giusti
Assignee: Ken Giusti
Priority: Blocker

 The method should not modify the caller's data buffer.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Created] (PROTON-80) Codec should respect the const-ness of the input buffer.

2012-10-16 Thread Ken Giusti (JIRA)
Ken Giusti created PROTON-80:


 Summary: Codec should respect the const-ness of the input buffer.
 Key: PROTON-80
 URL: https://issues.apache.org/jira/browse/PROTON-80
 Project: Qpid Proton
  Issue Type: Improvement
  Components: proton-c
Reporter: Ken Giusti
Assignee: Ken Giusti
Priority: Blocker


The method should not modify the caller's data buffer.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira