[jira] [Updated] (QPID-4390) Java Broker should allow runtime changes to persisted configuration

2013-02-19 Thread Alex Rudyy (JIRA)

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

Alex Rudyy updated QPID-4390:
-

Status: Ready To Review  (was: In Progress)

 Java Broker should allow runtime changes to persisted configuration
 ---

 Key: QPID-4390
 URL: https://issues.apache.org/jira/browse/QPID-4390
 Project: Qpid
  Issue Type: Improvement
  Components: Java Broker
Affects Versions: 0.19
Reporter: Philip Harvey
Assignee: Alex Rudyy
 Attachments: 
 0001-QPID-4390-Introduce-a-configuration-store-in-java-broker.patch.tar.gz


 The design for the new configuration store is on the wiki:
 [https://cwiki.apache.org/confluence/display/qpid/New+design+for+the+Java+Broker+configuration]

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

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



[jira] [Assigned] (QPID-4390) Java Broker should allow runtime changes to persisted configuration

2013-02-19 Thread Alex Rudyy (JIRA)

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

Alex Rudyy reassigned QPID-4390:


Assignee: Robbie Gemmell  (was: Alex Rudyy)

Robbie,
Could you please review the changes committed in revision 
https://svn.apache.org/repos/asf/qpid/trunk@1447646 ?

 Java Broker should allow runtime changes to persisted configuration
 ---

 Key: QPID-4390
 URL: https://issues.apache.org/jira/browse/QPID-4390
 Project: Qpid
  Issue Type: Improvement
  Components: Java Broker
Affects Versions: 0.19
Reporter: Philip Harvey
Assignee: Robbie Gemmell
 Attachments: 
 0001-QPID-4390-Introduce-a-configuration-store-in-java-broker.patch.tar.gz


 The design for the new configuration store is on the wiki:
 [https://cwiki.apache.org/confluence/display/qpid/New+design+for+the+Java+Broker+configuration]

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

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



[jira] [Commented] (QPID-3650) cast-align errors while building for various architectures

2013-02-19 Thread Darryl L. Pierce (JIRA)

[ 
https://issues.apache.org/jira/browse/QPID-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13581338#comment-13581338
 ] 

Darryl L. Pierce commented on QPID-3650:


Does this issue still occur with the more recent releases? We've pushed a fix 
that works on ARM  platforms, please verify that it works on the other 
platforms and, if so, please close out this ticket. Thanks.

 cast-align errors while building for various architectures
 --

 Key: QPID-3650
 URL: https://issues.apache.org/jira/browse/QPID-3650
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.12
 Environment: Debian unstable
Reporter: Cajus Pollmeier
Assignee: Darryl L. Pierce
  Labels: build

 While running thru various architecture builds for Debian, I'm running in 
 these errors for ia64, armel, mips, mipsel and sparc:
 8
 libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../include -I../include -I. -I=. 
 -D_FORTIFY_SOURCE=2 -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 -DQPID_LIBEXEC_DIR=\/usr/lib/qpid\ 
 -DBOOST_FILESYSTEM_VERSION=2 -Wno-missing-field-initializers -g -O2 
 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security 
 -Werror=format-security -c qpid/sys/rdma/RdmaIO.cpp  -fPIC -DPIC -o 
 qpid/sys/rdma/.libs/librdmawrap_la-RdmaIO.o
 qpid/sys/rdma/RdmaIO.cpp: In member function 'void 
 Rdma::AsynchIO::queueBuffer(Rdma::Buffer*, int)':
 qpid/sys/rdma/RdmaIO.cpp:203:59: error: cast from 'char*' to 'uint32_t* {aka 
 unsigned int*}' increases required alignment of target type 
 [-Werror=cast-align]
 cc1plus: all warnings being treated as errors
 make[4]: *** [qpid/sys/rdma/librdmawrap_la-RdmaIO.lo] Error 1
 make[4]: Leaving directory 
 `/build/buildd-qpid-cpp_0.12-2-armel-ztyDej/qpid-cpp-0.12/src'
 make[3]: *** [all-recursive] Error 1
 make[3]: Leaving directory 
 `/build/buildd-qpid-cpp_0.12-2-armel-ztyDej/qpid-cpp-0.12/src'
 make[2]: *** [all] Error 2
 make[1]: *** [all-recursive] Error 1
 dh_auto_build: make -j1 returned exit code 2
 make[2]: Leaving directory 
 `/build/buildd-qpid-cpp_0.12-2-armel-ztyDej/qpid-cpp-0.12/src'
 make[1]: Leaving directory 
 `/build/buildd-qpid-cpp_0.12-2-armel-ztyDej/qpid-cpp-0.12'
 make: *** [build] Error 2
 8
 The complete logs are here:
 https://buildd.debian.org/status/package.php?p=qpid-cpp

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

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



Re: Review Request: PROTON-200: messenger::recv(-1) allows unlimited credit to all receivers.

2013-02-19 Thread Kenneth Giusti


 On Feb. 18, 2013, 9:28 p.m., Rafael Schloming wrote:
  /proton/trunk/proton-c/bindings/python/proton.py, line 371
  https://reviews.apache.org/r/9503/diff/1/?file=259617#file259617line371
 
  should update the docs to reflec the optional parameter

Now reads:


Receives up to I{n} messages into the incoming queue of the
L{Messenger}. If I{n} is not specified, L{Messenger} will receive as many
messages as it can buffer internally. This method will block until at least
one message is available or the operation times out.


Please let me know if that's ok, otherwise please give me the specific text 
you'd prefer.


 On Feb. 18, 2013, 9:28 p.m., Rafael Schloming wrote:
  /proton/trunk/proton-c/include/proton/messenger.h, line 337
  https://reviews.apache.org/r/9503/diff/1/?file=259619#file259619line337
 
  I'd document the semantics a bit more vaguely here. What we're really 
  doing is allowing the limit to be managed internally. Saying that we allow 
  at least one message from each peer is actually more specific than we 
  need/want to be.

Now reads:

/** Receives up to n messages into the incoming message queue of a
 * messenger. If n is -1, Messenger will be able to receive as many
 * messages as it can buffer internally.  Blocks until at least one
 * message is available in the incoming queue.
 *
 * @param[in] messenger the messenger
 * @param[in] n the maximum number of messages to receive or -1 to to
 * receive as many messages as it can buffer internally.
 *
 * @return an error code or zero on success
 * @see error.h
 */

Ditto previous comment.


- Kenneth


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


On Feb. 18, 2013, 8:58 p.m., Kenneth Giusti wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/9503/
 ---
 
 (Updated Feb. 18, 2013, 8:58 p.m.)
 
 
 Review request for qpid, mick goulish, Rafael Schloming, and Philip Harvey.
 
 
 Description
 ---
 
 This implements the recv(-1) api change:  passing -1 to messenger::recv() 
 causes messenger to grant one credit to every active receiver link.
 
 Note this does not implement the same behavior for the Java implementation of 
 messenger - not sure even if the same bug is present with that implementation.
 
 
 This addresses bug proton-200.
 https://issues.apache.org/jira/browse/proton-200
 
 
 Diffs
 -
 
   /proton/trunk/proton-c/bindings/python/proton.py 1447222 
   /proton/trunk/proton-c/include/proton/cproton.i 1447222 
   /proton/trunk/proton-c/include/proton/messenger.h 1447222 
   /proton/trunk/proton-c/src/messenger.c 1447222 
   
 /proton/trunk/proton-j/proton/src/main/java/org/apache/qpid/proton/messenger/impl/MessengerImpl.java
  1447222 
   /proton/trunk/tests/python/proton_tests/messenger.py 1447222 
 
 Diff: https://reviews.apache.org/r/9503/diff/
 
 
 Testing
 ---
 
 additional python unit test to exercise this problem.
 
 
 Thanks,
 
 Kenneth Giusti
 




Re: Review Request: PROTON-215: Add type coverage to Java InteropTest.

2013-02-19 Thread Alan Conway

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

(Updated Feb. 19, 2013, 3:17 p.m.)


Review request for qpid, Kenneth Giusti and Rafael Schloming.


Changes
---

Added InteropTest.java, tests both JNI and Native. The test  uses a subset of 
the native Decoder interface. On the native build  this is actually a Decoder, 
on JNI it is a wrapper for codec.Data.


Summary (updated)
-

PROTON-215: Add type coverage to Java InteropTest.


Description (updated)
---

PROTON-215: Add type coverage to Java InteropTest.

Covers all types except:
- described types, described arrays: not yet done
- empty array: throws NPE, possible bug in the decoder.

PROTON-215: Fix bug in array decoding discovered by new tests.

JNIData.getJavaMap() was alwayws returning an empty map.

PROTON-215: Java InteropTest test for primitve types.

Added Java test coverage for just the primitive types, more types coming soon.

PROTON-215: Interop test: make finding AMQP fragments more robust.

Python: find the interop fragments by walking up the directory tree from 
__file__.
Java: Copy AMQP fragments as resources.

git-svn-id: https://svn.apache.org/repos/asf/qpid/proton/trunk@1446307 
13f79535-47bb-0310-9956-ffa450edef68


Diffs (updated)
-

  
/proton/trunk/proton-c/bindings/java/src/main/java/org/apache/qpid/proton/TestDecoder.java
 PRE-CREATION 
  
/proton/trunk/proton-c/bindings/java/src/main/java/org/apache/qpid/proton/codec/jni/JNIData.java
 1447222 
  
/proton/trunk/proton-j/proton/src/main/java/org/apache/qpid/proton/TestDecoder.java
 PRE-CREATION 
  /proton/trunk/tests/interop/message.amqp UNKNOWN 
  /proton/trunk/tests/java/org/apache/qpid/proton/InteropTest.java PRE-CREATION 
  /proton/trunk/tests/python/interop-generate 1447222 
  /proton/trunk/tests/python/proton_tests/interop.py 1447222 

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


Testing
---

described_array test fails, skipping. I believe the tests have found their 
first bug :)


