[jira] [Created] (PROTON-801) Add option to specify filter/selector in the subscribe method of Messenger API
Jorge Maroto created PROTON-801: --- Summary: Add option to specify filter/selector in the subscribe method of Messenger API Key: PROTON-801 URL: https://issues.apache.org/jira/browse/PROTON-801 Project: Qpid Proton Issue Type: Improvement Components: python-binding Affects Versions: 0.8 Reporter: Jorge Maroto Priority: Minor It would be nice to have a way of specifying filter/selectors for subscriptions in the Messenger API instead of having to fallback to the Protocol Engine API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [java] Message codec improvements
Rafi, Do you have a JIRA for this work? Regards, Rajith On Wed, Jan 14, 2015 at 6:35 PM, Rajith Muditha Attapattu rajit...@gmail.com wrote: Rafi, I had a closer look at the code, put it on trunk and ran your benchmark. I see quite an improvement with respect to writing lists, maps and strings. Simply put the writeList and writeMap methods in the old encorder is about ~10 times slower than the new encorder. If I run with a sufficiently large set of strings, the old encorder is about ~2 times slower than the new encorder. I'm now focusing on hooking it up with the engine. Once that is done we can look at tweaking it further. But as it is, the new codec is a real improvement over the existing one. Great job Rafi! Rajith On Tue, Jan 6, 2015 at 10:28 AM, Rajith Muditha Attapattu rajit...@gmail.com wrote: Thanks Rafi, for the link. I agree that any work should use this as a basis. I plan to take a closer look at this in the next week or so. Rajith On Wed, Dec 17, 2014 at 1:24 PM, Rafael Schloming r...@alum.mit.edu wrote: A while back I implemented a relatively complete standalone codec here: https://github.com/rhs/qpid-proton-old/tree/codec/proton-j/src/main/java/org/apache/qpid/proton/codec2 It's quite a bit faster than the existing codec. I believe any new codec work should probably be based on this. It's relatively standalone, so should be easy to import into the tree, and then it's just a matter of modifying the rest of the engine to use it. Note that my qpid-proton-old repo is a clone of the pre-migration repo. --Rafael On Mon, Dec 15, 2014 at 2:17 PM, Rajith Muditha Attapattu rajit...@gmail.com wrote: I'm starting to look at improving this areas as I was told a few folks have noted some concerns. I would appreciate some input on these concerns and hope to have a discussion to figure out how best to proceed. Regards, Rajith
Re: [java] Message codec improvements
I don't believe there is an existing one. --Rafael On Thu, Jan 15, 2015 at 3:10 PM, Rajith Muditha Attapattu rajit...@gmail.com wrote: Rafi, Do you have a JIRA for this work? Regards, Rajith On Wed, Jan 14, 2015 at 6:35 PM, Rajith Muditha Attapattu rajit...@gmail.com wrote: Rafi, I had a closer look at the code, put it on trunk and ran your benchmark. I see quite an improvement with respect to writing lists, maps and strings. Simply put the writeList and writeMap methods in the old encorder is about ~10 times slower than the new encorder. If I run with a sufficiently large set of strings, the old encorder is about ~2 times slower than the new encorder. I'm now focusing on hooking it up with the engine. Once that is done we can look at tweaking it further. But as it is, the new codec is a real improvement over the existing one. Great job Rafi! Rajith On Tue, Jan 6, 2015 at 10:28 AM, Rajith Muditha Attapattu rajit...@gmail.com wrote: Thanks Rafi, for the link. I agree that any work should use this as a basis. I plan to take a closer look at this in the next week or so. Rajith On Wed, Dec 17, 2014 at 1:24 PM, Rafael Schloming r...@alum.mit.edu wrote: A while back I implemented a relatively complete standalone codec here: https://github.com/rhs/qpid-proton-old/tree/codec/proton-j/src/main/java/org/apache/qpid/proton/codec2 It's quite a bit faster than the existing codec. I believe any new codec work should probably be based on this. It's relatively standalone, so should be easy to import into the tree, and then it's just a matter of modifying the rest of the engine to use it. Note that my qpid-proton-old repo is a clone of the pre-migration repo. --Rafael On Mon, Dec 15, 2014 at 2:17 PM, Rajith Muditha Attapattu rajit...@gmail.com wrote: I'm starting to look at improving this areas as I was told a few folks have noted some concerns. I would appreciate some input on these concerns and hope to have a discussion to figure out how best to proceed. Regards, Rajith
Re: c reactor / gordon's examples
On 01/14/2015 01:28 PM, Rafael Schloming wrote: Hi Everyone, I've been doing some work on a C reactor API for proton that is intended to fit both alongside and underneath what gordon has been doing in pure python. I have several goals with this work. - Simplify/enable a reactive style of programming in C that is similar to what gordon has built out in pure python. - Provide a C API that translates well into the python/ruby/etc bindings, so that sophisticated handlers can be written once in C rather than being duplicated in each scripting language. - Preserve the extensibility/flexibility that comes with being able to define custom handlers in the bindings, so python/ruby/etc handlers can intermix well with C handlers. - Provide a C API that translates well into javascript via emscripten. In some ways this is similar to the above goals with the other language bindings, however I mention it separately because there are additional memory management constraints for javascript since it has no finalizers. I believe I've made significant progress towards most of these goals, although there is still plenty of work left to do. I'd like to share a few examples both to illustrate where I am with this and to solicit feedback and/or help. Let me say up front that these examples aren't intended to be hello world type examples. The focus of this work has really been on the reactor/handler/event-dispatch infrastructure, and so the example I've chosen is really intended to illustrate key aspects of how this works. To do that I've built an example that sets up a recurring task, a server, and a client, all within the same process and then sends a number of messages to itself. I've included the same example twice, once written in C and once written in the python binding of the C API. Please have a look and let me know what you think. Attached is that example using the pure python utilities I've been working on. It's similar in many ways, but there are some differences. Ideally we can start to reconcile these differences, particularly for the python bindings, both to avoid the confusion of having slightly different variants of the same functionality and to allow more flexible combining between c and python (e.g. calling c handlers from python, using the c event loop with python handlers etc). I think that exercise will also be a useful way of solidifying some of the interfaces. There are a couple of immediate improvements I want to make based on your example. The first is having the 'reactor' (I currently call the equivalent 'container') as a property of all events. That avoids the need to explicitly 'plumb it in' to components. The other is to add a handler argument to the schedule call allowing specific timed events to be handled by a given piece of logic. The second point also opens up the wider question of how handler scoping works. There are some differences there between our approaches that are worth digging into and rationalising. The first point impacts on a question I've been thinking about which is the correct layering (if any). I started to use the term 'container' for something that had some higher level utility as an AMQP container, over and above the 'event loop'. Figuring out what the layers are, what they should be called and what exactly their interfaces are will be worthwhile. Anyway, more to come on all this from me, but I wanted to chip in briefly. I think we are building some momentum around the approach here, the c variant is an interesting addition - nice work - and I think also an opportunity to start unifying and consolidating things. #!/usr/bin/env python # # Licensed to the Apache Software Foundation (ASF) under one # or more contributor license agreements. See the NOTICE file # distributed with this work for additional information # regarding copyright ownership. The ASF licenses this file # to you under the Apache License, Version 2.0 (the # License); you may not use this file except in compliance # with the License. You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, # software distributed under the License is distributed on an # AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY # KIND, either express or implied. See the License for the # specific language governing permissions and limitations # under the License. # from proton import Message from proton.handlers import MessagingHandler from proton.reactors import Container import sys import time class Printer(MessagingHandler): def __init__(self): super(Printer, self).__init__() self.count = 0 def on_message(self, event): self.count += 1 print RCVD[%s] % self.count, event.message class PeriodicThingy: def on_start(self, event): print scheduling, time.ctime(time.time()) self.container = event.container
Re: c reactor / gordon's examples
On 14/01/15 08:28 -0500, Rafael Schloming wrote: Hi Everyone, I've been doing some work on a C reactor API for proton that is intended to fit both alongside and underneath what gordon has been doing in pure python. I have several goals with this work. - Simplify/enable a reactive style of programming in C that is similar to what gordon has built out in pure python. - Provide a C API that translates well into the python/ruby/etc bindings, so that sophisticated handlers can be written once in C rather than being duplicated in each scripting language. - Preserve the extensibility/flexibility that comes with being able to define custom handlers in the bindings, so python/ruby/etc handlers can intermix well with C handlers. Is the goal to be able to use swig here? My question is based on the fact that swig is not as smart as it should be when it comes to managing references and memory on the python side. I believe some bugs were found in qpid-proton because of this and I've hit this same issue in other projects. When it comes to create python bindings for C code, I normally prefer to use cffi[0] which is more reliable, the code bloat is less and it gives you, in my opinion, more control over the C objects. Other than this, I'm happy to see this happening! Great work, Flavio [0] https://cffi.readthedocs.org/en/release-0.8/ - Provide a C API that translates well into javascript via emscripten. In some ways this is similar to the above goals with the other language bindings, however I mention it separately because there are additional memory management constraints for javascript since it has no finalizers. I believe I've made significant progress towards most of these goals, although there is still plenty of work left to do. I'd like to share a few examples both to illustrate where I am with this and to solicit feedback and/or help. Let me say up front that these examples aren't intended to be hello world type examples. The focus of this work has really been on the reactor/handler/ event-dispatch infrastructure, and so the example I've chosen is really intended to illustrate key aspects of how this works. To do that I've built an example that sets up a recurring task, a server, and a client, all within the same process and then sends a number of messages to itself. I've included the same example twice, once written in C and once written in the python binding of the C API. Please have a look and let me know what you think. -- @flaper87 Flavio Percoco pgpV_38SV6YcQ.pgp Description: PGP signature
[jira] [Commented] (PROTON-800) [Windows C] Reactor test times out
[
https://issues.apache.org/jira/browse/PROTON-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14278562#comment-14278562
]
Rafael H. Schloming commented on PROTON-800:
I believe there are two relevant cases to consider when answering your
question. If you assume you have a parent object (the pn_io_t) and a child
object (the pn_socket_t) we actually follow two different patterns depending on
the circumstances. In the case where the child object is a full fledged object,
e.g. the parent is a pn_connection_t and the child is a pn_session_t, we have
the parent keep a pointer to the child and keep it alive, so that the order of
decref of the parent relative to the child doesn't matter.
The second case to consider is when the child is not actually an independent
object, e.g. it might be a pn_handle_t rather than an actual pointer. (We use
this pattern in the map API for example.) In these cases the life of the child
is scoped to the parent and the order of decref is important.
In your case I think we have to assume the latter unless we turn pn_socket_t
into a full-on pointer rather than just an alias for a file descriptor. I think
this is fine so long as we are clear about the semantics.
[Windows C] Reactor test times out
--
Key: PROTON-800
URL: https://issues.apache.org/jira/browse/PROTON-800
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.8
Environment: Windows Server 2012 R2, Visual Studio 2010 x64
Reporter: Chuck Rolke
ctest -VV times out on the reactor test.
Instrumenting and debugging shows the failure in test_reactor_acceptor
Running Debug instead of RelWithDebInfo crashes with an AccVio
{noformat}
qpid-protond.dll!pni_iocpdesc_map_get(iocp_t * iocp, unsigned __int64
s) Line 773 + 0xa bytes C++
qpid-protond.dll!pn_close(pn_io_t * io, unsigned __int64 socket) Line
350 + 0x16 bytes C++
qpid-protond.dll!pni_acceptor_finalize(pn_selectable_t * sel) Line 56
C++
qpid-protond.dll!pn_selectable_finalize(void * obj) Line 81C++
qpid-protond.dll!pn_class_decref(const pn_class_t * clazz, void *
object) Line 100 C++
qpid-protond.dll!pn_list_finalize(void * object) Line 205 C++
qpid-protond.dll!pn_class_decref(const pn_class_t * clazz, void *
object) Line 100 C++
qpid-protond.dll!pn_decref(void * object) Line 253 C++
qpid-protond.dll!pn_reactor_finalize(pn_reactor_t * reactor) Line 77
C++
qpid-protond.dll!pn_reactor_finalize_cast(void * object) Line 113 +
0x28 bytes C++
qpid-protond.dll!pn_class_decref(const pn_class_t * clazz, void *
object) Line 100 C++
qpid-protond.dll!pn_decref(void * object) Line 253 C++
qpid-protond.dll!pn_reactor_free(pn_reactor_t * reactor) Line 132
C++
c-reactor-tests.exe!test_reactor_acceptor() Line 171 C++
c-reactor-tests.exe!main(int argc, char * * argv) Line 446 C++
c-reactor-tests.exe!__tmainCRTStartup() Line 555 + 0x19 bytes C
c-reactor-tests.exe!mainCRTStartup() Line 371 C
kernel32.dll!7ff90cc913d2()
[Frames below may be incorrect and/or missing, no symbols loaded for
kernel32.dll]
ntdll.dll!7ff90e1003c4()
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
