[jira] [Commented] (QPID-6662) Use direct byte buffers

2015-09-04 Thread ASF subversion and git services (JIRA) 

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

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

Commit 1701238 from [~k-wall] in branch 'java/trunk'
[ https://svn.apache.org/r1701238 ]

QPID-6662: Ensure that 0-10 ServerDisassembler does not assume bytes in buffers 
are already zero when forming frames.

* Added QpidByteBufferTest.

> Use direct byte buffers
> ---
>
> Key: QPID-6662
> URL: https://issues.apache.org/jira/browse/QPID-6662
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.0
>
>
> To improve performance of the Broker, direct ByteBuffers should be passed 
> from the transport directly to the store, minimising copying whenever 
> possible, and vice versa. 



--
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] (QPIDJMS-106) apply the validatePropertyNames option for messages to be sent in addition to those received

2015-09-04 Thread Robbie Gemmell (JIRA) 

[ 
https://issues.apache.org/jira/browse/QPIDJMS-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14730547#comment-14730547
 ] 

Robbie Gemmell commented on QPIDJMS-106:


I have responded off-list via moderating the dev@ list copy of this 
mail-in-jira comment.

> apply the validatePropertyNames option for messages to be sent in addition to 
> those received
> 
>
> Key: QPIDJMS-106
> URL: https://issues.apache.org/jira/browse/QPIDJMS-106
> Project: Qpid JMS
>  Issue Type: Improvement
>  Components: qpid-jms-client
>Affects Versions: 0.4.0, 0.5.0
>Reporter: Jakub Scholz
>Assignee: Robbie Gemmell
> Fix For: 0.6.0
>
> Attachments: QPIDJMS-106.patch
>
>
> The JIRA QPIDJMS-48 added a new connection option jms.validatePropertyNames 
> which can be used to override the validation of property names against the 
> JMS spec. Switching off the validation allows for example to read message 
> properties which contain period in their names.
> Right now this option seems to be taken into account only for received 
> messages. It would be great if the the option is taken into account also for 
> messages which are created and sent by the client. That would allow to send 
> messages containing period in property names.



--
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] (DISPATCH-161) Move all annotation related functions into annotation.h with corresponding implementation in annotation.c

2015-09-04 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/DISPATCH-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14731010#comment-14731010
 ] 

ASF subversion and git services commented on DISPATCH-161:
--

Commit d882a66fd8b0c668407d9cc0929bbf973969484d in qpid-dispatch's branch 
refs/heads/master from [~ganeshmurthy]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=d882a66 ]

Fix for DISPATCH-161 (https://issues.apache.org/jira/browse/DISPATCH-161). 
Added new router property called stripAnnotations with possible values as [in, 
out, both, no]. Based on what is set in this property, the router will 
strip/preserve router specific message annotations'


> Move all annotation related functions into annotation.h with corresponding 
> implementation in annotation.c
> -
>
> Key: DISPATCH-161
> URL: https://issues.apache.org/jira/browse/DISPATCH-161
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Routing Engine
>Affects Versions: 0.4
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Trivial
>
> Qpid dispatch file src/message.c and other files contain a bunch of message 
> and delivery annotation related functions. Move the functions into its own 
> unit in annotation.c and corresponding header file annotation.h



--
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] (DISPATCH-148) Strip qpid-dispatch-specific message annotations on ingress/egress

2015-09-04 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/DISPATCH-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14731014#comment-14731014
 ] 

ASF GitHub Bot commented on DISPATCH-148:
-

Github user asfgit closed the pull request at:

https://github.com/apache/qpid-dispatch/pull/6


> Strip qpid-dispatch-specific message annotations on ingress/egress
> --
>
> Key: DISPATCH-148
> URL: https://issues.apache.org/jira/browse/DISPATCH-148
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Router Node
>Reporter: Ted Ross
>Assignee: Ganesh Murthy
> Fix For: 0.6
>
>
> Messages that ingress from endpoints outside of the router should have any 
> x-opt-qd headers removed from the message annotations.
> Occasionally developers will re-use received messages for transmit and not 
> clear the annotations.  This can result in mysterious dropping of messages 
> due to anti-looping (i.e. the x-opt-qd-trace header shows the message passing 
> through the router already and the message is dropped).



