search

instaclick / PDI-Plugin-Step-AMQP

AMQP Plugin for PDI
MIT License
10 stars 14 forks source link

Add Declare Exchange, Quque #9

Closed dshvedchenko closed 9 years ago

dshvedchenko commented 9 years ago

Binding implemented (!) targets have to exists. Durability, Autodelete, Exclusiveness - for Queue in Consumer Mode Durability, Autodelete, Exclusiveness - for Exchange in Producer Mode

FabioBatSilva commented 9 years ago

Some times I'm getting a "unable to open dialog for this step : -1" exception while editing the binding table, probably related to the iteration over the table items

FabioBatSilva commented 9 years ago

Nice work @dshvedchenko, Let me know when you have this minor fixes done and i'll take a look again

dshvedchenko commented 9 years ago

(!) for now I removed declaration for targets. Declaration for Queue/Exchange itself for Consumer/producer mode, and Binding. @FabioBatSilva what do you think about implementing declaration for Target ? is it necessary ? it will take extra 2 - 3 hours, but will it used by users ?

FabioBatSilva commented 9 years ago

Its i nice to have, Queue/Exchange declaration will handle most of the cases. Anyone how really need the "target" declaration can add another step before it to declare the "target".

dshvedchenko commented 9 years ago

BTW: how to treat current binding, should we remove already defined before add new ( defined in kettle ) ?

I think we at least can introduce auto-unbind on transformation finish, but it should be another issue

dshvedchenko commented 9 years ago

ArrayList used

FabioBatSilva commented 9 years ago

I believe the current behaviour will work fine..

IIRC Declaring simply ensures that it exists, creating it if necessary. So if you redeclare a queue/exchange/bind it should be no problem.

And If the user don`t need the queue/bind after the the kettle run he can declare it as not durable and rabbit will delete it after the transformation finish and disconnect.

dshvedchenko commented 9 years ago

currently consumer implemented, so if queue is empty at the moment transformation start, it will process nothing.

should we add mode SUBSCRIBER, to wait for some number of messages ??? maybe another issue ?

FabioBatSilva commented 9 years ago

We can open a issue to discuss this, But It can probably be done as part of the transformation

Something like :

"Declare Queue/Bind Step" ->  "Wait for X Sec Step" -> "Queue Consume Step"

Also transformation/jobs like that are usually scheduled to run from time to time, So in some cases its OK if the queue is empty in the first run the messages will be consumed durrring the next run.

FabioBatSilva commented 9 years ago

@dshvedchenko I'll do another test run and merge it you are done with your changes..

dshvedchenko commented 9 years ago

ok, so I'm waiting for you comments on current implementation and final decision about merge thank you

FabioBatSilva commented 9 years ago

Cool, i'll merge soon...

dshvedchenko commented 9 years ago

maybe we need extend text for limitation in Readme.md ...

dbron0000 commented 9 years ago

That would be nice for me. I have that function now but it is quite inefficient. A more thoughtful approach would be great for a subscriber,

Sent from my iPhone

On Mar 17, 2015, at 11:39 AM, Denis Shvedchenko notifications@github.com wrote:

currently consumer implemented, so if queue is empty at the moment transformation start, it will process nothing.

should we add mode SUBSCRIBER, to wait for some number of messages ??? maybe another issue ?

— Reply to this email directly or view it on GitHub.

FabioBatSilva commented 9 years ago

Nice work @dshvedchenko