The point I was making is that Grizzly's primary focus is on performance
& scalability where performance is throughput & responsiveness
performance and scalability is its ability to take on more load and
maintain the performance throughput and responsiveness.
I did not say or claim higher level interfaces is a bad thing. It
depends on the application being developed as to whether performance &
scalability take preference over the ability to program at a higher
level interface, (which Grizzly will slower migrate that direction as it
evolves, but it will not sacrifice performance in migrating to a general
purpose framework).
Let me also make clear that I have not said mina is a bad framework.
Quite frankly it is a good framework. I'm only claiming that there's a
different focus on priorities with mina and grizzly. My claim is that
mina is a good general purpose framework which lesser emphasis on
performance. Grizzly primary focus is performance with (at the moment)
lesser emphasis on being a general purpose framework.
Hope that makes sense.
Btw, thanks for sharing your experience in developing your application
with Grizzly. We appreciate any feedback you can give us.
thanks,
charlie ...
ÏòÇØÏÍ wrote:
> Hi Hunt,
> I must admit I not capture all of your means on the last paragraph.
> And I must say sooooooorry for my pool english again.
> Performance, hmm, In my eyes, there are many kind of performance.
> I do a joke, it's a performance. You do speeching, it's a performance
> too.
> Java with a vm do execution, it's a performance tooooo.
> 100m dashing, it's one person performance.
> tug-of-war, it's people's performance.
> From above, we can get a view:
> Performance not just for only performance, but for happiness, and for
> world, and for romance.
>
> I have checked out J12007 grizzly report in which there is a
> performance comparasion between
> grizzly and mina. both 2 point grizzly higher than mina, but not more
> higher.
> And from comprarasion between grizzly and c style server, grizzly can
> do great performance.
>
> So, I think that high level should not a bad thing. We can just take a
> talk on Java.
> In my heart, Java more higher than cX. but why grizzly can do a higher
> than cX-Servers.
> It's a evidence. that it is. So why not grizzly do higher level.
> From this point extend to Java language, Java can do more higher.
>
> There is a base in it, just like china say, more people picking more
> woods, more flaming more blaze.
> It do a metaphor, grizzly do more higher, more people do more
> participating, grizzly do more great. And Java do this way now. is it?
> or isn't it?
>
> Ok, soooorry for my pool english again.
>
> BTW, Jacrand, I'm waint for you check out grizzly I about write
> selector code comments from me.
> You remember it? :)
> Ooops, if not, right, please jump to
> http://weblogs.java.net/blog/jfarcand/archive/2006/05/tricks_and_tips_1.html
>
> Wish someone do speaking china.:)
> Happy to hear you.
>
> Regards,
>
> 2007/6/16, charlie hunt <charlie.hunt_at_sun.com
> <mailto:charlie.hunt_at_sun.com>>:
>
> Some evidence of what I have been claiming as a differentiator between
> mina and grizzly which is grizzly's emphasis is on performance &
> scalability where mina's emphasis is on a general purpose framework.
>
> I make this claim based the comment, "grizzly just provide low
> level api
> for developer, proactor do it too, only mina give higher level api
> for
> developer".
>
> I'd claim Grizzly is being proactive to not produce an API or set of
> APIs that might inhibit performance and scalability. If we do, I'd
> expect that we'd deprecate them in a later release should one
> manage to
> creep in.
>
> charlie ...
>
> Jeanfrancois Arcand wrote:
> > Interesting....
> >
> > -------- Original Message --------
> > Subject: Number of class, Maybe and How?
> > Date: Fri, 15 Jun 2007 11:39:14 +0800
> > From: ÏòÇØÏÍ <fyaoxy_at_gmail.com <mailto:fyaoxy_at_gmail.com>>
> > Reply-To: dev_at_mina.apache.org <mailto:dev_at_mina.apache.org>
> > To: dev_at_mina.apache.org <mailto:dev_at_mina.apache.org>
> >
> > Sirs,
> > I tried mina with FTP client. and planing a FTP server, maybe
> rush into
> > apache ftpserver by using mina.
> > There is an interesting comparation between mina with grizzly,
> proactor, and
> > aio.
> >
> > with mina 1.1, I do a ftp client, need mina supported class java
> file about
> > 83.
> > with grizzly, about 25.
> > with proactor about 20.
> > inner class not included, I just count java file.
> > I don't know the number if mean something.and if it is, but How
> to do in
> > future?
> >
> > Besides coconut (not competed), grizzly just provide low level
> api for
> > developer,
> > proactor do it too, only mina give higher level api for developer.
> > I like this point. and In my personal view, I feel it is
> possible that
> > removing some operation from session context (in mina aka
> iosession).
> >
> > Hope hear you. And Sooooooooooorry for my pool english writing.
> >
> > Regards,
> >
> >
>
> --
>
> Charlie Hunt
> Java Performance Engineer
> 630.285.7708 x47708 (Internal)
>
> <http://java.sun.com/docs/performance/
> <http://java.sun.com/docs/performance/>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> <mailto:dev-unsubscribe_at_grizzly.dev.java.net>
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
> <mailto:dev-help_at_grizzly.dev.java.net>
>
>
>
>
> --
> ÏòÇØÏÍ
--
Charlie Hunt
Java Performance Engineer
630.285.7708 x47708 (Internal)
<http://java.sun.com/docs/performance/>