-
-
16. Re: Multithreaded services and their EPR(s)
"kurt.stam@jboss.com" wrote:
The registry already assigns a UID to the ServiceBinding (In which we store the EPR). Maybe I should just return this (for now?, or for always?).
So does this mean it already supports registering of the same EPR 1+ time?"kurt.stam@jboss.com" wrote:
... what we should change is that you need that UID when you unregister that EPR, and the UID is returned at registration time.
If it does support registering the same EPR 1+ times, then... if you didn't change the interface at all and just removed/unregistered 1 of the EPR instances matching the name, would that solve the issue? What are we doing at the moment - removing them all? -
17. Re: Multithreaded services and their EPR(s)
Yes, at least each node will get it's own UID, and the easiest thing for now is to treat a thread the same way. I f we have time we can can hide the threading from the registry.
-
18. Re: Multithreaded services and their EPR(s)
If it does support registering the same EPR 1+ times, then... if you didn't change the interface at all and just removed/unregistered 1 of the EPR instances matching the name, would that solve the issue? What are we doing at the moment - removing them all?
yes right now upon unregistering I clean out all similarly looking EPRs.
I'm still worried that we end up with 'dead' EPRs, but I guess the code that consumes EPRs can pick the next one (and unregister dead onces?). -
19. Re: Multithreaded services and their EPR(s)
"kurt.stam@jboss.com" wrote:
I'm still worried that we end up with 'dead' EPRs, but I guess the code that consumes EPRs can pick the next one (and unregister dead onces?).
Can't that happen in either case? -
20. Re: Multithreaded services and their EPR(s)
"tfennelly" wrote:
"kurt.stam@jboss.com" wrote:
I'm still worried that we end up with 'dead' EPRs, but I guess the code that consumes EPRs can pick the next one (and unregister dead onces?).
Can't that happen in either case?
Yes, unless we tell users to persist the UID they get back.
A complete and correct solution is more complex than we have time for. I suggest that we simply don't clear out all of the EPRs at un-registration time. Any "dead" EPRs can be handled by a sys admin. Plus, the definition of a "dead" EPR may well be implementation specific.
If we agree and this works (!) then we need to call this out in the docs. -
21. Re: Multithreaded services and their EPR(s)
Yes, but right now they get cleaned out now when unregistering a similarly looking EPR.
-
22. Re: Multithreaded services and their EPR(s)
"kurt.stam@jboss.com" wrote:
Yes, but right now they get cleaned out now when unregistering a similarly looking EPR.
But we know where that's getting us ;-) -
23. Re: Multithreaded services and their EPR(s)
"kurt.stam@jboss.com" wrote:
yes right now upon unregistering I clean out all similarly looking EPRs.
How do you define "simiarly looking"? You shouldn't be comparing EPRs because equality isn't supported. -
24. Re: Multithreaded services and their EPR(s)
Note that like the registry, the admin will never know if the EPR is dead, unless the all the ESB systems are down. Which is a situation that will not likely occur.
-
25. Re: Multithreaded services and their EPR(s)
Without getting into too much technical detail, but it's never possible to detect a failure with 100% accuracy until the failure is fixed. All you can ever do is failure suspect. With this approach to UIDs and multiple registration, we're always going to have garbage in the registry in the event of failures and it's never going to be possible for us to know for certain that we can/should remove an EPR. This is a long winded way of saying: we can punt this to a sys admin function for now.
-
26. Re: Multithreaded services and their EPR(s)
That sounds good and acceptable to me, so long as we provide the mechanism for someone to do that administration. How should they go about detecting dead EPRs in the database? Why not build an admin console (or something like that) where you could see all registered EPR's and even try sending an 'ack' message to each - no response or no confirmation that it's up and you could punt it. by confirmation, it could be a simple telnet to the epr port, etc...
just an idea. -
27. Re: Multithreaded services and their EPR(s)
There's the old hearbeat trick. Processes could be required to send a periodic heartbeat that would change the 'time to live' for that particular registry entry. A garbage cleaner could purge stale entries
-
28. Re: Multithreaded services and their EPR(s)
"estebanschifman" wrote:
There's the old hearbeat trick. Processes could be required to send a periodic heartbeat that would change the 'time to live' for that particular registry entry. A garbage cleaner could purge stale entries
Yeah, I've just been asking Kurt about the possibility of this.
The Reg client could just filter these out and something else could periodically remove them as you say Es. -
29. Re: Multithreaded services and their EPR(s)
I don't think it's possible to do this for the GA. There are too many unknowns that we would need to solve in order to do this correctly (e.g., what protocol for the heartbeat, how long should you wait etc.)
I believe Kurt said there was a UDDI admin console that we could use? If that's the case then we can add something to the documentation that tells the administrator (or even a client) to use this when they suspect and EPR points to a service that is no longer available.