Thanks,

Alan Conway



Re: Review Request: Final Visual Studio build issues

2013-02-19 Thread Cliff Jansen

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

(Updated Feb. 19, 2013, 3:59 p.m.)


Review request for qpid and Rafael Schloming.


Changes
---

Same as before, but with added README changes with Windows build instructions 
and use of ctest


Description
---

These changes (against 0.4 rc1) allow a complete build of the C portions of 
proton-c in Visual Studio.  Of main note is the addition of freegetopt as a 3rd 
party module and the change to the top level license file.


This addresses bugs proton-236 and proton-237.
https://issues.apache.org/jira/browse/proton-236
https://issues.apache.org/jira/browse/proton-237


Diffs (updated)
-

  http://svn.apache.org/repos/asf/qpid/proton/trunk/LICENSE 1446820 
  http://svn.apache.org/repos/asf/qpid/proton/trunk/README 1446820 
  http://svn.apache.org/repos/asf/qpid/proton/trunk/examples/messenger/c/recv.c 
1446820 
  http://svn.apache.org/repos/asf/qpid/proton/trunk/examples/messenger/c/send.c 
1446820 
  http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/proton.c 
1446820 
  http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/util.h 1446820 
  http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/wincompat/getopt.h 
PRE-CREATION 
  
http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/wincompat/internal/LICENSE
 PRE-CREATION 
  
