Yes the tick function is used solely for heartbeat processing. Each peer
sets or declines to set its own heartbeat interval independently.
If you never call the tick function, you fail to send empty heartbeat
frames in time to the peer if required. You also fail to enforce the
presence of inbound
Hi Andrew,
It looks like your crash is in pni_process_tpwork which processes a linked
list of deliveries that have been modified and require wire (AMQP protocol)
frames sent to the peer to keep both sides of the connection in sync.
The actual call is made via a function pointer, which I don't
Hi Tom,
As a further note to whatever you have found so far...
The recommended route would be for you to retain your existing code
based on proton::container, and allow it to run with its own dedicated
thread (or threads) using its own epoll loop and let Proton manage the
sockets for the AMQP
There is some work starting to simplify platform dependencies in the
Proton C code base starting with switching to OpenSSL as the TLS
provider on Windows away from the native Schannel implementation.
The reason for this work starting now is twofold. First, the adoption
and support for open
+1
Built and tested on Windows VS 2022
Fedora 37 clang build and test
Fedora 37 gcc build and test + quiver soak test
Cliff
On Wed, May 31, 2023 at 4:59 AM Robbie Gemmell
wrote:
> Hi folks,
>
> I have put together a first spin for a Qpid Proton 0.39.0 release,
> please give it a test out
+1
Built the source and ran the tests without any failures on RHEL8.
On Mon, Dec 5, 2022 at 1:50 PM Timothy Bish wrote:
> Hi folks,
>
> I have put together a release candidate for a 1.0.0-M7 Qpid
> proton-dotnet release,
> please give it a test out and vote accordingly.
>
> The source and
+1
Downloaded the M2 source tar and checked the sha512sum
Built an alpine based image using docker/Dockerfile
Ran the image and executed “bash ./docker/run-tests.sh” on the extracted M2
source archive.
All tests passed.
Cliff
On Mon, Jul 11, 2022 at 12:13 PM Timothy Bish wrote:
> Hi
it is worth trying again with the current backlog
> setting?
>
>
> On Thu, Jun 2, 2022 at 5:11 PM Cliff Jansen wrote:
>
> > Please try raising your fd limit too. Perhaps doubling it or more.
> >
> > I would also try running your proton::container with more th
Please try raising your fd limit too. Perhaps doubling it or more.
I would also try running your proton::container with more threads, say 4
and then 16, and see if that makes a difference. It shouldn’t if your
processing within Proton is as minimal as you describe. However, if there
is lengthy
I can reproduce the problem seen by Roddie with Python 3.10.2 on Fedora 35.
It fails in the same way with 0.36.0, so it is not a regression.
If I increase the sleep time in the fdlimit.py driver program, the failure
goes away. In my opinion, this is a flaky test that Python 3.10 triggers
more
+1
Built and tested with new TLS library.
Did basic soak test with Quiver and Qpid Dispatch 1.19 RC2: high message
throughput alternating with 250 simultaneous connections.
On Tue, Mar 15, 2022 at 10:34 AM Robbie Gemmell
wrote:
> Hi folks,
>
> I have put together another spin for a Qpid
+1
Built and ran tests, including the new TLS library and associated example.
Ran some quiver soak tests against the Dispatch router, including 1, 3, and
125 arrow pairs.
On Thu, Feb 24, 2022 at 8:17 AM Robbie Gemmell
wrote:
> Hi folks,
>
> I have put together a first spin for a Qpid Proton
I can reproduce. I also get failures for Proton 0.36 on the same system.
In my opinion it is not a regression and not a reason to fail this RC.
I will raise a Jira to get this resolved for the next release.
On Mon, Feb 28, 2022 at 10:29 AM Ken Giusti wrote:
> +- "?"
>
> Just want to rule
This is a brief introduction to a proposed new Proton-C support library to
provide generalized TLS functionality.
The existing Proton SSL/TLS functionality is tightly coupled to AMQP
connections and does not provide application access to the encrypted or
decrypted stream data. As a result, there
Hi Glen,
I believe you are mixing old and new methodologies.
NSS and certutil are unrelated to the Qpid Proton C++ library which uses
OpenSSL on Posix systems. The environment variables QPID_SSL_CERT_XXX are
not used for TLS configuration.
See the example at
+1
Built and ran tests on Centos 8 and Fedora 34.
Ran 4 hour Quiver soak against Qpid Dispatch (4 arrow pairs) all built with
this release candidate. Fedora 34.
Cliff
On Mon, Nov 1, 2021 at 6:13 AM Robbie Gemmell
wrote:
> Hi folks,
>
> I have put together a first spin for a Qpid Proton
>
> P.S.: I’m off for holiday’s from tomorrow. Could you reply to all in CC
> when reacting to this mail?
>
>
>
> Thanks again!
>
>
>
> With kind regards,
>
>
>
> *Jaap Wiggelinkhuizen*
>
>
>
> *Van:* Cliff Jansen
> *Verzonden:* vrijdag 16
This is not a known bug. Despite your providing a helpful detailed account,
I am unable to see the possibility of a second “earlier” deadline in the
life of an AMQP connection. Even being off by one.
Please raise a JIRA including any additional information you can think of.
Obviously a
+1
Ran some quiver soak tests with the C based arrow driver in various
configurations on a 24 core /48 thread system (CentOS 7.9):
- peer-to-peer
- qpid-dispatch and 3 high throughput arrow pairs
- qpid-dispatch and 125 “credit 1” low throughput pairs
On Fri, Jun 25, 2021 at 7:56 AM
+1
Various Quiver and connexorciser soak/performance tests with C test broker
and Qpid Dispatch.
Build and ctest checkout on centos6 (last time?), centos7, fedora32.
On Tue, Nov 17, 2020 at 4:33 AM Robbie Gemmell
wrote:
> Hi folks,
>
> I have put together another spin for a Qpid Proton
-1 see PROTON-2304.
Yes, a hang in my own main contribution to this release. I was minutes
away from a +1 when this showed up. Fix looking likely by end of my working
day.
On Mon, Nov 16, 2020 at 7:21 AM Robbie Gemmell
wrote:
> Hi folks,
>
> I have put together another spin for a Qpid Proton
There is nothing wrong with your current strategy. You could
alternatively create a new connection on the same proactor instance.
You can also reuse a connection with a new transport, for example by
calling pn_proactor_release_connection() when you get the
PN_TRANSPORT_CLOSED event and before
+1
- I ran an overnight soak test compiled with “Debug” to expose asserts
- I ran dispatch with clang and thread sanitizer
Orange you glad I didn’t say banana?
On Thu, May 7, 2020 at 9:06 AM Robbie Gemmell
wrote:
> Hi folks,
>
> I have put together a third spin for a Qpid Proton 0.31.0
-1
Party pooper again.
I have a hang on a soak test. Inconclusive debugging so far. Best guess is
connections are not cleaning up on some condition and file descriptors are
leaking, preventing any new accepts. Still looking.
On Fri, May 1, 2020 at 9:41 AM Robbie Gemmell
wrote:
> Hi folks,
>
>
-1
See PROTON-2203.
On Tue, Apr 28, 2020 at 6:42 AM Robbie Gemmell
wrote:
> On Tue, 28 Apr 2020 at 13:01, Robbie Gemmell
> wrote:
> >
> > Hi folks,
> >
> > I have put together a spin for a Qpid Proton 0.31.0 release, please
> > give it a test out and vote accordingly.
> >
> > The files can be
ace it instead by a
> connection.work_queue().add() everything comes back to normal.
>
> I tried to think about what might be the source of the problem but i can't
> find any ideas yet...
>
> Best regards,
> Rabih
>
>
>
> On Fri, Apr 26, 2019 at 9:38 AM Cliff Janse
on the ref counting.
> This is why we proposed the atomic types in C11.
>
> Best regards.
> Jeremy and Rabih
>
>
> On Tue, Apr 23, 2019 at 9:28 AM Cliff Jansen wrote:
>>
>> I am of the same opinion as Gordon that fixing the counting (to be atomic)
>> will only ad
I am of the same opinion as Gordon that fixing the counting (to be atomic)
will only address the current symptom without preventing other races that
will present themselves later or on other hardware architectures.
Having two threads participating in Proton object reference counting is
I can reproduce and it looks more like a proactor problem than the C++
container.stop().
I will investigate further and create an appropriate JIRA. Thank you
for the simple test case.
Cliff
On Wed, Apr 3, 2019 at 4:17 AM Rabih M wrote:
>
> Hello,
>
> Concerning this point, i still have the
Hi Jeremy,
Thank you for your testing and report.
I am not seeing these errors on a variety of systems. Would you please tell me
- Your OS
- Compiler of choice
- cmake build arguments
??
Also, can you confirm whether you see similar or no errors from the
0.26.0 release?
Many thanks.
Have you tried the libuv proactor implementation for Proton-C? See
qpid-proton/c/CMakeLists.txt.
The current release of libuv claims to be fully supported on "Linux >=
2.6.32 with glibc >= 2.12".
If libuv works for you, that might be the easiest solution.
On Thu, Sep 6, 2018 at 4:26 AM,
electing the libuv proactor does not "unlock other functionalities in
proton". They all provide the same feature set.
Its purpose is indeed to increase the range of supported operating systems.
On platforms that have custom proactor implementations, i.e epoll on
Linux and iocp on Windows, the
This should work on Windows too.
Could you please raise a JIRA? Thanks.
Cliff
On 4/12/17, Rabih M wrote:
> Hello,
>
> I noticed that windows does not take into consideration the configured
> connection idle_timeout if it is less than 1 second. Linux does not have
>
Yes, this is being actively worked. Please see the latest comment in
PROTON-1340 and the intended Windows proacter implementation. The C++
injector should work the same on all platforms in that case.
On Tuesday, 8 November 2016, Adel Boutros wrote:
> Hello guys,
>
> Is
Thank-you for the helpful stack trace.
The Windows pn_selector_t and pn_io_t objects are intertwined but are
completely separate on Posix systems where the order of teardown is
unimportant. It looks to me as if the selector is free'd too early by
both the reactor and messenger. The window of
The reason for the definition is that it works in tandem with the gcc
compiler directive "-fvisibility=hidden" to stop exporting symbols that are
not part of the actual API. This second piece of the puzzle is provided in
the CMakeLists.txt files.
Using empty macros as you suggest should "work",
I also cannot read much of the email content unless I separately visit
the nabble version.
I believe Gordon is right: only PLAIN and ANONYMOUS are supported SASL
mechanisms on Windows at this time. See
src/qpid/broker/windows/SaslAuthenticator.cpp
Cliff
On Tue, Aug 16, 2016 at 7:49 AM,
Hi Jeff,
Further to Jakub's excellent reply...
If both sides are authenticating each other, each side must provide an
appropriate certificate (with private key), and use a separate
database/collection of root certificates (usually without private key
info) to verify the peer's certificate.
That
PROTON-1243 looks good to me for inclusion.
Cliff
On Wednesday, 3 August 2016, Andrew Stitcher wrote:
> These fixes missed the beta cut-off by a few hours!
>
> PROTON-1272: This is a trivial fix that allows build tests to run
> correctly on more systems (RHEL 6 in
Service bus authenticates to the link ("entity"), so it is perfectly normal
to have connection and session operations succeed with bogus credentials
followed by a link attach failure.
However, I can't say that you actually have an authentication issue since
you have success with at least one of
Hi Justin,
I would like to request the changes to schannel.c in PROTON-1228 and
PROTON-1233 be made available for 0.13.1. These are small and make
the Windows behavior match the Posix behavior. Andrew has reviewed
the changes.
Thanks.
Cliff
On Mon, Jun 27, 2016 at 5:31 PM, Justin Ross
Hi Justin,
I would like to request for inclusion in 0.13 the fix in PROTON-1226
for honoring a handler specifier for inbound connections from a
listener.
While not the most common use case it is a regression and causes the
flow_control example to fail.
Alan has reviewed the patch and approved
https://issues.apache.org/jira/browse/PROTON-1211
I would propose including this fix in 0.13. I marked the bug a
blocker since it can prevent messages being sent. It has been
reviewed by Alan.
Cliff
-
To unsubscribe, e-mail:
Thank-you for the additional information.
It appears that you successfully create an SSL encrypted TCP
connection acceptable to each peer. So SSL configuration seems fine.
It further appears that the service bus refuses to create a link to
your topic based on an unauthorized access attempt,
Hi Alex,
You may be running into https://issues.apache.org/jira/browse/QPID-6966.
There is a prospective patch: https://reviews.apache.org/r/41800
Also note that the qpid cpp client uses NSS libraries for TLS/SSL, not OpenSSL.
Regards,
Cliff
On Tue, Dec 29, 2015 at 5:21 AM, Oleksandr Rudyy
I'm not sure if this exactly fits your question (especially the
multi-threaded part), but the python tornado loop examples run a
regular reactor set of events and collectors but driven by the
external loop.
pn_iohandler is replaced with the TornadoLoophandler which knows how
to insert Proton io
hough about it before, but it sounds like an elegant
>> solution. The problem is that using custom CA and sign the certificates for
>> few hundred customers is often quite painful. On the other hand, the self
>> signed certificates also cause trouble here and there, so maybe it is
The certDb (proton:
pn_ssl_domain_t::pn_ssl_domain_trusted_certificate_db) is the
database/collection/store of CA certificates which are used to
validate the authenticity of the peer's certificate (client or
server). For self signed certificates, at least the public portion of
the certificate
+1 same build and tests as for beta
On Thu, Jun 25, 2015 at 4:42 AM, Robbie Gemmell
robbie.gemm...@gmail.com wrote:
Hi folks,
I have put together a RC for the Qpid CPP 0.34 release. The RC was produced
using r1687472 of the cpp dir from the qpid-cpp-0.34-rc branch.
You can find the files
This builds and runs for me on Windows 7, VS2008, Proton 9.1.
One client certificate test failed for me, until I corrected the
test to use the username along with the external mechanism (as is now
the correct way with QPID-6511).
Ship it!
On Wed, Jun 24, 2015 at 1:24 PM, Chuck Rolke
Hi Nelson,
The spout.cpp and drain.cpp messaging examples in
cpp/examples/messaging
work fine for me without hanging on Windows (using either AMQP1.0 or
AMQP0-10 protocols) when talking to a Linux C++ broker. (Windows 7,
VS2008).
Can you confirm those run for you without hanging? If those
Windows now works with ctest for 0.8. Yay!
The rc1 version of qpid-proton-0.8.tar.gz works for me (build and ctest) on:
XP32bit compile python27 cmake28 VS2010 server VM
WIN7 32bit compile python25 cmake28 vs2008 laptop
WIN8 64bit compile python27 cmake30 vs2013 server
Hi Justin,
I would like to request inclusion of QPID-5669 and QPID-5694 in Qpid
0.28. Reviews are https://reviews.apache.org/r/20122/ and
https://reviews.apache.org/r/20319/ respectively.
The former fixes a frequent bug seen on shutting down AMQP 1.0 client
connections on Windows. The latter
AM, Cliff Jansen cliffjan...@gmail.com wrote:
An HA fix appears to have broken basic C++ client ssl connections over
AMQP1.0 (Linux and Windows). See QPID-5648.
Cliff
On Fri, Mar 21, 2014 at 8:45 AM, Justin Ross jr...@apache.org wrote:
Hi, everyone. We have branched for release and the beta
An HA fix appears to have broken basic C++ client ssl connections over
AMQP1.0 (Linux and Windows). See QPID-5648.
Cliff
On Fri, Mar 21, 2014 at 8:45 AM, Justin Ross jr...@apache.org wrote:
Hi, everyone. We have branched for release and the beta distribution is
available for testing. As a
Hi Jeremy,
I don't have exact experience to help you but your plan seems doable.
The SWIG documentation for Perl on Windows doesn't list any obvious
limitations that look like they will get in your way. I'm pretty sure
any lack of development libs would have been noted there.
In your shoes, I
Albert,
Please try the recent fix to the JIRA (r1539474). This should get you
going for the 0-10 protocol.
Cliff
On Wed, Nov 6, 2013 at 10:20 AM, Albert Pomortsev apomo...@opentext.com wrote:
Chuck,
I created https://issues.apache.org/jira/browse/QPID-5302
Thanks,
Albert.
-Original
Hi Albert,
SSL support is not yet available for Windows in proton-c, which is
what the .NET messaging API will use for AMQP 1.0 functionality. The
work has started in earnest and is hoped to be available on trunk soon
after Proton 0.6 and Qpid 0.26 are released.
I will update the documentation
The default varies from machine to machine and if N is the number of
CPU threads that the operating system has available to it, the default
is N+1. This should get you close to the sweet spot, but as in all
things performance related, your specific use case may benefit from
more or fewer threads.
Hi Marcello,
Supplementing Jakub's reply, the source for the
Org.Apache.Qpid.Messaging dll is written in C++/CLI (not C#). You can
find it in the C++ Multiple component package or the full C++ source
release. It will be in:
qpidXX/cpp/bindings/qpid/dotnet/src
It is probably safer using the
If the C# is 64 bit (or cpu-any and launched as 64 bit) it will pull
in the 64bit CLR which cannot be mixed with the 32 bit version. You
can force your C# to be 32 bit from some setting in Visual Studio.
You can also set a property on the dll after the fact with some tool
from the SDK.
Cliff
On
+1 for (a)
On Tue, Aug 7, 2012 at 11:11 AM, Gordon Sim g...@redhat.com wrote:
So, to follow up and summarise this thread so far, the only contentious
point has been the loss of the 'flow to disk' functionality.
Though the current solution doesn't limit the memory used by a large queue,
it
Are you running windows 64 bit? Did you build any of the C++ or WCF
components as 32bit assemblies? The error you are seeing often results
from mixing assembly types.
If you built your final exe as Any CPU, it will start out as 64 bit
by default and fail when loading any of the 32 bit
Hi Robert,
I regularly build the WCF channel using VS2008, but haven't from trunk
since 0.16. CMake doesn't understand C# and C++/CLI, so the
projects/solutions aren't particularly flexible. Be sure to choose
the correct Debug/Release + Win32/x64 options to match your CMake
choices.
- What
Hi Todd,
Chuck was referring to the .NET binding. There are two separate .NET
offerings in Qpid:
- The Qpid WCF client
(//http://qpid.apache.org/books/0.14/Programming-In-Apache-Qpid/html/ch04.html)
- The .NET Binding for the C++ Messaging Client
Hi Hamid,
If I were in your position, I would not try to debug two pieces of
complex code at the same time.
I would recommend first trying to get the Windows ssl/tls calls
working in a simple C program, completely separated from Qpid code.
When that is working with your server and client
Hi Hamid,
What happens if you try to connect using Internet Explorer on your
Windows machine? Using the following in the address bar:
https://amqserver.rest.com:10170
where amqpserver.rest.com is the name of the server as it appears in
the certificate.
Usually if I have a certificate
Hi Hamid,
I am confused. It was explained to you in November that client side
certificates were not yet implemented in the Windows implementation.
Yet here it looks like your server will not negotiate the ssl
connection without a client certificate. Am I misunderstanding what
you are trying to
to
get it working?
Cliff Jansen mentioned a few weeks ago that he's working on the Solaris
port, so he may have addressed this. If he doesn't chime in here, you may
need to fix the poller. If you do, please raise a jira for each issue you
encounter, and attach patch(es) to the jira(s). Please
Has anyone tried to use the dotNet client on mono?
It was originally created using mono, so that should in fact be its
most robust runtime environment.
Unfortunately, the Qpid dotnet client that you are trying to use has
not been actively maintained for a long time
It is ported from the Java
I regret to report that the C# client you are using is not currently
being maintained within Qpid and has been identified as a candidate
for removal.
To paraphrase some recent emails, your best options for Qpid C#
development are as follows:
- The Qpid WCF client
On Tue, Dec 7, 2010 at 1:11 AM, Adam Kaminiecki ada...@dgt.com.pl wrote:
What a waste :/ can u tell what I need to download to use
- The .NET Binding for the C++ Messaging Client
because I dont understant it clearly what I have to do to use it i C#
Regards,
Adam
Here is a recent
Hi Adam,
I regret to report that the C# client you are using is not currently
being maintained within Qpid and has been identified as a candidate
for removal.
To paraphrase some recent emails, your best options for Qpid C#
development are as follows:
- The Qpid WCF client
Hi Adam,
Adding to Steve's comments, the WCF implementation in
qpid/0.6/qpid-dotnet-0-10-0.6.zip is a simple wrapper suitable for
Windows to Windows client use only and lacks the underpinning
architecture to do distraibuted transactions at all or local
trasactions outside the channel model
Hi Adam,
VS can't find the following attributes:
[ServiceContract], [OperationContract], [OperationBehavior]
and some classes like:
CustomBinding
Those should be in your .NET Framework, you need to be at least at
.NET Framework 3.5 SP1.
Should I just try and upgrade to VS2008?
I would
Hi Daniel,
This is not possible in 0.6. All queues/exchanges are expected to be
created and configured with the desired properties in advance, e.g. by using
qpid-tool.
In 0.7, there will be very limited support for the new messaging API's
addressing model, so that you can create temporary
Hi Ignacio,
If you are using durable messages, your test may be mainly measuring
the speed of the broker's message store on your hardware.
I have very little knowledge of the dotnet client, but using both the
qpid/wcf and qpid/cpp clients with a Linux broker give the following
numbers for 100
As an update: the build succeeds when this user switches to another Windows
machine (one not particularly different).
I will try to get additional info regarding the specific build problem and
report back.
Cliff
-Original Message-
From: lroloson [mailto:lrolo...@trmi.com]
Sent:
Hi Christophe,
Since you appear to be running on Windows, I would qualify Carl's response
by stating that the python tools work within cygwin. I am unable to get
them to work with the Windows version of python from python.org. I've
reported this as QPID-1641.
Cliff
-Original Message-
79 matches
Mail list logo