2 ms·
Actually, a setter on an instantiated server object would prob be a bad idea there, unless you're proposing logic to scale up/down the number of threads dynamic
by jbooth 15y ago
Actually, a setter on an instantiated server object would prob be a bad idea there, unless you're proposing logic to scale up/down the number of threads dynamically. You probably want a constructor parameter.
- PaulHoule 15y agothe trouble with the constructor parameter is you need one for each and every parameter. this might be a good answer if the language supports named parameters for the constructor, but Java doesn't. In this case, there's a ThreadPoolConfig object which you can set these things on. It turns out you can pass this to the constructor^h^h^h^h^h^h^h^h^h^h^h^h factory method AND you can pass it to a reconfigure() method on the ThreadPool -- so the (normal) static case and the (slightly odd) dynamic case are both covered. It wouldn't be so bad if there were reasonable defaults for the ThreadPoolConfig, but there aren't. If you take the defaults, the server complains that you've got the wrong ThreadFactory when you try to start it. In the end I was able to solve the problem by getting a copy of the thread pool configuration of the server (having to do two casts), changing the thread count, and then reconfiguring. The final answer wasn't that bad, but it wasn't that good either. And that's the trouble w/ the Java culture. The basic design is tolerable, but it's complex, which makes it hard to understand and hard to implement correctly. A little bit of attention to (i) sensible defaults, and (ii) documentation would go a long way. Given a fixed budget, complexity is the enemy of quality, since it creates more surface area for barnacles to accumulate.
- jbooth 15y agoWell, it does sound like a bad design, because they should just be using an ExecutorService.. better implementation and industry-standard interface. Plus you could just do new Server(Executors.newCachingThreadPool(10)). Smart job skipping past my initial point to the deeper point, that constructor values would just accumulate, which creates a need for the builder pattern in the absence of named parameters (which would be sweet.. java 7 supposedly will give us map literals which can substitute).
- PaulHoule 15y agoIt ~is~ an ExecutorService, but it's funky because the Thread(s) that this system needs are special subclasses of Thread... Which in turn means you need a special ThreadFactory and such. Which of course points out more ugliness in Java; if there was a better generics implementation we could have the type system enforcing the correct choice of a ThreadFactory.
- jbooth 15y agoEh, it's an ugliness in this particular program IMO. You should not be subclassing Thread, pretty much ever, and every competent Java programmer will tell you so. That's like me writing Perl or Python code that uses globals for everything and then complaining that they're unmaintainable languages. Out of curiosity, which system are we talking about here? Jboss or something? Java protip, avoid any library involving the letters "EE".
- PaulHoule 15y agoGrizzly, a part of Glassfish. Officially sponsored by Sun^h^h^h^h Oracle.
- jbooth 15y agoYeah, there's your problem right there :) Never even looked at Glassfish but it was pretty much panned from the moment it came out. Sorry you have to work with it. Recommend Jetty or Netty if you want an embedded server to work with.