Re: How to share fixed bugs with you?
On 05/09/14 02:33, Miguel da Rocha Correia Lima wrote: Hi Proton Subscribers, We are using proton qpid for some AMQP software architecture proof of concept. The objective is use proton as our standard AMQP message client to router, gateway and interface with user domain applications and AMQP brokers like qpid, rabitmq, zeromq, etc. While we worked with proton, we found bugs and we fixed they. How can we share they with you? Can we send a patch? Regards, Hi Miguel, The best approach is generally to raise a Jira. In an ideal world explaining the issue, preferably with a reproducer and ideally a patch. TBH plenty of people just raise Jiras giving the symptoms that they've seen, you sound like you've gone a lot further, which is great. For Proton the Jira link is: https://issues.apache.org/jira/browse/PROTON/ For Qpid (The Brokers, JMS, C++ messaging client etc.) the Jira link is: https://issues.apache.org/jira/browse/qpid TBH I personally always suggest opening up a conversation on the main qpid mailing list whether it's more general qpid or more specifically proton as there might be cross pollination of issues (proton is a sub-project of qpid and the qpid AMQP 1.0 support is via proton). HTH, Frase
[jira] [Created] (PROTON-660) Fix openssl.c build on windows
Bozo Dragojevic created PROTON-660: -- Summary: Fix openssl.c build on windows Key: PROTON-660 URL: https://issues.apache.org/jira/browse/PROTON-660 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Environment: Windows 7, VS2013 Reporter: Bozo Dragojevic Compiled openssl-1.0.1i from source Proton finds it, but openssl.c does not compile without small adjustments. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [jira] [Commented] (PROTON-640) IO completion port Windows IO for Proton
Hi Cliff,
On 4. 09. 14 20:03, Cliff Jansen wrote:
Hi,
I am not sure what you are trying to do with xdispatch.
Exactly the same idea as contrib/proton-hawtdispatch, but in C.
If you are
using and external loop and managing your own IO, you can bypass the
low level Proton IO primitives and access the proton engine directly.
This is how Qpid uses Proton.
I am using the engine directly.
I am also using io.[ch] as a *very* convenient multi platform socket
abstraction.
If you were using the driver.c mechanism, please take a look at
PROTON-658. This and the main messenger loop show how the
selectors/selectables can be used within Proton. pn_selector_select()
is pretty central to the completion port model on windows.
I'm not using the proton driver, I have my own driver and thread model.
All serialization of one engine instance is one serial libdispatch task
queue.
I'm also not using proton selectors but two libdispatch sources (read
and write)
that are bound to the same task queue.
All bits of my application that need to be talk to the engine then just
queue
tasks to the same libdispatch queue, so we have practically no locks in
the app.
You may find that if you use Windows accept and connect instead of
pn_accept and pn_connect you can keep your descriptors completely
outside the completion port model and use things as you did. If not,
perhaps we can find another way to isolate your sockets from the
completion port implementation.
I like io's eror thing, and the wouldblock thing, I'd hate to duplicate
all that
across the platforms.
Today I had a read through the iocp change.
I see it kept support for 'user supplied' sockets, where it behaves
synchronously, as before.
I can make iocp support be controlled by an opt-out parameter.
Then for example, pn_listen does not enroll the socket to iocp and
pn_accept
does not find it in the map and treat it as user supplied.
Patch attached, with it my code works again.
Would such a change be acceptable?
The patch is a bit rough
- not sure I really like the name pn_io_no_iocp()
- missing non-windows stub for pn_io_no_iocp()
- it most likely handles the selector access wrong (see XXX comment)
The Windows completion port implementation is designed to provide a
highly scalable throughput in a constrained (mostly) single thread
model, but remain lightweight for small clients. Central to that is
the integration with selectors and selectables. But it can't be
everything to everybody.
I did not want to say this is a bad thing! :) I just wanted to let you
guys know
there is a user of the library with slightly different use-case and to
figure out if
such use can be considered to be within scope of the things that proton
is trying to accomplish.
Cheers,
Bozzo
From 357bf8fa698e9a49170b5e53b9abb2a74007dbb2 Mon Sep 17 00:00:00 2001
From: Bozo Dragojevic bo...@digiverse.si
Date: Fri, 5 Sep 2014 11:40:57 +0200
Subject: [PATCH 1/1] Make iocp optional on windows
---
proton-c/include/proton/io.h | 1 +
proton-c/src/windows/io.c| 47 ++--
proton-c/src/windows/iocp.c | 8
proton-c/src/windows/iocp.h | 1 +
4 files changed, 47 insertions(+), 10 deletions(-)
diff --git a/proton-c/include/proton/io.h b/proton-c/include/proton/io.h
index 2d56736..3aac524 100644
--- a/proton-c/include/proton/io.h
+++ b/proton-c/include/proton/io.h
@@ -47,6 +47,7 @@ typedef struct pn_io_t pn_io_t;
typedef struct pn_selector_t pn_selector_t;
PN_EXTERN pn_io_t *pn_io(void);
+PN_EXTERN bool pn_io_no_iocp(pn_io_t *io);
PN_EXTERN void pn_io_free(pn_io_t *io);
PN_EXTERN pn_error_t *pn_io_error(pn_io_t *io);
PN_EXTERN pn_socket_t pn_connect(pn_io_t *io, const char *host, const char
*port);
diff --git a/proton-c/src/windows/io.c b/proton-c/src/windows/io.c
index b5660be..f9c85b4 100644
--- a/proton-c/src/windows/io.c
+++ b/proton-c/src/windows/io.c
@@ -92,7 +92,8 @@ void pn_io_finalize(void *obj)
{
pn_io_t *io = (pn_io_t *) obj;
pn_error_free(io-error);
- pn_free(io-iocp);
+ if (io-iocp != NULL)
+pn_free(io-iocp);
WSACleanup();
}
@@ -112,6 +113,20 @@ void pn_io_free(pn_io_t *io)
pn_free(io);
}
+bool pn_io_no_iocp(pn_io_t *io)
+{
+ if (io-iocp != NULL) {
+if (pni_iocpdesc_map_empty(io-iocp)) {
+ pn_free(io-iocp);
+ io-iocp = NULL;
+} else {
+ pn_error_format(io-error, PN_ERR, Cannot turn off iocp, already in
use);
+ return false;
+}
+ }
+ return true;
+}
+
pn_error_t *pn_io_error(pn_io_t *io)
{
assert(io);
@@ -210,14 +225,17 @@ pn_socket_t pn_listen(pn_io_t *io, const char *host,
const char *port)
return INVALID_SOCKET;
}
- iocpdesc_t *iocpd = pni_iocpdesc_create(io-iocp, sock, false);
- if (!iocpd) {
-pn_i_error_from_errno(io-error, register);
-closesocket(sock);
-return INVALID_SOCKET;
+ if (io-iocp != NULL) {
+iocpdesc_t *iocpd = pni_iocpdesc_create(io-iocp, sock, false);
+if (!iocpd) {
+
Re: [jira] [Commented] (PROTON-640) IO completion port Windows IO for Proton
On 5. 09. 14 11:53, Bozo Dragojevic wrote:
The patch is a bit rough
- not sure I really like the name pn_io_no_iocp()
- missing non-windows stub for pn_io_no_iocp()
- it most likely handles the selector access wrong (see XXX comment)
I missed this bit (blush)
diff --git a/proton-c/src/windows/io.c b/proton-c/src/windows/io.c
index f9c85b4..b5fc7b2 100644
--- a/proton-c/src/windows/io.c
+++ b/proton-c/src/windows/io.c
@@ -263,6 +263,14 @@ pn_socket_t pn_connect(pn_io_t *io, const char
*hostarg, const char *port)
if (io-iocp != NULL) {
sock = pni_iocp_begin_connect(io-iocp, sock, addr, io-error);
} else {
+if (connect(sock, addr-ai_addr, addr-ai_addrlen) != 0) {
+ if (WSAGetLastError() != WSAEWOULDBLOCK) {
+pni_win32_error(io-error, connect, WSAGetLastError());
+freeaddrinfo(addr);
+closesocket(sock);
+return INVALID_SOCKET;
+ }
+}
freeaddrinfo(addr);
}
return sock;
Bozzo
[jira] [Commented] (PROTON-651) Export the proton version numbers via the bindings.
[ https://issues.apache.org/jira/browse/PROTON-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14122835#comment-14122835 ] Darryl L. Pierce commented on PROTON-651: - I would suggest, for the Ruby bindings, to drop the PN_ prefix to the contants. Since they're defined in the Qpid::Proton namespace they shouldn't conflict with anything. Export the proton version numbers via the bindings. --- Key: PROTON-651 URL: https://issues.apache.org/jira/browse/PROTON-651 Project: Qpid Proton Issue Type: New Feature Components: perl-binding, python-binding, ruby-binding Affects Versions: 0.7 Reporter: Ken Giusti Assignee: Rafael H. Schloming Fix For: 0.8 Provide a way to access the proton version number (PN_VERSION_MAJOR and PN_VERSION_MINOR) via the bindings. This will allow applications determine which version of the Proton libraries are available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-651) Export the proton version numbers via the bindings.
[ https://issues.apache.org/jira/browse/PROTON-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14122863#comment-14122863 ] ASF subversion and git services commented on PROTON-651: Commit 1622689 from [~mcpierce] in branch 'proton/trunk' [ https://svn.apache.org/r1622689 ] PROTON-651: Export Proton major/minor version number in Perl. Export the proton version numbers via the bindings. --- Key: PROTON-651 URL: https://issues.apache.org/jira/browse/PROTON-651 Project: Qpid Proton Issue Type: New Feature Components: perl-binding, python-binding, ruby-binding Affects Versions: 0.7 Reporter: Ken Giusti Assignee: Rafael H. Schloming Fix For: 0.8 Provide a way to access the proton version number (PN_VERSION_MAJOR and PN_VERSION_MINOR) via the bindings. This will allow applications determine which version of the Proton libraries are available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-653) Expose the version and build details for Proton in the Perl bindings.
[ https://issues.apache.org/jira/browse/PROTON-653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce closed PROTON-653. --- Resolution: Fixed Fix Version/s: 0.8 Expose the version and build details for Proton in the Perl bindings. - Key: PROTON-653 URL: https://issues.apache.org/jira/browse/PROTON-653 Project: Qpid Proton Issue Type: Improvement Components: perl-binding Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce Fix For: 0.8 Expose the build details and version information from the underlying C code in the Perl bindings. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-582) Perl language bindings do not properly identify integers from strings when encoding
[
https://issues.apache.org/jira/browse/PROTON-582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14122862#comment-14122862
]
ASF subversion and git services commented on PROTON-582:
Commit 1622688 from [~mcpierce] in branch 'proton/trunk'
[ https://svn.apache.org/r1622688 ]
PROTON-582: Missing utils.pm module
The module was missed when the original code was submitted.
Perl language bindings do not properly identify integers from strings when
encoding
---
Key: PROTON-582
URL: https://issues.apache.org/jira/browse/PROTON-582
Project: Qpid Proton
Issue Type: Bug
Components: perl-binding
Affects Versions: 0.7
Reporter: Darryl L. Pierce
Assignee: Darryl L. Pierce
Fix For: 0.8
Rafi found the code:
sub isnum ($) {
return 0 if $_[0] eq '';
$_[0] ^ $_[0] ? 0 : 1
}
which can differentiate strings from integers. An additional piece can check
for a . in a numeric value to differentiate integers from floating point
values.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: proton performance: Release vs. RelWithDebInfo
On Thu, 2014-09-04 at 14:37 -0400, Michael Goulish wrote: A little confirmation -- in my testing of proton engine send/receive clients I just now tested the performance of those clients built against Proton Release version, versus Proton RelWithDebInfo version. I did indeed find that both versions were the same at running my tests, after averaging the speed of 5 tests with each version. In fact, RelWithDebInfo came in a mite faster -- a couple percent -- but probably still within the variability of the observations. For gcc: CMakeCache.txt:123:CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG CMakeCache.txt:126:CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG So the only differences are debug symbols (-g) and the extra optimizations in -O3: gcc -c -Q -O3 --help=optimizers /tmp/O3-opts; gcc -c -Q -O2 --help=optimizers /tmp/O2-opts; diff /tmp/O2-opts /tmp/O3-opts | grep enabled -fgcse-after-reload [enabled] -finline-functions [enabled] -fipa-cp-clone [enabled] -fpredictive-commoning [enabled] -ftree-loop-distribute-patterns [enabled] -ftree-partial-pre [enabled] -ftree-vectorize[enabled] -funswitch-loops[enabled] -fvect-cost-model [enabled] I'm not sure what any of those do except for -finline-functions which is self-explanatory.
Re: How to share fixed bugs with you?
Hi Frase, Thanks by your replay! We will open a issue on jira! Regards, Miguel da Rocha Correia Lima miguel at landix dot com dot br Em 05/09/2014 03:55, Fraser Adams escreveu: On 05/09/14 02:33, Miguel da Rocha Correia Lima wrote: Hi Proton Subscribers, We are using proton qpid for some AMQP software architecture proof of concept. The objective is use proton as our standard AMQP message client to router, gateway and interface with user domain applications and AMQP brokers like qpid, rabitmq, zeromq, etc. While we worked with proton, we found bugs and we fixed they. How can we share they with you? Can we send a patch? Regards, Hi Miguel, The best approach is generally to raise a Jira. In an ideal world explaining the issue, preferably with a reproducer and ideally a patch. TBH plenty of people just raise Jiras giving the symptoms that they've seen, you sound like you've gone a lot further, which is great. For Proton the Jira link is: https://issues.apache.org/jira/browse/PROTON/ For Qpid (The Brokers, JMS, C++ messaging client etc.) the Jira link is: https://issues.apache.org/jira/browse/qpid TBH I personally always suggest opening up a conversation on the main qpid mailing list whether it's more general qpid or more specifically proton as there might be cross pollination of issues (proton is a sub-project of qpid and the qpid AMQP 1.0 support is via proton). HTH, Frase