--
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] (DISPATCH-161) Move all annotation related functions into annotation.h with corresponding implementation in annotation.c

2015-09-04 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/DISPATCH-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14731012#comment-14731012
 ] 

ASF subversion and git services commented on DISPATCH-161:
--

Commit 4acb7522a12f1635df707e81c236fac11e8c8025 in qpid-dispatch's branch 
refs/heads/master from [~ganeshmurthy]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=4acb752 ]

Additional fix for DISPATCH-161 
(https://issues.apache.org/jira/browse/DISPATCH-161). Added new router property 
called stripAnnotations with possible values as [in, out, both, no]. Based on 
what is set in this property, the router will strip/preserve router specific 
message annotations


> Move all annotation related functions into annotation.h with corresponding 
> implementation in annotation.c
> -
>
> Key: DISPATCH-161
> URL: https://issues.apache.org/jira/browse/DISPATCH-161
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Routing Engine
>Affects Versions: 0.4
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Trivial
>
> Qpid dispatch file src/message.c and other files contain a bunch of message 
> and delivery annotation related functions. Move the functions into its own 
> unit in annotation.c and corresponding header file annotation.h



--
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] (DISPATCH-161) Move all annotation related functions into annotation.h with corresponding implementation in annotation.c

2015-09-04 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/DISPATCH-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14731009#comment-14731009
 ] 

ASF subversion and git services commented on DISPATCH-161:
--

Commit d882a66fd8b0c668407d9cc0929bbf973969484d in qpid-dispatch's branch 
refs/heads/master from [~ganeshmurthy]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=d882a66 ]

Fix for DISPATCH-161 (https://issues.apache.org/jira/browse/DISPATCH-161). 
Added new router property called stripAnnotations with possible values as [in, 
out, both, no]. Based on what is set in this property, the router will 
strip/preserve router specific message annotations'


> Move all annotation related functions into annotation.h with corresponding 
> implementation in annotation.c
> -
>
> Key: DISPATCH-161
> URL: https://issues.apache.org/jira/browse/DISPATCH-161
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Routing Engine
>Affects Versions: 0.4
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Trivial
>
> Qpid dispatch file src/message.c and other files contain a bunch of message 
> and delivery annotation related functions. Move the functions into its own 
> unit in annotation.c and corresponding header file annotation.h



--
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] (DISPATCH-161) Move all annotation related functions into annotation.h with corresponding implementation in annotation.c

2015-09-04 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/DISPATCH-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14731011#comment-14731011
 ] 

ASF subversion and git services commented on DISPATCH-161:
--

Commit 4acb7522a12f1635df707e81c236fac11e8c8025 in qpid-dispatch's branch 
refs/heads/master from [~ganeshmurthy]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=4acb752 ]

Additional fix for DISPATCH-161 
(https://issues.apache.org/jira/browse/DISPATCH-161). Added new router property 
called stripAnnotations with possible values as [in, out, both, no]. Based on 
what is set in this property, the router will strip/preserve router specific 
message annotations


> Move all annotation related functions into annotation.h with corresponding 
> implementation in annotation.c
> -
>
> Key: DISPATCH-161
> URL: https://issues.apache.org/jira/browse/DISPATCH-161
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Routing Engine
>Affects Versions: 0.4
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Trivial
>
> Qpid dispatch file src/message.c and other files contain a bunch of message 
> and delivery annotation related functions. Move the functions into its own 
> unit in annotation.c and corresponding header file annotation.h



--
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] (DISPATCH-148) Strip qpid-dispatch-specific message annotations on ingress/egress

