Comments (6)
So basically you just want to change a Connection's options after it's been created?
Right now the ConnectionOptions class is cloned when a Connection is created, and the new clone is stored internally for the Connection. If addresses are something that can change over time (like configuration) I'd consider either moving them to the ConnectionConfig interface where they can be exposed and modified over time or making the ConnectionOptions publicly available via the ConfigurableConnection interface.
Conceptually, options were intended to be things that do not change whereas configuration can change. You've brought up a good point that for connections which can re-established, the config could potentially change.
Do you have any API suggestions for what this would look like?
from lyra.
Thanks for explaining the design considerations of ConnectionOptions and ConnectionConfig. I now understand the separation of concerns.
Proposals for address resolver
Option 1 - A very simple one, and should suffice for most cases and good to start with
// A resolver that is called back when a new (or recovery) connection is attempted
public interface AddressResolver {
Address[] resolve();
}
Option 2 - A stateful resolver - helps to pick an address that has lesser number of open connections, or is located in the same zone/region. The entire logic can be plugged in this way.
// A resolver that is called back when a new (or recovery) connection is attempted
public interface AddressResolver {
Address nextAddress();
}
Option 2 would be my preference since it caters to more usecases.
Proposals for setting the address resolver
I would be ok to have the resolver set into either the Options or the Config.
from lyra.
Please review and comment on the proposed changes as in the above comment.
from lyra.
Have raised a pull request for this with Option 2. See #21.
Happy to incorporate any review comments suggested.
from lyra.
Still thinking about this feature. You described a few possible use cases for an AddressResolver, but I'm wondering how you'll most likely use this in practice? I'm just wondering about the necessity of having something like an AddressResolver versus simply being able to change the set of addresses (options.setAddresses
) after a Connection has been established. Along the same lines, it makes me wonder if there's a need to change other ConnectionOptions after a Connection has been established - probably not, but if so I'd like to address all of this at the same time.
from lyra.
In an environment that I'm working on right now, I would implement the AddressResolver to fetch the current list of addresses from a central registry. This is a http call to an external system which maintains the rabbitmq cluster member details and it would take a few milli-seconds to complete.
Having to set "options.setAddresses" is ok, but the point is that I would need to update the addresses periodically anticipating a connection re-establishment. Having a resolver helps to optimize in saying that the fetch is going to be made only when required (i.e. when a new connection is being re-attempted).
I haven't come across use-cases for updating the connection factory settings or the execution service after connection establishment. But if I do, I'll raise them here.
from lyra.
Related Issues (20)
- Reconnection after RabbitMQ shutdown is not successful HOT 5
- when java.net.UnknownHostException is thrown the recovery failed
- What about moving to the latest 'amqp-client' version?
- Forgotten copying of automaticRecovery in ConnectionOptions.copy() HOT 1
- Documentation on ConnectionFactory used in ConnectionOptions HOT 2
- support withUri() in ConnectionOptions HOT 5
- Moving to latest RabbitMQ Java Client 4.0 HOT 5
- Why to copy ConnectionFactory on each create HOT 7
- No communication after recovery HOT 4
- Consumers not getting messages after broker restart HOT 8
- Connection name is not passed HOT 8
- RabbitMQ flooded by new connections HOT 5
- Lyra recover mechanism can prevent from the JVM to shutdown HOT 6
- Get rid of static executor service HOT 2
- Rapid growth of connections when network conditions are unreliable HOT 3
- retryableExceptions configuration and implementation HOT 3
- Use a `Predicate` for retry exception strategy
- Getting Rabbitmq HeartBeat Exception HOT 3
- Lyra is no longer under active development. HOT 1
- Connection recovery fails and gives up even though recovery policy is recoverAlways() HOT 1
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 lyra.