http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/wincompat/internal/getopt.h
 PRE-CREATION 
  
http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/wincompat/internal/getopt.c
 PRE-CREATION 

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


Testing
---

Tested on rhel6 and VS2008


Thanks,

Cliff Jansen



[jira] [Assigned] (QPID-530) Support selectors on consume

2013-02-19 Thread Ken Giusti (JIRA)

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

Ken Giusti reassigned QPID-530:
---

Assignee: Andrew Stitcher  (was: Ken Giusti)

 Support selectors on consume
 

 Key: QPID-530
 URL: https://issues.apache.org/jira/browse/QPID-530
 Project: Qpid
  Issue Type: New Feature
  Components: C++ Broker
Reporter: Gordon Sim
Assignee: Andrew Stitcher
 Fix For: Future




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

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



[jira] [Resolved] (QPID-2889) WCF client crash with corrupted heap if broker is not available

2013-02-19 Thread Cliff Jansen (JIRA)

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

Cliff Jansen resolved QPID-2889.


   Resolution: Fixed
Fix Version/s: 0.8

This appears fixed based on the comments in 0.8.


 WCF client crash with corrupted heap if broker is not available
 ---

 Key: QPID-2889
 URL: https://issues.apache.org/jira/browse/QPID-2889
 Project: Qpid
  Issue Type: Bug
  Components: WCF/C++ Client
