R
Rob Fitzpatrick
Guest
I didn't say that you *must not* overlap port ranges. That would imply that it doesn't work. It does. And obviously it is the simplest way to deploy if you want to avoid strictly unnecessary work. But I would call overlapping port ranges a worst practice. It is something that you *should not* do, IMHO. How much of a problem it might pose depends on your situation. I have internal servers that each run dozens of DBs, each with 4GL and SQL brokers. There are some AppServer and WebSpeed brokers as well. Some of my clients' machines are similar, though on a smaller scale. A range of 2001 ports seems large, and it is. If you have two or three brokers on a given box then probably it won't be a problem, as long as it *stays* at two or three. But things tend not to stay the same forever. As you add more and more brokers you are dividing that large range into smaller and smaller chunks. Those chunks can be made smaller still if port numbers within them are already defined in the services file as the brokers will skip those ones when giving ports to servers. This is particularly problematic on Linux boxes where the services file is full of unnecessary garbage after installation. The real problem is when you run into an error because a broker can't spawn a server. Everything might work just fine right up until that point but there is really no gauge you can look at to see how close you are to that point of failure. You may be okay when adding one more broker to the box, but if you do that enough there will come a time when you won't be okay and you will have errors. When the problem happens, then you ask why didn't the server spawn? Are the startup parameters wrong? Are all the ports in use? Where are they being used? I've been down that road more than once and it's a pain. Moreover it's a preventable pain. Others may disagree but I prefer to plan not to have errors than to not plan and have them eventually.
Continue reading...
Continue reading...