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/>