Comments (7)
Thanks for assigning, I appreciate it very much. I will keep you updated
from hexagon.
Thanks! Working on improvements. Want to build in some metrics too. Will keep you updated.
from hexagon.
Hi, I would like to work on this issue
from hexagon.
Ok, I will assign it to you.
The bottom line is that a lot of the code added to check connection errors and assure messages are handled and acknowledged is old (coming from Java 5+ years ago).
It would be great if it could be reduced (removing not needed code) by taking advantage of the latest AMQP Java Client (if possible).
This issue is a bit vague, sorry about that :( If you want to do a simple analysis and see how it could be improved to be smaller and simpler while still being reliable (this is the most important thing for me when dealing with messages), it would be great!
Thanks for your interest, and for your help :)
from hexagon.
Hi Juanjo,
- What I noticed you open a new channel for each message and that is what they don't want. Channels supposed to be long-lived.
"A classic anti-pattern to be avoided is opening a channel for each published message. Channels are supposed to be reasonably long-lived and opening a new one is a network round-trip which makes this pattern extremely inefficient. Just like connections, channels are meant to be long-lived. Opening a new channel for every operation would be highly inefficient is highly discouraged. Channels, however, can have a shorter life span than connections. For example, certain protocol errors will automatically close channels. If applications can recover from them, they can open a new channel and retry the operation."
This approach problems when you delete the queue and you did't call chanell.basicCancel() before
- you do retry() on the channel.basicAck(envelope.deliveryTag, false) in the Handler.kt. I am not sure if you really need it. The protocol states
"If a consumer dies without sending an ack, RabbitMQ will understand a message wasn't processed fully and will redeliver it to another consumer. That way you can be sure that no message is lost, even if the workers occasionally die."
-
you use sleep() but it is not a good idea. There are better ways to do that.
-
you set
factory.setAutomaticRecoveryEnabled(true);
factory.setNetworkRecoveryInterval(xxxxx);
so you don't really need to restore the connection manually.
"If recovery fails due to an exception (e.g. RabbitMQ node is still not reachable), it will be retried after a fixed time interval (default is 5 seconds). The interval can be configured." RabbitMQ Java client 4.0 and later versions have automatic connection recovery enabled by default.
I have done very tiny approvements in the code, just have a look. But there is more to be improved.
Let me know please what you think about this.
Thanks a lot
from hexagon.
Thanks for digging in the documentation and exposing those flaws, it is a valuable information.
I encourage you to make a PR with the improvements you made, and if you feel it could be further improved and want to give it a go, it would be great!
I really appreciate the time you took to improve this feature, thanks again!
from hexagon.
I've merged your PR. Thanks! let me know if you want to make further improvements to the module :)
from hexagon.
Related Issues (20)
- Add Netty HTTP client adapter HOT 12
- Complete SSE implementation HOT 1
- Message broker adapter
- Convert HTTP calls to an OpenAPI spec
- Develop OpenAPI verify callback
- Callback to return an OpenAPI example response HOT 6
- Add OpenAPI tooling example
- Add Mustache.java template adapter HOT 3
- Add jte template adapter
- Support multiplatform (Amper) HOT 1
- Create K8s starter
- Serve examples using DO infrastructure
- Code application/problem+{json,xml} exception handler
- HTTP model and handlers improvements
- Generate router from OpenAPI spec
- Rename to hexagontk
- Allow handler callbacks and predicates to be decorated after handler creation
- Support Unix Domain Sockets
- Use JReleaser to automate release
- [Helidon] Fetching form parameters with multiple values only return the last one
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from hexagon.