[jira] [Created] (QPID-4582) C++ Broker legacystore self tests fail

[Chuck Rolke (JIRA)]

Chuck Rolke created QPID-4582:
-

 Summary: C++ Broker legacystore self tests fail
 Key: QPID-4582
 URL: https://issues.apache.org/jira/browse/QPID-4582
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.21
 Environment: Linux C++
Reporter: Chuck Rolke
Assignee: Chuck Rolke


As standalone unit test executables the legacystore self tests pass. However, 
they fail in the 'make test' setup.

qpid/b64-cmake> /usr/bin/ctest -R legacystore_SimpleTest
Test project /home/svn/qpid/b64-cmake
Start 17: legacystore_SimpleTest
1/1 Test #17: legacystore_SimpleTest ...***Not Run   0.00 sec

0% tests passed, 1 tests failed out of 1

Total Test time (real) =   0.23 sec

The following tests FAILED:
 17 - legacystore_SimpleTest (BAD_COMMAND)
Errors while running CTest





--
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-4580) Improve the Perl language binding documentation

[Darryl L. Pierce (JIRA)]

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

Darryl L. Pierce resolved QPID-4580.


   Resolution: Fixed
Fix Version/s: 0.21

> Improve the Perl language binding documentation
> ---
>
> Key: QPID-4580
> URL: https://issues.apache.org/jira/browse/QPID-4580
> Project: Qpid
>  Issue Type: Improvement
>  Components: Perl Client
>Reporter: Darryl L. Pierce
>Assignee: Darryl L. Pierce
> Fix For: 0.21
>
>
> Provide API documentation with examples.

--
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: PROTON-225: refactor transport API to move the I/O buffering into the transport

[Kenneth Giusti]

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

Review request for qpid, Rafael Schloming and Philip Harvey.


Description
---

See proton-225 jira.
This only modifies the proton-c transport.


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


Diffs
-

  /proton/trunk/proton-c/include/proton/engine.h 144 
  /proton/trunk/proton-c/src/engine/engine-internal.h 144 
  /proton/trunk/proton-c/src/engine/engine.c 144 

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


Testing
---

python unit tests


Thanks,

Kenneth Giusti

Review Request: Initial CTest support

[Cliff Jansen]

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

Review request for qpid and Mary Hinton.


Description
---

The smallest useful example I could devise to illustrate the possibilities.

See https://issues.apache.org/jira/browse/PROTON-238 for more info


This addresses bug PROTON-238.
https://issues.apache.org/jira/browse/PROTON-238


Diffs
-

  http://svn.apache.org/repos/asf/qpid/proton/trunk/CMakeLists.txt 1445761 
  http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 
1445761 

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


Testing
---

linux only so far.  Minimally the PYTHONPATH will require a ';' separator in 
Windows.


Thanks,

Cliff Jansen

Re: 0.22 release update - alpha approaches

[Gordon Sim]

On 02/13/2013 04:25 PM, Robbie Gemmell wrote:

I'd like to suggest pushing the 0.22 release process back a little
bit, given the actual 0.20 release date was only 3 weeks ago.

We delayed cutting the 0.20 branch by 3 weeks due to concentrated
work on Proton prior to ApacheCon EU, and with the holidays falling
since then its not that clear to me how much compelling new work
really exists on trunk at this point.



Given the close proximity of the last release, it seems like allowing
a bit more time for the next release would be good, and preferable to
the overhead of us requesting significant numbers of merges later
on.

What do you (or anyone else for that matter) think?


No objection from me; what you say makes sense!


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

[jira] [Resolved] (QPID-4560) C++ Broker Acl overpopulates decision data tables

[Chuck Rolke (JIRA)]

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

Chuck Rolke resolved QPID-4560.
---

Resolution: Duplicate

See https://issues.apache.org/jira/browse/QPID-4123

> C++ Broker Acl overpopulates decision data tables
> -
>
> Key: QPID-4560
> URL: https://issues.apache.org/jira/browse/QPID-4560
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: 0.21
> Environment: All C++ brokers
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>Priority: Minor
>
> The primary run-time decision structure for Acl processing contains rule 
> lists indexed by [object][action]. There are five objects and nine actions 
> resulting in 45 rule list roots. In actual practice, however, the broker has 
> code only to call 14 of these. 
> For instance, the broker will never call for authorisation of [link][bind] or 
> [method][purge].
> Normal Acl writers would not specify rules to fill these rule list roots but 
> they are populated when rules using the "all" keyword are processed.
> There is already validation map code that identifies active intersections in 
> the rule list but that code is unused. A relatively easy modification to the 
> Acl module would be to consult the validation map before loading decision 
> data and only proceed to install rules that may actually be called by the 
> broker.
> On small scale Acl rule sets this is not an issue or at least no one has 
> complained about it yet. Anticipating larger installations this proposed 
> change would help.