Affects Versions: 0.6
 Environment: qpid 0.6 cpp broker and WCF Binding
 OS: Windows 7 x86
Reporter: Daniel Sack
Assignee: Cliff Jansen
Priority: Critical
 Fix For: 0.8


 If and WCF client is trying to send a message and the broker is not available 
 the client will crash with the following error:
 Unhandled exception at 0x77912913 in w3wp.exe: 0xC374: A heap has been 
 corrupted.
 In the windows eventlog you will also find then the following entry:
 Faulting application name: w3wp.exe, version: 7.5.7600.16385, time stamp: 
 0x4a5bcd2b
 Faulting module name: ntdll.dll, version: 6.1.7600.16559, time stamp: 
 0x4ba9b21e
 Exception code: 0xc374
 Fault offset: 0x000c2913
 Faulting process id: 0x23e4
 Faulting application start time: 0x01cb608bfcb4e9f5
 Faulting application path: c:\windows\system32\inetsrv\w3wp.exe
 Faulting module path: C:\Windows\SYSTEM32\ntdll.dll

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

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



[jira] [Created] (QPID-4591) mechanism to detect when messages are overwritten in ring-type queues

2013-02-19 Thread Ernest Allen (JIRA)
Ernest Allen created QPID-4591:
--

 Summary: mechanism to detect when messages are overwritten in 
ring-type queues
 Key: QPID-4591
 URL: https://issues.apache.org/jira/browse/QPID-4591
 Project: Qpid
  Issue Type: New Feature
  Components: C++ Broker
Affects Versions: 0.18
Reporter: Ernest Allen
 Fix For: Future


A way to determine when a ring queue is full and old messages are being 
deleted. Also need a way to determine when the ring queue is no longer full.

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

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



[jira] [Resolved] (QPID-3397) Add Broker management methods for several queue functions

2013-02-19 Thread michael goulish (JIRA)

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

michael goulish resolved QPID-3397.
---

Resolution: Won't Fix

 Add Broker management methods for several queue functions
 -

 Key: QPID-3397
 URL: https://issues.apache.org/jira/browse/QPID-3397
 Project: Qpid
  Issue Type: Improvement
  Components: C++ Broker
Affects Versions: 0.14
Reporter: michael j. goulish
Assignee: michael j. goulish

 Implement broker management functions to 
   (1) return the ID list of all messages on a queue.
   (2) retrieve the header of a given message on a given queue
   (3) retrieve the body of a given message on a given queue
   (4) remove a given message from a given queue.

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

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



[jira] [Commented] (QPID-4591) mechanism to detect when messages are overwritten in ring-type queues

2013-02-19 Thread Ernest Allen (JIRA)

[ 
https://issues.apache.org/jira/browse/QPID-4591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13581452#comment-13581452
 ] 

Ernest Allen commented on QPID-4591:


A suggested implementation is:
Send the deleted messages to the alternate exchange associated with a queue. 
That would let any application detect them by binding to that exchange as 
appropriate. That is also more susceptible to ACL control.

To avoid this mechanism causing build up of messages that the ring policy is 
attempting to avoid, the queue bound to the alternate exchange could have be a 
ring queue of size 1, meaning it only ever held the last message which I think 
would be sufficient to notify of the dropping of messages.

So for the application, the following would happen:
- create an alternate exchange for use with the ring queue
- create the ring queue, associating it with the alternate exchange
- create an overflow ring queue with max-count=1
- bind the overflow queue with the alternate exchange

