Re: Qpid 0.22 spec file for SL 6.2
On Wed, 2013-11-27 at 14:16 +, Bruno Matos wrote:
> Hi,
>
> I've changed the Qpid 0.22 spec file from FC18 to build RPMs for SL 6.2.
> If someone need, they are in attachment, and the contents are:
> * Final Qpid spec file for SL 6.2;
> * Diff from original spec file;
> * Patch to add -DNDEBUG to Gnu compiler.
I'd strongly recommend NOT patching the CMake system like this.
Instead in the spec file build using a Release or Release with Debug
Info setting.
So in the line you have
%cmake
use something like
%cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo
[This will also set different optimisation options from the default.
Although I find it a little puzzling the SL6.2s rpmbuild dosn't already
set a Release build type in the %cmake macro - I'm pretty sure that
Fedora's macro does this]
>
> The NDEBUG is needed because there is an assert in ACL plugin that kills
> the Broker when a route is created between brokers with ACL policies
> set. This may have been fixed in 0.24, at least I couldn't reproduce it
> with Qpid 0.24 FC19 packages.
>
> One problem that I know exists and I didn't solve has to do with
> dependencies. The package qpid-cpp-client depends on
> qpid-cpp-client-rdma and qpid-cpp-client-ssl because there are some
> files being added to qpid-cpp-client that I think they shouldn't:
> rdmaconnector.so and sslconnector.so. To solve this, however, it would
> be necessary to change the way the amqpc.so is included.
I don't understand this: the dependencies are the other way around -
qpid-cpp-client-rdma & qpid-cpp-client-ssl depend on
qpid-cpp-client.
The rdma and ssl subpackages just add those extra plugins to the client
library.
I think your problem is the %files line:
%{_libdir}/qpid/client/*
Since the only plugin included in the client package is amqpc.so this
could be just
%{_libdir}/qpid/client/amqpc.so
In any case any plugins shipped with qpid-cpp-client should be
individually enumerated in the files section because there are some
plugins that are not shipped in that package.
In fact I think this is simply a bug in the original spec file.
[In the 0.26 there is no separate amqpc or ssl module leaving only rdma
as a module so this will go away as an issue]
Andrew
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
RE: QPid 0.14 messaging times
This is a bit of a SWAG but you may be seeing effects of Nagle's algorithm. I believe the default for --tcp-nodelay changed to "on" sometime after your version. You may want to try that on both the client and broker side. -Steve > -Original Message- > From: Toralf Lund [mailto:toralf.l...@pgs.com] > Sent: Wednesday, November 27, 2013 9:26 AM > To: users@qpid.apache.org > Subject: QPid 0.14 messaging times > > Hi. > > I'm testing pretty standard (I think) request-response type setup for > communication between two processes, using QPid 0.14 (AMQP 0.10). > Messaging is implemented via a the C++ Messaging API, and the broker is > qpidd from qpid-cpp-server. All running under CentOS 6.4. Messages are > typically quite small - contents are often just 2-3 bytes, but there are > couple > of headers as well. > > Question: What sort of transfer times should I expect for my setup? When > testing with all processes on the same machine, and a broker used > exclusively for this purpose, I get a round-trip time of up to 80 ms, or > slightly > more, which is a bit longer than I expected. Furthermore, closer inspection > seems to reveal that I get either of the following 4 > scenarios: > > 1. (Worst case) The request message takes around 40 ms to reach the > "server", and the response 40 ms to get back to the client - for a > total time of around 80 ms. > 2. The request message takes around 40 ms, but the response is very > fast, perhaps the transfer time is 1 ms or so. So the total time is > 40 ms or so. > 3. As above, only the other way around (fast request, slower response.) 4. > The request and response are both very fast, giving nearly > instantaneous feedback. > > 2 and 3 are the most common of these. > > So, is this as expected, or should I expect faster transfers? Where might the > 40 ms come from? > > I suppose I should provide some code here, but it will take a while to > prepare, so I thought I might ask some general questions first... > > As for QPid version, I'm using 0.14 simply because it seems to be the most > recent available on standard software depositories for the system, but > upgrading to a more recent release may of course be an option. > > Thanks, > > > - Toralf > > > This e-mail, including any attachments and response string, may contain > proprietary information which is confidential and may be legally privileged. > It > is for the intended recipient only. If you are not the intended recipient or > transmission error has misdirected this e-mail, please notify the author by > return e-mail and delete this message and any attachment immediately. If > you are not the intended recipient you must not use, disclose, distribute, > forward, copy, print or rely on this e-mail in any way except as permitted by > the author. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
QPid 0.14 messaging times
Hi. I'm testing pretty standard (I think) request-response type setup for communication between two processes, using QPid 0.14 (AMQP 0.10). Messaging is implemented via a the C++ Messaging API, and the broker is qpidd from qpid-cpp-server. All running under CentOS 6.4. Messages are typically quite small - contents are often just 2-3 bytes, but there are couple of headers as well. Question: What sort of transfer times should I expect for my setup? When testing with all processes on the same machine, and a broker used exclusively for this purpose, I get a round-trip time of up to 80 ms, or slightly more, which is a bit longer than I expected. Furthermore, closer inspection seems to reveal that I get either of the following 4 scenarios: 1. (Worst case) The request message takes around 40 ms to reach the "server", and the response 40 ms to get back to the client - for a total time of around 80 ms. 2. The request message takes around 40 ms, but the response is very fast, perhaps the transfer time is 1 ms or so. So the total time is 40 ms or so. 3. As above, only the other way around (fast request, slower response.) 4. The request and response are both very fast, giving nearly instantaneous feedback. 2 and 3 are the most common of these. So, is this as expected, or should I expect faster transfers? Where might the 40 ms come from? I suppose I should provide some code here, but it will take a while to prepare, so I thought I might ask some general questions first... As for QPid version, I'm using 0.14 simply because it seems to be the most recent available on standard software depositories for the system, but upgrading to a more recent release may of course be an option. Thanks, - Toralf This e-mail, including any attachments and response string, may contain proprietary information which is confidential and may be legally privileged. It is for the intended recipient only. If you are not the intended recipient or transmission error has misdirected this e-mail, please notify the author by return e-mail and delete this message and any attachment immediately. If you are not the intended recipient you must not use, disclose, distribute, forward, copy, print or rely on this e-mail in any way except as permitted by the author.
Qpid 0.22 spec file for SL 6.2
Hi,
I've changed the Qpid 0.22 spec file from FC18 to build RPMs for SL 6.2.
If someone need, they are in attachment, and the contents are:
* Final Qpid spec file for SL 6.2;
* Diff from original spec file;
* Patch to add -DNDEBUG to Gnu compiler.
The NDEBUG is needed because there is an assert in ACL plugin that kills
the Broker when a route is created between brokers with ACL policies
set. This may have been fixed in 0.24, at least I couldn't reproduce it
with Qpid 0.24 FC19 packages.
One problem that I know exists and I didn't solve has to do with
dependencies. The package qpid-cpp-client depends on
qpid-cpp-client-rdma and qpid-cpp-client-ssl because there are some
files being added to qpid-cpp-client that I think they shouldn't:
rdmaconnector.so and sslconnector.so. To solve this, however, it would
be necessary to change the way the amqpc.so is included.
Tests and suggestions are welcome, I hope the spec file can be useful
for someone else.
Regards.
--
Bruno Matos
diff --git a/qpid-0.22/cpp/src/CMakeLists.txt b/qpid-0.22/cpp/src/CMakeLists.txt
index 2a3cfcf..37c0ab5 100644
--- a/qpid-0.22/cpp/src/CMakeLists.txt
+++ b/qpid-0.22/cpp/src/CMakeLists.txt
@@ -287,6 +287,8 @@ if (CMAKE_COMPILER_IS_GNUCXX)
else (GCC_VERSION VERSION_EQUAL 4.1.2)
set (HIDE_SYMBOL_FLAGS "-fvisibility=hidden")
endif (GCC_VERSION VERSION_EQUAL 4.1.2)
+
+ add_definitions("-DNDEBUG")
endif (CMAKE_COMPILER_IS_GNUCXX)
if (CMAKE_CXX_COMPILER_ID STREQUAL SunPro)
# qpid-cpp
%{!?python_sitelib: %global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")}
%{!?python_sitearch: %define python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")}
# The following macros are no longer used for installation but only for cleanup
%{!?ruby_sitelib: %global ruby_sitelib %(/usr/bin/ruby -rrbconfig -e 'puts Config::CONFIG["sitelibdir"] ')}
%{!?ruby_sitearch: %global ruby_sitearch %(/usr/bin/ruby -rrbconfig -e 'puts Config::CONFIG["sitearchdir"] ')}
# LIBRARY VERSIONS
%global QPIDCOMMON_VERSION_INFO 5:0:0
%global QPIDTYPES_VERSION_INFO 3:0:2
%global QPIDBROKER_VERSION_INFO 5:0:0
%global QPIDCLIENT_VERSION_INFO 5:0:0
%global QPIDMESSAGING_VERSION_INFO 4:0:1
%global QMF_VERSION_INFO4:0:0
%global QMF2_VERSION_INFO 1:0:0
%global QMFENGINE_VERSION_INFO 4:0:0
%global QMFCONSOLE_VERSION_INFO 5:0:0
%global RDMAWRAP_VERSION_INFO 5:0:0
%global SSLCOMMON_VERSION_INFO 5:0:0
# Single var with all lib version params (except store) for make
%global LIB_VERSION_MAKE_PARAMS QPIDCOMMON_VERSION_INFO=%{QPIDCOMMON_VERSION_INFO} QPIDBROKER_VERSION_INFO=%{QPIDBROKER_VERSION_INFO} QPIDCLIENT_VERSION_INFO=%{QPIDCLIENT_VERSION_INFO} QPIDMESSAGING_VERSION_INFO=%{QPIDMESSAGING_VERSION_INFO} QMF_VERSION_INFO=%{QMF_VERSION_INFO} QMFENGINE_VERSION_INFO=%{QMFENGINE_VERSION_INFO} QMFCONSOLE_VERSION_INFO=%{QMFCONSOLE_VERSION_INFO} RDMAWRAP_VERSION_INFO=%{RDMAWRAP_VERSION_INFO} SSLCOMMON_VERSION_INFO=%{SSLCOMMON_VERSION_INFO}
Name: qpid-cpp
Version: 0.22
Release: 3%{?dist}
Summary: Libraries for Qpid C++ client applications
License: ASL 2.0
URL: http://qpid.apache.org
Source0: http://www.apache.org/dist/qpid/%{version}/qpid-%{version}.tar.gz
BuildRequires: cmake
BuildRequires: boost-devel
BuildRequires: libtool
BuildRequires: doxygen
BuildRequires: pkgconfig
BuildRequires: ruby
BuildRequires: ruby-devel
BuildRequires: python
BuildRequires: python-devel
BuildRequires: perl
BuildRequires: perl-devel
BuildRequires: swig
BuildRequires: cyrus-sasl-devel
BuildRequires: cyrus-sasl-lib
BuildRequires: cyrus-sasl
BuildRequires: boost-program-options
BuildRequires: boost-filesystem
BuildRequires: libuuid-devel
%ifnarch s390 s390x %{arm}
BuildRequires: libibverbs-devel
BuildRequires: librdmacm-devel
%endif
BuildRequires: nss-devel
BuildRequires: nspr-devel
BuildRequires: xqilla-devel
BuildRequires: xerces-c-devel
BuildRequires: db4-devel
BuildRequires: db4-cxx
BuildRequires: libaio-devel
Patch2: 02-QPID-4826-Patch-Perl-bindings-memory-leak.patch
Patch3: 03-QPID-4843-Fixed-the-Perl-spout.pl-example.patch
Patch4: 04-QPID-4857-Fixed-passing-Perl-Message-to-C-code.patch
Patch5: 05-QPID-4885-C-examples-install-to-qpid-examples.patch
Patch6: 06-QPID-4889-Only-installs-the-Swig-descriptors-in-usr-.patch
Patch7: 07-QPID-4825-Add-SOVERSION-link-to-shared-libraries.patch
Patch8: 08-NO-JIRA-CXXFLAGS-NDEBUG.patch
%description
Run-time libraries for AMQP client applications developed using Qpid
C++. Clients exchange messages with an AMQP message broker using
the AMQP protocol.
%package -n qpid-cpp-client
Summary: Libraries for Qpid C++ client applications
Requires: boost
Requires: chkconfig
Requires: initscripts
%description -n qpid-cpp-client
Run