2015-09-04 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/DISPATCH-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14731013#comment-14731013
 ] 

ASF subversion and git services commented on DISPATCH-148:
--

Commit 4d22cb876964558ffa9e48dac780940da2fb6c4e in qpid-dispatch's branch 
refs/heads/master from [~tr...@redhat.com]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=4d22cb8 ]

DISPATCH-148 - Strip qpid-dispatch-specific message annotations on 
ingress/egress
Applied patch from Ganesh Murthy


> Strip qpid-dispatch-specific message annotations on ingress/egress
> --
>
> Key: DISPATCH-148
> URL: https://issues.apache.org/jira/browse/DISPATCH-148
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Router Node
>Reporter: Ted Ross
>Assignee: Ganesh Murthy
> Fix For: 0.6
>
>
> Messages that ingress from endpoints outside of the router should have any 
> x-opt-qd headers removed from the message annotations.
> Occasionally developers will re-use received messages for transmit and not 
> clear the annotations.  This can result in mysterious dropping of messages 
> due to anti-looping (i.e. the x-opt-qd-trace header shows the message passing 
> through the router already and the message is dropped).



--
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

[GitHub] qpid-dispatch pull request: Fix for DISPATCH-148.

2015-09-04 Thread asfgit 
Github user asfgit closed the pull request at:

https://github.com/apache/qpid-dispatch/pull/6


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Commented] (QPID-6727) Remove sendBufferSize/receiveBufferSize from AmqpPort and make max framesize/sendBufferSize/receiveBufferSize share a single source

2015-09-04 Thread ASF subversion and git services (JIRA) 

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

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

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

QPID-6727: Introduce context variable for network buffer size, use it to set 
max frame size, send and receive buffer sizes and remove port attributes for 
send and receive buffers sizes

   (work by Lorenz Quack  and Alex Rudyy 
)

> Remove sendBufferSize/receiveBufferSize from AmqpPort and make max 
> framesize/sendBufferSize/receiveBufferSize share a single source
> ---
>
> Key: QPID-6727
> URL: https://issues.apache.org/jira/browse/QPID-6727
> Project: Qpid
>  Issue Type: Improvement
>Reporter: Lorenz Quack
>
> Currently the TCP/IP buffer sizes (sendBufferSize/receiveBufferSize) are 
> attributes of AmpqPort.  For the new memory model, supporting different ports 
> using different receive buffers would be problematic and cause inefficient 
> use of direct memory.  Similarly clients using framesizes where the framesize 
> !=buffer size will be inefficient.
> # Remove sendBufferSize/receiveBufferSize from the Port.
> # Make max frame size and sendBufferSize/receiveBufferSize share a single 
> source which should be a context variable belonging to the Broker. Minimum 
> size must be no smaller than SSL netbuffer size
> # The context variable should be evaluated only once at Broker startup.
> # Upgraders should remove the attribute from AmqpPorts



--
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] (DISPATCH-163) Add username and password for authentication of connectors

2015-09-04 Thread Ted Ross (JIRA) 
Ted Ross created DISPATCH-163:
-

 Summary: Add username and password for authentication of connectors
 Key: DISPATCH-163
 URL: https://issues.apache.org/jira/browse/DISPATCH-163
 Project: Qpid Dispatch
  Issue Type: New Feature
  Components: Container
Reporter: Ted Ross
 Fix For: 0.6


Currently, connectors cannot use PLAIN authentication because there is no 
configuration for username and password.  This needs to be added.



--
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-6723) [Java Broker] Stop caching AMQShortStrings

2015-09-04 Thread Keith Wall (JIRA) 

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

Keith Wall closed QPID-6723.

Resolution: Fixed

> [Java Broker] Stop caching AMQShortStrings
> --
>
> Key: QPID-6723
> URL: https://issues.apache.org/jira/browse/QPID-6723
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.24, 0.26, 0.28, 0.30, 0.32
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
> Fix For: qpid-java-6.0
>
>
> Cached AMQShortStrings might fill the entire memory heap and cause OOM