- watch the overflow queue. When a message appears, the original queue is full 
and has just overflowed.
- remove the overflow message

 mechanism to detect when messages are overwritten in ring-type queues
 -

 Key: QPID-4591
 URL: https://issues.apache.org/jira/browse/QPID-4591
 Project: Qpid
  Issue Type: New Feature
  Components: C++ Broker
Affects Versions: 0.18
Reporter: Ernest Allen
 Fix For: Future


 A way to determine when a ring queue is full and old messages are being 
 deleted. Also need a way to determine when the ring queue is no longer full.

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

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



Review Request: Check the if_empty and if_unused flags when deleting a queue with deleteObject()

2013-02-19 Thread Ernie Allen

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

Review request for qpid.


Description
---

Adds a check() method to the broker and passes it to queueDelete to inspect the 
if_unused and if_empty flags. 


This addresses bug QPID-4559.
https://issues.apache.org/jira/browse/QPID-4559


Diffs
-

  /trunk/qpid/cpp/src/qpid/broker/Broker.h 1447816 
  /trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1447816 

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


Testing
---

unit tests: created queue, added messages, deleted queue with and without flags 
and with and without messages and connections


Thanks,

Ernie Allen



Re: Review Request: QPID-4559 Check the if_empty and if_unused flags when deleting a queue with deleteObject()

2013-02-19 Thread Ernie Allen

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

(Updated Feb. 19, 2013, 5:36 p.m.)


Review request for qpid.


Summary (updated)
-

QPID-4559 Check the if_empty and if_unused flags when deleting a queue with 
deleteObject()


Description
---

Adds a check() method to the broker and passes it to queueDelete to inspect the 
if_unused and if_empty flags. 


This addresses bug QPID-4559.
https://issues.apache.org/jira/browse/QPID-4559


Diffs
-

  /trunk/qpid/cpp/src/qpid/broker/Broker.h 1447816 
  /trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1447816 

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


Testing
---

unit tests: created queue, added messages, deleted queue with and without flags 
and with and without messages and connections


Thanks,

Ernie Allen



Re: Review Request: PROTON-215: Add tests to verify AMQP 1.0 type support for all language bindings

2013-02-19 Thread Alan Conway

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

(Updated Feb. 19, 2013, 5:41 p.m.)


Review request for qpid, Kenneth Giusti and Rafael Schloming.


Changes
---

Java coverage now same as python.


Summary (updated)
-

PROTON-215: Add tests to verify AMQP 1.0 type support for all language bindings


Description (updated)
---

Python and Java tests in place, PHP, Perl and ruby to come.


Diffs (updated)
-

  
/proton/trunk/proton-c/bindings/java/src/main/java/org/apache/qpid/proton/TestDecoder.java
 PRE-CREATION 
  
/proton/trunk/proton-c/bindings/java/src/main/java/org/apache/qpid/proton/codec/jni/JNIData.java
 1447222 
  
/proton/trunk/proton-j/proton/src/main/java/org/apache/qpid/proton/TestDecoder.java
 PRE-CREATION 
  /proton/trunk/tests/interop/message.amqp UNKNOWN 
  /proton/trunk/tests/java/org/apache/qpid/proton/InteropTest.java PRE-CREATION 
  /proton/trunk/tests/python/interop-generate 1447222 
  /proton/trunk/tests/python/proton_tests/interop.py 1447222 

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


Testing (updated)
---

echo  python
tests/python/proton-test *.interop.* || EXIT=1
echo  proton-jni
mvn -P proton-jni -Dtest=InteropTest -DfailIfNoTests=false test || EXIT=1
echo  proton-j
mvn -P proton-j -Dtest=InteropTest -DfailIfNoTests=false test || EXIT=1


Thanks,

Alan Conway



Re: Review Request: QPID-4559 Check the if_empty and if_unused flags when deleting a queue with deleteObject()

2013-02-19 Thread Ernie Allen

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

(Updated Feb. 19, 2013, 6:14 p.m.)


Review request for qpid and Ted Ross.


Description
---

Adds a check() method to the broker and passes it to queueDelete to inspect the 
if_unused and if_empty flags. 


This addresses bug QPID-4559.
https://issues.apache.org/jira/browse/QPID-4559


