Comments for Stephans Blog

Comment on Using Google Guice Providers to Solve Law of Demeter Problems by stephan

stephan — Thu, 24 Jul 2008 19:25:54 +0000

@Doug: Of course you’re right, my error, passing in Context is IoC.

“Sometimes that’s not possible. With IoC this can be solved without (much) refactoring.”

Reading my post again, I didn’t write that passing in a Context is not IoC, just that IoC can solve the problem.

Comment on Using Google Guice Providers to Solve Law of Demeter Problems by Doug

Doug — Thu, 24 Jul 2008 16:25:41 +0000

To be picky about terminology, passing a Context object IS a form of IoC. It’s what used to be called “Type 1″ IoC, or “Contextualized Dependency Lookup”. It’s not Dependency Injection, but it IS Inversion of Control. (One could argue that the dependency on the injected context qualifies as DI, but I don’t think that argument would win many supporters.) As noted, it’s harder to test than DI is.

As for the Law of Demeter, I say “ptthht.” There are some places where it’s a reasonable guideline, and many places where it isn’t. The real problem with passing a Context object instead of an Engine object is one of increased coupling: the method is not only coupled to the Engine class but to the Context class as well.

Comment on Unscientific Jetty versus Glassfish for REST by stephan

stephan — Mon, 21 Jul 2008 19:39:20 +0000

@Greg: Sorry, no source code yet, but it’s a simple Jersey REST resource which returns Json.

The versions were probably not the newest, the Jetty plugin is 6.1.10, the Glassfish plugin is 1.0-alpha-4.

“The difference between jetty/glassfish may be something as simple as default configured depth of accept queues. Unscientific as it is, its no fun having psuedo benchmarks published that you can’t analyse or respond to.”

I’m sorry, with some hindsight I wasn’t clever to publish numbers, a “around 1000req/sec” would have been enough. As I’ve said, both are so fast, that the numbers are really no problem to me (but might be for others, I agree).

It probably wouldn’t help if I do another benchmark, with published source code and documented configuration.

That aside, Jetty is an excellent container and the container of choice whenever I do something with servlets. Ever since we’ve developed SnipSnap some years ago I love Jetty.

Comment on Decided on a NAS: Zyxel, Infrant or Qnap by GroverBlue

GroverBlue — Mon, 21 Jul 2008 18:13:59 +0000

The Infrant box is hardware RAID, where as the QNAP box is software.

Comment on Unscientific Jetty versus Glassfish for REST by lumpynose

lumpynose — Mon, 21 Jul 2008 17:05:24 +0000

Very true.

I think the Rails scalability issue bothers me because I work with people who are Rails fanatics and their fanaticism blinds them to the scalability and reliability issues with Rails. The Rails people are typically chanting about how with it you can crank out a web app in no time at all, and within the Rails community you find very few people who think about the design and architecture of web applications. The whole mind set is to just use the tools that Rails gives you and be thankful that you don’t have to think about the gritty under the hood implementation details or alternative choices. They think of that as time wasted. I call it the Duncan Hines mind set. Duncan Hines is a cake mix in a box here in the states.

Comment on Unscientific Jetty versus Glassfish for REST by stephan

stephan — Mon, 21 Jul 2008 16:06:30 +0000

What I miss when people talk about scalability, is not if somethings scales or not (your app should be designed in a way that it scales), but how much it will cost. Linear scalability for academics is the same independent of the scaling factor (2n or 10n), for business it makes a huge difference (5x more money though both technologies scale linear).

I think it’s funny that VCs don’t care about how much a chosen technology costs to scale.

And no, I have no facts that Rails doesn’t scale as good as e.g. Spring, just a gut feeling.

But the post was mainly to reassure me that my scaling factor for the REST solution is cheap, not to bash Rails/Ruby (I was afraid after reading the report).

Comment on Unscientific Jetty versus Glassfish for REST by lumpynose

lumpynose — Mon, 21 Jul 2008 15:42:58 +0000

With Rails it was 320 requests per seconds with what, 25 servers? Given my experience probably a significant percentage of those servers were needed because so many are being restarted by some external monitoring process because the Mongrel, Webrick, or whatever, was hung. One of the Rails fanboys here was complaining that the monitoring program he uses, god, was sending him several false positives emails a day about the server being hung. Talk about adding insult to injury. But he doesn’t see it that way or what black comedy the whole Rails thing is.

Comment on Unscientific Jetty versus Glassfish for REST by Greg Wilkins

Greg Wilkins — Mon, 21 Jul 2008 07:31:13 +0000

Stephan,

What versions of jetty/glassfish were compared? Also, any chance you can make the source for this project available, or at least something similar.

The difference between jetty/glassfish may be something as simple as default configured depth of accept queues. Unscientific as it is, its no fun having psuedo benchmarks published that you can’t analyse or respond to.

cheers

Comment on Unscientific Jetty versus Glassfish for REST by stephan

stephan — Mon, 21 Jul 2008 06:32:38 +0000

Sorry, I don’t have a tutorial at hand, everytime I implement something new wit etags I use google to find the information I need. It’s usually not very often.

Peace
-stephan

Comment on Unscientific Jetty versus Glassfish for REST by anjan bacchu

anjan bacchu — Mon, 21 Jul 2008 06:16:30 +0000

hi Stephan,

thanks for the info.

E-Tag : I’ve been reading up on this for a while. Would you know of a tutorial /introduction on how to use it efficiently ?

Thank you,

BR,
~A