--
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] (DISPATCH-148) Strip qpid-dispatch-specific message annotations on ingress/egress

2015-09-04 Thread Ted Ross (JIRA) 

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

Ted Ross resolved DISPATCH-148.
---
Resolution: Fixed

> Strip qpid-dispatch-specific message annotations on ingress/egress
> --
>
> Key: DISPATCH-148
> URL: https://issues.apache.org/jira/browse/DISPATCH-148
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Router Node
>Reporter: Ted Ross
>Assignee: Ganesh Murthy
> Fix For: 0.6
>
>
> Messages that ingress from endpoints outside of the router should have any 
> x-opt-qd headers removed from the message annotations.
> Occasionally developers will re-use received messages for transmit and not 
> clear the annotations.  This can result in mysterious dropping of messages 
> due to anti-looping (i.e. the x-opt-qd-trace header shows the message passing 
> through the router already and the message is dropped).



--
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] (DISPATCH-159) Enhance the address prefix used for link routing to support different patterns

2015-09-04 Thread Ted Ross (JIRA) 

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

Ted Ross reassigned DISPATCH-159:
-

Assignee: Ganesh Murthy

> Enhance the address prefix used for link routing to support different patterns
> --
>
> Key: DISPATCH-159
> URL: https://issues.apache.org/jira/browse/DISPATCH-159
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Affects Versions: 0.4
>Reporter: Jakub Scholz
>Assignee: Ganesh Murthy
> Fix For: 0.6
>
>
> The address used for link routing (in linkRoutePattern element) is currently 
> allowed to have only the form of a text without periods (.) followed by a 
> single period. That's quite a limitation in some situations. 
> The link routing should be enhanced to support different prefixes with 
> multiple periods or without any periods at all. That would give the link 
> routing mode lot more flexibility.



--
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

[GitHub] qpid-dispatch pull request: NO-JIRA: Code cleanup. Made more code ...

2015-09-04 Thread ganeshmurthy 
GitHub user ganeshmurthy opened a pull request:

https://github.com/apache/qpid-dispatch/pull/7

NO-JIRA: Code cleanup. Made more code call the common qd_router_link_…

"NO-JIRA: Code cleanup. Made more code call the common qd_router_link_t* 
qd_router_link(qd_link_t *link, qd_link_type_t link_type, qd_direction_t 
direction, qd_address_t *owning_addr, qd_waypoint_t *wp, int mask_bit) function.

This must have been done as part of my previous pull request. 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ganeshmurthy/qpid-dispatch master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-dispatch/pull/7.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #7


commit 8c5e0380aa991c6b320a1a464ed20a12fa0918e8
Author: ganeshmurthy 
Date:   2015-09-04T18:19:31Z

NO-JIRA: Code cleanup. Made more code call the common qd_router_link_t* 
qd_router_link(qd_link_t *link, qd_link_type_t link_type, qd_direction_t 
direction, qd_address_t *owning_addr, qd_waypoint_t *wp, int mask_bit) function




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Resolved] (QPID-6718) parsing errors for integer literals in selectors

2015-09-04 Thread Andrew Stitcher (JIRA) 

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

Andrew Stitcher resolved QPID-6718.
---
   Resolution: Fixed
Fix Version/s: qpid-cpp-next

> parsing errors for integer literals in selectors
> 
>
> Key: QPID-6718
> URL: https://issues.apache.org/jira/browse/QPID-6718
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Client
>Affects Versions: qpid-cpp-0.34
>Reporter: Gordon Sim
>Assignee: Andrew Stitcher
>Priority: Minor
> Fix For: qpid-cpp-next
>
>
> There are a few integer literals that cause selector parsing to fail or the 
> resulting evaluation to be incorrect:
> (a) hexadecimal literals don't seem to be recognised, e.g. 0xFF will result 
> in a parse error
> (b) octal literals are evaluated as decimal e.g 077 is interpreted as decimal 
> 77 rather than decimal 63
> (c) large numbers fail with a lexical cast error, e.g -9223372036854775808L 
> or 9223372036854775807L



