Hi,
once 1.5.2 is out the door, It might be a good idea to start a new sub
module that contains high level interface (like context.write(String))
and evangelize that such API might (or might not) gives the same
performance as the low level one. I would think this is a good extension
, and more important, a very good way to get a free t-shirt if people
wants to collaborate :-)
A+
-- Jeanfrancois
charlie hunt wrote:
> 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>
>>
>>
>>
>>
>> --
>> 向秦贤
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net