--
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-4054) C++ Broker connection limits require better granularity

[Chuck Rolke (JIRA)]

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

Chuck Rolke resolved QPID-4054.
---

   Resolution: Fixed
Fix Version/s: 0.21

Fixed by r1444302

> C++ Broker connection limits require better granularity
> ---
>
> Key: QPID-4054
> URL: https://issues.apache.org/jira/browse/QPID-4054
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Broker
>Affects Versions: 0.16
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
> Fix For: 0.21
>
>
> A single command line switch sets the connection limit value for all users. 
> Typical customers require different limits for different users. This issue 
> tracks moving the user limit specification to the ACL file.

--
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: 0.22 release update - alpha approaches

[Robbie Gemmell]

Hi Justin,

I'd like to suggest pushing the 0.22 release process back a little bit,
given the actual 0.20 release date was only 3 weeks ago.

We delayed cutting the 0.20 branch by 3 weeks due to concentrated work on
Proton prior to ApacheCon EU, and with the holidays falling since then its
not that clear to me how much compelling new work really exists on trunk at
this point. I can't speak to the C++ etc components, but with the Java
pieces for example the vast majority of commits done between the branch
creation and the final 0.20 RC were merged into the release, so there is
currently little there of note.

I'll admit to also being after a bit more time to work on some things for
the Java broker which we would like to get into the release. We have some
sizable cofiguration related changes on a branch that we intend to merge to
trunk before the Alpha, and will then be looking to add various related
management functionality which is likely to take us past the point the
release branch would currently be created. Given the close proximity of the
last release, it seems like allowing a bit more time for the next release
would be good, and preferable to the overhead of us requesting significant
numbers of merges later on.

What do you (or anyone else for that matter) think?

Robbie

On 11 February 2013 13:29, Justin Ross  wrote:

> Hi, everyone.
>
> Alpha is scheduled for this week.  I'm sorry I didn't get a warning
> about dates out earlier.  I'll target later in the week so we have a
> little more time to get major improvements landed.
>
> See the release page (linked below) for more information about the
> content of our alpha and beta distributions.
>
> Thanks,
> Justin
>
> ---
> 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-4575) Support Visual Studio 2012

[Chuck Rolke (JIRA)]

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

Chuck Rolke commented on QPID-4575:
---

How I built Boost 1.53 (from my log book)

=
1. Set up a path with executables on it (or not).
=
> showpath

current PATH environment

C:\Program Files (x86)\AMD APP\bin\x86_64
C:\Program Files (x86)\AMD APP\bin\x86
C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common
C:\Program Files\Common Files\Microsoft Shared\Windows Live
C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\Windows\System32\WindowsPowerShell\v1.0\
c:\Program Files\WIDCOMM\Bluetooth Software\
c:\Program Files\WIDCOMM\Bluetooth Software\syswow64
C:\Program Files (x86)\Common Files\HP\Digital Imaging\bin
C:\Program Files (x86)\HP\Digital Imaging\bin\
C:\Program Files (x86)\HP\Digital Imaging\bin\Qt\Qt 4.3.3
C:\Program Files (x86)\Windows Live\Shared
c:\Program Files (x86)\Microsoft SQL Server\90\Tools\binn\
C:\Program Files (x86)\WinSCP\
C:\Program Files (x86)\doxygen\bin
C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static
C:\Program Files\TortoiseSVN\bin
C:\Program Files\Microsoft\Web Platform Installer\
C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET Web Pages\v1.0\
C:\Program Files (x86)\Windows Kits\8.0\Windows Performance Toolkit\
C:\Program Files\Microsoft SQL Server\110\Tools\Binn\
C:\Ruby192\bin
c:\sw\bin
c:\cygwin\bin
C:\Program Files (x86)\CMake 2.8\bin
C:\Program Files (x86)\Python27
c:\program files\7-zip

=
2. Set up a directory and check out the source
=

Using directory: 
  S:\Users\boost-1_53\Source-built\svn>

TortoiseSVN checkout 
  http://svn.boost.org/svn/boost/tags/release/Boost_1_53_0

=
3. Execute the build script
=
see attachment build-boost-vs2012.bat