--
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

[GitHub] qpid-dispatch pull request: NO-JIRA: Code cleanup. Made more code ...

2015-09-04 Thread asfgit 
Github user asfgit closed the pull request at:

https://github.com/apache/qpid-dispatch/pull/7


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Created] (DISPATCH-164) Remove connector state-machine from the server module

2015-09-04 Thread Ted Ross (JIRA) 
Ted Ross created DISPATCH-164:
-

 Summary: Remove connector state-machine from the server module
 Key: DISPATCH-164
 URL: https://issues.apache.org/jira/browse/DISPATCH-164
 Project: Qpid Dispatch
  Issue Type: Improvement
  Components: Container
Reporter: Ted Ross
Assignee: Ted Ross
 Fix For: 0.6


The server module implements a state machine that monitors the asynchronous 
creation of outbound connections from connectors.
With the latest Proton Engine API, this is no longer necessary as connection 
setup and authentication is all handled by Proton.  This state machine can be 
removed and the code simplified.



--
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] (DISPATCH-163) Add username and password for authentication of connectors

2015-09-04 Thread Ted Ross (JIRA) 

[ 
https://issues.apache.org/jira/browse/DISPATCH-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14731340#comment-14731340
 ] 

Ted Ross commented on DISPATCH-163:
---

The connector state-machine adds the pn_connection_t to the transport late in 
the process (after I/O has already occurred).  Since the username and password 
are attributes of the pn_connection_t, they can't be provided until it is too 
late and the SASL exchange has already begun.


> Add username and password for authentication of connectors
> --
>
> Key: DISPATCH-163
> URL: https://issues.apache.org/jira/browse/DISPATCH-163
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Container
>Reporter: Ted Ross
> Fix For: 0.6
>
>
> Currently, connectors cannot use PLAIN authentication because there is no 
> configuration for username and password.  This needs to be added.



--
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-6717) selector can match incorrectly due to different type for values

2015-09-04 Thread ASF subversion and git services (JIRA) 

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

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

Commit 1701301 from [~astitcher] in branch 'qpid/trunk'
[ https://svn.apache.org/r1701301 ]

QPID-6717: Change Selector beaviour and tests to accord with consensus semantics
- It seems to be the consensus amongst JMS Selector implementations that
  the NOT IN expression should return false if none of the types match

> selector can match incorrectly due to different type for values
> ---
>
> Key: QPID-6717
> URL: https://issues.apache.org/jira/browse/QPID-6717
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: qpid-cpp-0.34
>Reporter: Gordon Sim
>Assignee: Andrew Stitcher
>Priority: Minor
> Fix For: qpid-cpp-next
>
>
> E.g. a selector "x BETWEEN 1 AND 10" would match for a value of x="foo", 
> because of the way the logic is implemented for the between expression, or a 
> selector "x NOT IN ('a', 'b', 'c')" would match where x=1, though it should 
> not due to the type mismatch.
> From JMS spec: "Only like type values can be compared. One exception is that 
> it is valid to compare exact numeric values and approximate numeric values"



--
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-6727) Remove sendBufferSize/receiveBufferSize from AmqpPort and make max framesize/sendBufferSize/receiveBufferSize share a single source

2015-09-04 Thread Lorenz Quack (JIRA) 
Lorenz Quack created QPID-6727:
--

 Summary: Remove sendBufferSize/receiveBufferSize from AmqpPort and 
make max framesize/sendBufferSize/receiveBufferSize share a single source
 Key: QPID-6727
 URL: https://issues.apache.org/jira/browse/QPID-6727
 Project: Qpid
  Issue Type: Improvement
Reporter: Lorenz Quack


