I think RMI makes the source code messy and complicates testing.
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
SCJP2
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
servers need to know when clients die RMI doesn't seem to be the best choice.
And you can have an RMI-callable server-side API the stub for which is this client-side object. Including lock and unlock, without modificationOriginally posted by John Immordino:
[...] there is one sticky point with RMI that hasn't been mentioned. The requirements state that one must have a client-side object that implement ALL public Data API. This includes the lock/unlock API.
Think. Long. Hard. Thoroughly. Maybe read my response in this thread. See the error of your ways and repentI'm planning to add an additional remote method for booking a flight that will lock/unlock in its server-side implementation to avoid lock/unlock over the network
But do you? When a client disconnects normally, perhaps; but a client would've called close() under those circumstances anyway. In fact, unless you use TCP/IP keepalive you will get no notification whatsoever of network problems severing the connection between client and server. The range of fault conditions that can be dealt with more easily using Sockets is fairly narrow, I think.This [cleanup] feature would be much easier to implement in a socket-based implementation as the server receives immediate notification when a client disconnects.
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Originally posted by Mark Spritzler:
Unreferenced interface.
Mark
Really? At first sight that seems plain silly. What are RMI leases, if not a sophisticated type of heartbeat implementation? What does a heartbeat do that a lease doesn't?Originally posted by John Immordino:
[...] If you adjust the lease value to be too low, your references may go stale between calls during normal operation. Waiting around 10 minutes after a client dies to clean up after it isn't reasonable, either, especially if that client attempts to log back in and grab the same resource(s).
Some folks work around this by sending client heartbeats, which is fine for a small number of clients
If you want guaranteed notification within a given time, there is no way around this -- no matter what protocol you choose or what layer you implement this in: application (heartbeat), RPC layer (RMI lease) or network protocol (keepalive); you will have a network overhead that increases with the number of users connected at any given time.but can cause network storms when that number grows.
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Originally posted by Peter den Haan:
Think. Long. Hard. Thoroughly. Maybe read my response in this thread. See the error of your ways and repent
[ February 10, 2003: Message edited by: Peter den Haan ][/QB]
Originally posted by Peter den Haan:
In fact, unless you use TCP/IP keepalive you will get no notification whatsoever of network problems severing the connection between client and server.
[ February 10, 2003: Message edited by: Peter den Haan ][/QB]
Originally posted by Peter den Haan:
My RMI-based cleanup code (using Unreferenced, as indicated by Mark) counted three lines, including the method header and closing brace but not including comments; shall we take bets on how socket-based cleanup with similar functionality pans out?
[ February 10, 2003: Message edited by: Peter den Haan ][/QB]
Originally posted by Peter den Haan:
Really? At first sight that seems plain silly. What are RMI leases, if not a sophisticated type of heartbeat implementation? What does a heartbeat do that a lease doesn't?
[ February 10, 2003: Message edited by: Peter den Haan ][/QB]
Originally posted by Peter den Haan:
If you want guaranteed notification within a given time, there is no way around this -- no matter what protocol you choose or what layer you implement this in: application (heartbeat), RPC layer (RMI lease) or network protocol (keepalive);
[ February 10, 2003: Message edited by: Peter den Haan ][/QB]
Originally posted by Peter den Haan:
you will have a network overhead that increases with the number of users connected at any given time.
[ February 10, 2003: Message edited by: Peter den Haan ][/QB]
Ok. You walk up to the guys from Oracle, IBM (DB2), Microsoft (SQL Server), Sybase, etc, and tell them that they've been suckered into building their businesses on an inherently bad design. I'll watchOriginally posted by John Immordino:
[...] I don't agree that Sun is intentionally nudging me toward a bad design.
I didn't dispute that -- but how does it respond to a network outage? It won't. That's where TCP keepalive kicks in.If the client terminates abnormally the server immediately receives an IOException as a result of that read call.
Let's not get hung up about the 10 minutes; changing that is just a system property away. You can easily crank this down to the 10-30 second mark, depending on the number of clients and the type of connectivity we're talking about, and that is quite acceptable in my book.It would be foolish to compare lines of code in an RMI vs. socket-based implementation. That's not the point. The point is that your 3 clean lines of code won't be called for at least 10 minutes if your client crashes. If you can live with this, I can too.
Sorry, I may be a bit thick tonight but I fail to see the your point. Whether the client sends a packet to the server every 10 seconds to renew its lease, or whether it sends a packet to the server every 10 seconds as a heartbeat, the difference is merely semantical. In either case, you can conclude after 20 seconds of silence that the client is probably dead.A lease is passive, a heartbeat is active. A lease may expire if your client terminates or it may expire if your client doesn't call the server for a while. A heartbeat ALWAYS means the client is alive, whether it's sending other messages to the server or not.
I don't see why that would be (OK, so you don't get lease renewals when there's nothing to lease, but in the FBN application every client always has a lease anyway).[...] I should have said that for a given number of clients, a server is much more loaded in a heartbeat implementation than in a lease implementation.
NIO is not at all a replacement for RMI; it's a replacement for java.io.* and java.net.*. NIO is more scalable because, among other things, it doesn't force you to waste a precious thread on every connection you are servicing.After all that, I still plan to use RMI - it's appropriate for this project. I'm just trying to point out that this is not always the case. If Sun disagrees, why did they invest so much time creating NIO to "enable scalable servers"?
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
My, my, aren't you a big fella. Here, have a tiny ad:
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
|