search

mbroadst / qamqp

AMQP 0.9.1 implementation for Qt
Other
151 stars 127 forks source link

Add storage of Queues and Exchanges to QAmqpClient. #27

Closed sjlongland closed 9 years ago

sjlongland commented 9 years ago

Rather than handing out "new" exchange and queue objects, we conserve memory and channel usage by keeping a list of existing objects.

If an object is asked for by name, we look for the existing object of that name first before declaring a new one. When a queue is asked for without a name, we wait until it is declared (thus given a name by the broker) before we store it.

For exchanges, all exchanges are stored by name: NULL QStrings are converted to an empty string to avoid having duplicate references to the "nameless" exchange.

mbroadst commented 9 years ago

okay! I think those are all my comments :smiling_imp: it seems you're still not passing a test, but it might be invalid at this point?

mbroadst commented 9 years ago

@sjlongland ping. I think that one test can be disabled considering your changes here. Then we can at least merge this in (sorry this has been somewhat trying)

sjlongland commented 9 years ago

Hi Matt, On 01/05/15 13:23, Matt Broadstone wrote:

@sjlongland https://github.com/sjlongland ping. I think that one test can be disabled considering your changes here. Then we can at least merge this in (sorry this has been somewhat trying)

No problems there. I've just been flat out lately, in addition to the C++ based code I've been writing there's a Python-based counterpart using pika that I'm also in the process of writing.

It was experimenting with QAMQP that told me I had problems in my Python code, so I'm working on eliminating those. I've taken the ideas used in these QAMQP branches and applied those to a wrapper around Pika+Tornado, using Fysom as a state machine.

The same concepts should work for QAMQP with QStateMachine. I do intend to get back to the C++ code since the performance felt orders of

magnitude faster.

Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind... ...it's backed up on a tape somewhere.

sjlongland commented 9 years ago

Okay, that's just fixed up the failing test case. Now to address the code style issues. :-)

sjlongland commented 9 years ago

That should have addressed the remaining issues, if I've missed anything, let me know. :-)

sjlongland commented 9 years ago

Out of interest, I just had a closer look at QStateMachine. One problem I see is there's no way to directly trigger a transition from a method other than to have declared a signal and to then emit that signal.

e.g. to use an existing example in Fysom (a Python state machine):

fsm = Fysom({'initial': 'green',
             'events': [
                 {'name': 'warn', 'src': 'green', 'dst': 'yellow'},
                 {'name': 'panic', 'src': 'yellow', 'dst': 'red'},
                 {'name': 'panic', 'src': 'green', 'dst': 'red'},
                 {'name': 'calm', 'src': 'red', 'dst': 'yellow'},
                 {'name': 'clear', 'src': 'yellow', 'dst': 'green'}],
             'callbacks': { … }})

fsm.panic(msg='killer bees')
fsm.calm()
fsm.clear()

— https://github.com/mriehl/fysom

There, each event gets its own method on the state machine object, which can then be called to signal events to the state machine. It seems QStateMachine requires that the events be signals or keyboard/mouse events.

We've got a couple of options:

mbroadst commented 9 years ago

@sjlongland I'm really sorry, I've been incredibly busy and this got away from me (shame on me for pinging you in the first place only to disappear :smile:). I agree with your wrt QStateMachine, I've often found it lacking for anything but automation of Qt gui states - however I did come to a similar conclusion that this -might- be possible with QAbstractStates. I think for now perhaps the best way to go about it is to continue to use the private enums (unless you're working on something currently)

sjlongland commented 9 years ago

On 08/06/15 23:22, Matt Broadstone wrote:

@sjlongland https://github.com/sjlongland I'm really sorry, I've been incredibly busy and this got away from me (shame on me for pinging you in the first place only to disappear :smile:).

This is fine, I've been flat out on the python side of things, we're still umming and arring about whether we do a move to C++ for the high-performance stuff and leave Python for things that are too hard in C++, or whether we stay purely Python based.

Right now the codebase I'm working on is officially pure Python with the C++ code being a proof-of-concept, but this may change as we're needing to squeeze a little more oomph out of little industrial computers with 128MB RAM: Python is getting a bit too chunky.

I agree with your wrt QStateMachine, I've often found it lacking for anything but automation of Qt gui states - however I did come to a similar conclusion that this -might- be possible with QAbstractStates. I think for now perhaps the best way to go about it is to continue to use the private enums (unless you're working on something currently)

The other option might be we port the concepts over from Jake Gordon's finite state machine¹ to Qt and that would give us a pretty robust non-GUI state machine.

The existing QStateMachine could also be used, we'd just have to come up with our own state transition class that can be triggered by a method.

Regards,

Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind... ...it's backed up on a tape somewhere.

1. http://codeincomplete.com/posts/2014/3/15/javascript_state_machine_v2_3_0/