Currently the TCP/IP buffer sizes (sendBufferSize/receiveBufferSize) are 
attributes of AmpqPort.  For the new memory model, supporting different ports 
using different receive buffers would be problematic and cause inefficient use 
of direct memory.  Similarly clients using framesizes where the framesize 
!=buffer size will be inefficient.

# Remove sendBufferSize/receiveBufferSize from the Port.
# Make max frame size and sendBufferSize/receiveBufferSize share a single 
source which should be a context variable belonging to the Broker. Minimum size 
must be no smaller than SSL netbuffer size
# The context variable should be evaluated only once at Broker startup.
# Upgraders should remove the attribute from AmqpPorts




--
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-6662) Use direct byte buffers

2015-09-04 Thread Lorenz Quack (JIRA) 

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

Lorenz Quack commented on QPID-6662:


Today, I stumbled over the QpidByteBuffer#allocateDirectFromPool().
I find the name a bit unfortunate because:
* It might not allocate from a pool (if size > maxPooledBufferSize)
* QpidByteBuffer#allocateDirect() may allocate from a pool as well.
* It does not describe what the method is about (slicing a larger buffer to 
efficiently handle smaller allocations)

IMHO, the method should go away and its functionality should be handled 
transparently by QpidByteBuffer#allocateDirect(). There could be a threshold 
(e.g., 0.25 * _maxPooledBufferSize) and for calls smaller than that it could 
use a cached slicing buffer and for larger ones it could keep its current 
behaviour.

> Use direct byte buffers
> ---
>
> Key: QPID-6662
> URL: https://issues.apache.org/jira/browse/QPID-6662
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.0
>
>
> To improve performance of the Broker, direct ByteBuffers should be passed 
> from the transport directly to the store, minimising copying whenever 
> possible, and vice versa. 



--
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] [Comment Edited] (QPIDJMS-105) Cannot set messageId to UUID-format

2015-09-04 Thread Pontus Liljegren (JIRA) 

[ 
https://issues.apache.org/jira/browse/QPIDJMS-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14730395#comment-14730395
 ] 

Pontus Liljegren edited comment on QPIDJMS-105 at 9/4/15 7:33 AM:
--

I see in the old implementation it used the messageId from the message and if 
that was not present it generated a new one. Was this changed due to what 
Timothy writes?

http://svn.apache.org/viewvc/qpid/tags/0.32/qpid/java/amqp-1-0-client-jms/src/main/java/org/apache/qpid/amqp_1_0/jms/impl/MessageProducerImpl.java?view=markup
 (line 290)

A solution similar to that would be great to have if it is possible.



was (Author: p3anuts):
I see in the old implementation it used the messageId from the jms message and 
if that was not present it generated a new one. Was this changed due to what 
Timothy writes?

http://svn.apache.org/viewvc/qpid/tags/0.32/qpid/java/amqp-1-0-client-jms/src/main/java/org/apache/qpid/amqp_1_0/jms/impl/MessageProducerImpl.java?view=markup
 (line 290)

A solution similar to that would be great to have if it is possible.


> Cannot set messageId to UUID-format
> ---
>
> Key: QPIDJMS-105
> URL: https://issues.apache.org/jira/browse/QPIDJMS-105
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Reporter: Pontus Liljegren
>
> We need to set a messageId to UUID format on messages we send. When I look at 
> the source code in 
> https://github.com/apache/qpid-jms/blob/master/qpid-jms-client/src/main/java/org/apache/qpid/jms/JmsSession.java
>  I see that the message id is generated using the producer id and a sequence 
> number. (Line 923).
> Is it not possible to use UUID:s as message ids?
> Question on Stack overflow: 
> http://stackoverflow.com/questions/32353797/apache-camel-qpid-set-messageid-to-uuid-not-working



--
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] (QPIDJMS-105) Cannot set messageId to UUID-format

2015-09-04 Thread Pontus Liljegren (JIRA) 

[ 
https://issues.apache.org/jira/browse/QPIDJMS-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14730395#comment-14730395
 ] 