> Support Visual Studio 2012
> --
>
> Key: QPID-4575
> URL: https://issues.apache.org/jira/browse/QPID-4575
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: 0.20, 0.21
> Environment: visual studio 2012
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
> Attachments: build-boost-vs2012.bat
>
>
> Building under VS2012 requires the whole ecosystem of
> * qpid code
> * boost
> * cmake
> to be on the same page. This issue chronicles the journey.

--
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] [Updated] (QPID-4575) Support Visual Studio 2012

[Chuck Rolke (JIRA)]

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

Chuck Rolke updated QPID-4575:
--

Attachment: build-boost-vs2012.bat

> Support Visual Studio 2012
> --
>
> Key: QPID-4575
> URL: https://issues.apache.org/jira/browse/QPID-4575
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: 0.20, 0.21
> Environment: visual studio 2012
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
> Attachments: build-boost-vs2012.bat
>
>
> Building under VS2012 requires the whole ecosystem of
> * qpid code
> * boost
> * cmake
> to be on the same page. This issue chronicles the journey.

--
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-4581) Perl message content should be automatically encoded and decoded.

[Darryl L. Pierce (JIRA)]

Darryl L. Pierce created QPID-4581:
--

 Summary: Perl message content should be automatically encoded and 
decoded.
 Key: QPID-4581
 URL: https://issues.apache.org/jira/browse/QPID-4581
 Project: Qpid
  Issue Type: Improvement
  Components: Perl Client
Reporter: Darryl L. Pierce
Assignee: Darryl L. Pierce


When setting or getting the content for a message, Perl should automatically 
handle encoding and decoding the content.

--
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-215: Add tests to verify AMQP type support for python bindings.

[Rafael Schloming]

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



/proton/trunk/proton-c/bindings/python/proton.py


I don't recall offhand if this notation works on python 2.4. If you haven't 
already, we should probably check just to be sure.



/proton/trunk/tests/python/proton_tests/interop.py


I'm thinking we should actually check the data files into svn and load them 
from disk rather than generate them on the fly. I think this would be good for 
two reasons (1) the unit tests in other languages wouldn't need to depend on 
python, and (2) we would also catch compensating bugs, e.g. if I generate the 
test data on the fly all the time then I could introduce an encode bug along 
with a compensating decode bug and the tests wouldn't catch it, whereas if we 
check the files in, then we can verify that the current decode will work 
properly against historic versions of the encode as well.



/proton/trunk/tests/python/proton_tests/interop.py


I'm wondering if we shouldn't just add methods to the Message class to 
directly encode/decode to/from binary data. This seems like it might be 
convenient here and its also plausible that end users would find it useful. It 
would also let us check interop on a few small aspects of the message 
encode/decode that might not be covered by just checking through the data 
interface here.



/proton/trunk/tests/python/proton_tests/interop_gen.py


I'm wondering if we'll want to define a format such that we can add 
multiple values to check edge cases, e.g. binary with nulls in it, or a string 
with unicode characters, empty binary, string, and symbol values, etc.

I'm not sure offhand what the best way to deal with that would be. I guess 
in some ways we'd need to update all the unit tests anyways in order to add to 
an extra assertion, so there might not be all that much point to a generic 
format.

Either way I'd suggest starting out with as many edge cases as we can think 
of so when we port the python unit tests you have to other languages we get the 
additional coverage. Edgecases are a pretty common place where subtle mapping 
issues creep in. It's easy to confuse binary, string, and symbol and map them 
all into the same thing if you don't have sample values that exercise their 
differences.


- Rafael Schloming


On Feb. 12, 2013, 5:40 p.m., Alan Conway wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/9413/
> ---
> 
> (Updated Feb. 12, 2013, 5:40 p.m.)
> 
> 
> Review request for qpid, Kenneth Giusti and Rafael Schloming.
> 
> 
> Description
> ---
> 
> PROTON-215: Add tests to verify AMQP type support for python bindings.
> 
> The test consists of
> - a generator program that generates AMQP fragments for all AMQP types
> - a set of unit tests to decode, verify and re-encode the fragments.
> 
> This will be extended intended to cover all the proton language bindings.  
> All bindings
> will re-use the generator, unit tests will be added for each language.
> 
> 
> Diffs
> -
> 
>   /proton/trunk/proton-c/bindings/python/proton.py 1443924 
>   /proton/trunk/tests/python/proton_tests/__init__.py 1443924 
>   /proton/trunk/tests/python/proton_tests/interop.py PRE-CREATION 
>   /proton/trunk/tests/python/proton_tests/interop_gen.py PRE-CREATION 
> 
> 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
> 
>