« first day (2 days earlier)    last day (27 days later) » 

Sylvain Boisse
Sylvain Boisse
2:26 PM
Hello! Sorry, christmas helidays, i was in my family.
- Datacenters: ok we understand each other, it's good
- For socket liveliness you should be clearer un your naming, it is confusing. liveUpdatedSockets contains non-live sockets? so it contains all? but hy is it useful, and why name it as such?
either rename it as allSockets or only put live sockets inside
you'll need an always up-to-date list of live sockets at some point. It's not very clean to filter them every time in getLiveSocket
- ack: why do you only wait ack on checker thread, why not on every single message? that would allow more responsiveness
you know what you are re-inventing? a Load-balancer.
(but one with priority)
Anyway, all you said is what your code told me, except socket.isLive() which I thought was doing something but is just returning a stored boolean
I think you should lift your pen a bit, a think about interaction between your objects, and their responsibilites.
for example, why would a Socket not manage itself? ping itself every 60s, manage a queue of input messages, etc ?
you don't need a manager class. You don't need to have the pings be simltaneous.
also sockets can have much better info than the manager class about themselves. They could wait for ack on their own business messages, and delay pinging (a business message is also a ping if it receives an ack!)
you should delegate responsibility to your objects a bit more
manager classes are a form of god-object, which increase complexity, reduce reusabilty and rewrittability
For example, having a singleton would be fine, to handle a unique pinger thread. Unnecessary, but fine.
but i don't see the point of SendToQueue being a singleton at all. In fact, i don't see why it should have an instance in the first place.
it has methods without side-effects. Those could be made static methods.
now static methods acting solely through other Objects means the method should be written over there.
in multithreading, to handle thread concurrencies, reducing object count is not the right tool. It's controlling Thread actions and interactions. Many threads could use a single singleton Object in parallel, or could use multiple instances of that Object to the same effect.
you need to think 'thread' not 'object', it's like an othogonal dimension in a way.
 

« first day (2 days earlier)    last day (27 days later) »