Pontus Liljegren commented on QPIDJMS-105:
--

I see in the old implementation it used the messageId from the jms message and 
if that was not present it generated a new one. Was this changed due to what 
Timothy writes?

http://svn.apache.org/viewvc/qpid/tags/0.32/qpid/java/amqp-1-0-client-jms/src/main/java/org/apache/qpid/amqp_1_0/jms/impl/MessageProducerImpl.java?view=markup
 (line 290)

A solution similar to that would be great to have if it is possible.


> Cannot set messageId to UUID-format
> ---
>
> Key: QPIDJMS-105
> URL: https://issues.apache.org/jira/browse/QPIDJMS-105
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Reporter: Pontus Liljegren
>
> We need to set a messageId to UUID format on messages we send. When I look at 
> the source code in 
> https://github.com/apache/qpid-jms/blob/master/qpid-jms-client/src/main/java/org/apache/qpid/jms/JmsSession.java
>  I see that the message id is generated using the producer id and a sequence 
> number. (Line 923).
> Is it not possible to use UUID:s as message ids?
> Question on Stack overflow: 
> http://stackoverflow.com/questions/32353797/apache-camel-qpid-set-messageid-to-uuid-not-working



--
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] [Issue Comment Deleted] (QPIDJMS-105) Cannot set messageId to UUID-format

2015-09-04 Thread Pontus Liljegren (JIRA) 

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

Pontus Liljegren updated QPIDJMS-105:
-
Comment: was deleted

(was: Ok, thanks. I saw now in the source code for the old library that 
generateMessageId() at line 373 creates a new UUID. I was under the impression 
that it used the JMSMessageId but I was mistaken.
http://svn.apache.org/viewvc/qpid/tags/0.32/qpid/java/amqp-1-0-client-jms/src/main/java/org/apache/qpid/amqp_1_0/jms/impl/MessageProducerImpl.java?view=markup)

> Cannot set messageId to UUID-format
> ---
>
> Key: QPIDJMS-105
> URL: https://issues.apache.org/jira/browse/QPIDJMS-105
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Reporter: Pontus Liljegren
>
> We need to set a messageId to UUID format on messages we send. When I look at 
> the source code in 
> https://github.com/apache/qpid-jms/blob/master/qpid-jms-client/src/main/java/org/apache/qpid/jms/JmsSession.java
>  I see that the message id is generated using the producer id and a sequence 
> number. (Line 923).
> Is it not possible to use UUID:s as message ids?
> Question on Stack overflow: 
> http://stackoverflow.com/questions/32353797/apache-camel-qpid-set-messageid-to-uuid-not-working



--
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] (QPIDJMS-105) Cannot set messageId to UUID-format

2015-09-04 Thread Robbie Gemmell (JIRA) 

[ 
https://issues.apache.org/jira/browse/QPIDJMS-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14730537#comment-14730537
 ] 

Robbie Gemmell commented on QPIDJMS-105:


It wasnt specifically 'changed' as such, the newer client was not based on the 
old one (which originated from prototyping work during creation of the AMQP 1.0 
protocol itself), its just the case that the newer client has not been written 
to do that since it isnt actually in keeping with the behaviour JMS details.

> Cannot set messageId to UUID-format
> ---
>
> Key: QPIDJMS-105
> URL: https://issues.apache.org/jira/browse/QPIDJMS-105
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Reporter: Pontus Liljegren
>
> We need to set a messageId to UUID format on messages we send. When I look at 
> the source code in 
> https://github.com/apache/qpid-jms/blob/master/qpid-jms-client/src/main/java/org/apache/qpid/jms/JmsSession.java
>  I see that the message id is generated using the producer id and a sequence 
> number. (Line 923).
> Is it not possible to use UUID:s as message ids?
> Question on Stack overflow: 
> http://stackoverflow.com/questions/32353797/apache-camel-qpid-set-messageid-to-uuid-not-working



--
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