Diffs
-

  /trunk/qpid/cpp/src/qpid/broker/Broker.h 1447816 
  /trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1447816 

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


Testing
---

unit tests: created queue, added messages, deleted queue with and without flags 
and with and without messages and connections


Thanks,

Ernie Allen



Review Request: PROTON-232: described arrays seem to force the descriptor to be of the same type as the array

2013-02-19 Thread Alan Conway

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

Review request for qpid, Kenneth Giusti and Rafael Schloming.


Description
---

PROTON-232: described arrays seem to force the descriptor to be of the same 
type as the array

Fixed bug in code.c pn_data_encode_node: was always using the parent-type
for everything inside an array, including the descriptor.


Diffs
-

  /proton/trunk/proton-c/src/codec/codec.c 1447222 
  /proton/trunk/tests/interop/described_array.amqp UNKNOWN 
  /proton/trunk/tests/python/proton_tests/interop.py 1447222 

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


Testing
---

jni, java-native and python tests all pass. New test case added in interop.py


Thanks,

Alan Conway



Re: Review Request: PROTON-232: described arrays seem to force the descriptor to be of the same type as the array

2013-02-19 Thread Rafael Schloming

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

Ship it!


Ship It!

- Rafael Schloming


On Feb. 19, 2013, 9:16 p.m., Alan Conway wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/9516/
 ---
 
 (Updated Feb. 19, 2013, 9:16 p.m.)
 
 
 Review request for qpid, Kenneth Giusti and Rafael Schloming.
 
 
 Description
 ---
 
 PROTON-232: described arrays seem to force the descriptor to be of the same 
 type as the array
 
 Fixed bug in code.c pn_data_encode_node: was always using the parent-type
 for everything inside an array, including the descriptor.
 
 
 Diffs
 -
 
   /proton/trunk/proton-c/src/codec/codec.c 1447222 
   /proton/trunk/tests/interop/described_array.amqp UNKNOWN 
   /proton/trunk/tests/python/proton_tests/interop.py 1447222 
 
 Diff: https://reviews.apache.org/r/9516/diff/
 
 
 Testing
 ---
 
 jni, java-native and python tests all pass. New test case added in interop.py
 
 
 Thanks,
 
 Alan Conway
 




0.22 release update - alpha is postponed

2013-02-19 Thread Justin Ross
Hi.  As we discussed on the list[1], we're postponing the 0.22 alpha.
I've reset it for 4 March and updated the subsequent release dates
accordingly.

Thanks!
Justin

[1] 
http://qpid.2158936.n2.nabble.com/0-22-release-update-alpha-approaches-td7588356.html

---
0.22 release page: https://cwiki.apache.org/qpid/022-release.html

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



[jira] [Commented] (QPID-4589) C++ client unable to connect to Java Broker

2013-02-19 Thread Keith Wall (JIRA)

[ 
https://issues.apache.org/jira/browse/QPID-4589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13581705#comment-13581705
 ] 

Keith Wall commented on QPID-4589:
--

James,

Given your description, your issue is likely to be the absence of cyrus-sasl 
package on the new Redhat 6.3 machines hosting your client.

QPID-4419 was concerned only the Java Broker's ability to detect and cleanly 
report the fact that the client had failed to select a SASL mechanism in the 
connection.start control.   If you were to upgrade to 0.20, I would expect your 
underlying problem to persist, but you'll probably see a clearer error message 
(I haven't tried this).

I think the other questions may better belong on the one of the Qpid mailing 
lists http://qpid.apache.org/mailing_lists.html.  

Hope this helps.
Keith.


 

 C++ client unable to connect to Java Broker
 ---

 Key: QPID-4589
 URL: https://issues.apache.org/jira/browse/QPID-4589
 Project: Qpid
  Issue Type: Bug
  Components: Java Broker
Affects Versions: 0.18
 Environment: C++ client and Java Broker running on Redhat 6.3
Reporter: James Belch
Priority: Minor

 Our C++ clients were initially running on Redhat 5.4 and communicating with a 
 Java Broker running on Redhat 6.3.  Everything was working fine.  We need to 
 move our C++ development over to another network which use Redhat 6.3.  
 Because of this, we needed to rebuild our C++ executables on Redhat 6.3.  
 When attempting to connect with a 6.3 C++ client, we get an error while 
 trying connect to the Java Broker.  It returns an error saying Reconnect 
 disabled.  It appears to be similar to the following issue, 
 https://issues.apache.org/jira/browse/QPID-4419;. I am able to connect to 
 the C++ broker successfully from the Redhat 6.3 client.  My questions are:
 1.  Is this a bug that has been fixed or is there something that we can do in 
 our .18 Java Broker configuration to solve this problem?  We are currently 
 using the default Java Broker configuration.
 2.  Do you think this is related to QPID-4419 from above?  If so, should we 
 upgrade to Qpid .20 to solve this problem?
 3.  Do you recommend using the Java Broker or the C++ Broker?  We have 
 thought about switching over to the C++ Broker, but we wanted to know if you 
 could answer the following questions:
 a.  Do you know how many of your Redhat customers use the Java Broker?   
 Do you think the Java Broker and C++ Broker are used equally 
 or is one preferred over the other?
 b.  Which Broker (Java or C++) offers better performance?
 c.  Do you offer the same support for the Java and C++ Brokers.  Do bugs 
 written against the Java Broker and C++ Broker get the same priority?

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

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



[jira] [Assigned] (QPID-4589) C++ client unable to connect to Java Broker

2013-02-19 Thread Keith Wall (JIRA)

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

Keith Wall reassigned QPID-4589:


Assignee: Keith Wall

 C++ client unable to connect to Java Broker
 ---

 Key: QPID-4589
 URL: https://issues.apache.org/jira/browse/QPID-4589
 Project: Qpid
  Issue Type: Bug
  Components: Java Broker
Affects Versions: 0.18
 Environment: C++ client and Java Broker running on Redhat 6.3
Reporter: James Belch
Assignee: Keith Wall
Priority: Minor

 Our C++ clients were initially running on Redhat 5.4 and communicating with a 
 Java Broker running on Redhat 6.3.  Everything was working fine.  We need to 
 move our C++ development over to another network which use Redhat 6.3.  
 Because of this, we needed to rebuild our C++ executables on Redhat 6.3.  
 When attempting to connect with a 6.3 C++ client, we get an error while 
 trying connect to the Java Broker.  It returns an error saying Reconnect 
 disabled.  It appears to be similar to the following issue, 
 https://issues.apache.org/jira/browse/QPID-4419;. I am able to connect to 
 the C++ broker successfully from the Redhat 6.3 client.  My questions are:
 1.  Is this a bug that has been fixed or is there something that we can do in 
 our .18 Java Broker configuration to solve this problem?  We are currently 
 using the default Java Broker configuration.
 2.  Do you think this is related to QPID-4419 from above?  If so, should we 
 upgrade to Qpid .20 to solve this problem?
 3.  Do you recommend using the Java Broker or the C++ Broker?  We have 
 thought about switching over to the C++ Broker, but we wanted to know if you 
 could answer the following questions:
 a.  Do you know how many of your Redhat customers use the Java Broker?   
 Do you think the Java Broker and C++ Broker are used equally 
 or is one preferred over the other?
 b.  Which Broker (Java or C++) offers better performance?
 c.  Do you offer the same support for the Java and C++ Brokers.  Do bugs 
 written against the Java Broker and C++ Broker get the same priority?

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

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



Re: Review Request: PROTON-200: messenger::recv(-1) allows unlimited credit to all receivers.

2013-02-19 Thread Kenneth Giusti

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

(Updated Feb. 20, 2013, 2:51 a.m.)


Review request for qpid, mick goulish, Rafael Schloming, and Philip Harvey.


Changes
---

Maintain a fixed credit level for each link.


Description
---

This implements the recv(-1) api change:  passing -1 to messenger::recv() 
causes messenger to grant one credit to every active receiver link.

Note this does not implement the same behavior for the Java implementation of 
messenger - not sure even if the same bug is present with that implementation.


This addresses bug proton-200.
https://issues.apache.org/jira/browse/proton-200


Diffs (updated)
-

  /proton/trunk/proton-c/bindings/python/proton.py 1447222 
  /proton/trunk/proton-c/include/proton/cproton.i 1447222 
  /proton/trunk/proton-c/include/proton/messenger.h 1447222 
  /proton/trunk/proton-c/src/messenger.c 1447222 
  
/proton/trunk/proton-j/proton/src/main/java/org/apache/qpid/proton/messenger/impl/MessengerImpl.java
 1447222 
  /proton/trunk/tests/python/proton_tests/messenger.py 1447222 

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


Testing
---

additional python unit test to exercise this problem.


Thanks,

Kenneth Giusti



Re: Review Request: PROTON-200: messenger::recv(-1) allows unlimited credit to all receivers.

2013-02-19 Thread Rafael Schloming

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

Ship it!


Ship It!

- Rafael Schloming


On Feb. 20, 2013, 2:51 a.m., Kenneth Giusti wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/9503/
 ---
 
 (Updated Feb. 20, 2013, 2:51 a.m.)
 
 
 Review request for qpid, mick goulish, Rafael Schloming, and Philip Harvey.
 
 
 Description
 ---
 
 This implements the recv(-1) api change:  passing -1 to messenger::recv() 
 causes messenger to grant one credit to every active receiver link.
 
 Note this does not implement the same behavior for the Java implementation of 
 messenger - not sure even if the same bug is present with that implementation.
 
 
 This addresses bug proton-200.
 https://issues.apache.org/jira/browse/proton-200
 
 
 Diffs
 -
 
   /proton/trunk/proton-c/bindings/python/proton.py 1447222 
   /proton/trunk/proton-c/include/proton/cproton.i 1447222 
   /proton/trunk/proton-c/include/proton/messenger.h 1447222 
   /proton/trunk/proton-c/src/messenger.c 1447222 
   
 /proton/trunk/proton-j/proton/src/main/java/org/apache/qpid/proton/messenger/impl/MessengerImpl.java
  1447222 
   /proton/trunk/tests/python/proton_tests/messenger.py 1447222 
 
 Diff: https://reviews.apache.org/r/9503/diff/
 
 
 Testing
 ---
 
 additional python unit test to exercise this problem.
 
 
 Thanks,
 
 Kenneth Giusti
 




Re: Review Request: Final Visual Studio build issues

2013-02-19 Thread Rafael Schloming

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

Ship it!


Ship It!

- Rafael Schloming


On Feb. 19, 2013, 3:59 p.m., Cliff Jansen wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/9489/
 ---
 
 (Updated Feb. 19, 2013, 3:59 p.m.)
 
 
 Review request for qpid and Rafael Schloming.
 
 
 Description
 ---
 
 These changes (against 0.4 rc1) allow a complete build of the C portions of 
 proton-c in Visual Studio.  Of main note is the addition of freegetopt as a 
 3rd party module and the change to the top level license file.
 
 
 This addresses bugs proton-236 and proton-237.
 https://issues.apache.org/jira/browse/proton-236
 https://issues.apache.org/jira/browse/proton-237
 
 
 Diffs
 -
 
   http://svn.apache.org/repos/asf/qpid/proton/trunk/LICENSE 1446820 
   http://svn.apache.org/repos/asf/qpid/proton/trunk/README 1446820 
   
 http://svn.apache.org/repos/asf/qpid/proton/trunk/examples/messenger/c/recv.c 
 1446820 
   
 http://svn.apache.org/repos/asf/qpid/proton/trunk/examples/messenger/c/send.c 
 1446820 
   http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/proton.c 
 1446820 
   http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/util.h 
 1446820 
   
 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/wincompat/getopt.h 
 PRE-CREATION 
   
 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/wincompat/internal/LICENSE
  PRE-CREATION 
   
 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/wincompat/internal/getopt.h
  PRE-CREATION 
   
 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/wincompat/internal/getopt.c
  PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/9489/diff/
 
 
 Testing
 ---
 
 Tested on rhel6 and VS2008
 
 
 Thanks,
 
 Cliff Jansen