incubator-awf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michele Zuccala'" <zuccal...@gmail.com>
Subject Re: [Thread model] was : Re: Any activity soon ?
Date Tue, 14 Feb 2012 12:19:52 GMT
> I don't know exactly how you wrote you're Michele but, I think there are
> more effects than you see.


Hi Seven, can you explain better this point please!?!?!?
In the HttpProtocol.onread method, the request and the response are
new objects on every invocation
Same for RequestHandler that are always cloned.
Then I've thinked that invoking the RequestDispatcher in a separate
thread, at this point, can be safe, or in any case no more dangerous
than the current model of threads.
But since is code that I use normally, if you think it's technically
wrong, every your opinion is important.

Thanks,
Michele

>
>
> Séven.
>
> 2012/2/13 Emmanuel Lécharny <elecharny@gmail.com>
>
> > (Changing the subject for clarity)
> >
> > Le 2/13/12 7:59 PM, Johnathan Meehan a écrit :
> >
> >>
> >> Thinking about the threading model(s) to use, I also thought any updates
> >> of the code would be a good chance to change the workings a little. I
> >> was interested in explicitly adding state to the request, and perhaps
> >> consolidating the request/response to a single type.
> >>
> >> With state, each request/response is marked as at a particular point in
> >> the flow, which is now clearly defined for the developer and provides
> >> multiple and expandable options to inject code. It also raises the
> >> possibility of other things in the far (far, far) future like management
> >> by this state or moving to a staged model. The move to a single type
> >> would provide a nice clean interface, and make things a little simpler.
> >>
> >> Just thinking out loud, really, but I'm starting to wonder about how to
> >> make things as flexible as possible without impinging upon performance.
> >>
> >> Cheers,
> >> Johnathan
> >>
> >>
> >>
> >> On Sun, 2012-02-12 at 18:33 +0100, Michele Zuccala' wrote:
> >>
> >>> Hi guys,
> >>>
> >>> about the current architecture of threads, my version of deft, use a pool
> >>> inside the class httpProtocol (the change is to run
> >>> HttpRequestDispatcher in
> >>> a separate thread) and seems to work quite well.
> >>>
> >>> If can help, I can prepare a patch.
> >>>
> >>> Michele
> >>>
> >>> 2012/2/12 Séven Le Mesle<slemesle@xebia.fr>
> >>>
> >>>  Hi, Johnathan,
> >>>>
> >>>> Separating the demo, and sample from the core source tree to a separate
> >>>> tree is definitely a good point.
> >>>> I was also thinking about it this week :). This will also help us
> >>>> demonstrate awf simplicity to the community.
> >>>> A friend of mine, told me this week that we don't have any schema nor
> >>>> presentation on the site to introduce our technology to visitors.
> >>>> So I think we also need to work on the website, adding a "What is it
?"
> >>>> link and a "Starting with awf" would be nice, because it can help
> >>>> building
> >>>> a community.
> >>>> The roadmap, should also be on the site so anyone coming to the site
can
> >>>> see where we are going.
> >>>> I've also run a short audit on the existing source tree and the result
> >>>> is
> >>>> that we have cyclic dependencies that we need to solve a good sample
is
> >>>> the
> >>>> HttpResponseImpl using the HttpProtocol class to close or register.
> >>>> Last but not least, Deft was built to be used in single threaded manner,
> >>>> the introduction of multi-thread was a good point but the design remains
> >>>> oriented by the old architecture, I propose to fix this by removing
old
> >>>> fashion code the HttpServer is a good sample of this duality.
> >>>>
> >>>> Where can we maintain the roadmap, any idea ?
> >>>>
> >>>> Séven.
> >>>>
> >>>> 2012/2/12 Johnathan Meehan<jmeehan@phasevariance.**com<jmeehan@phasevariance.com>
> >>>> >
> >>>>
> >>>>  Hi,
> >>>>>
> >>>>> I like the priority list; I think it's nicer to build some kind
of
> >>>>> roadmap rather than just file and manage JIRA tickets as it gives
us
> >>>>> direction. Prior to any release, the packages should be renamed
as you
> >>>>> say but I was also wondering about moving things around a little.
Roger
> >>>>> created a demonstration gossip server, which still sits in the main
> >>>>> project under "demo". I would like to move this out to a separate
> >>>>> project, perhaps with a parent to keep versions and dependencies
> >>>>> straight. So, the top-level would now be:
> >>>>>
> >>>>> awf-core
> >>>>> awf-parent
> >>>>> awf-example-gossip
> >>>>>
> >>>>> Personally, I would like to put a couple more demonstrations together
> >>>>> to
> >>>>> see if that helps highlight what is missing and provide ideas on
where
> >>>>> to go. Sound okay?
> >>>>>
> >>>>> Cheers,
> >>>>> Johnathan
> >>>>>
> >>>>> On Mon, 2012-02-06 at 23:02 +0000, Mark Struberg wrote:
> >>>>>
> >>>>>> a release would be highly appreciated.
> >>>>>> We just need to do a few quick checks up front.
> >>>>>>
> >>>>>>
> >>>>>> Mainly if the IP is fine, plus a few things I've wrote up for
another
> >>>>>>
> >>>>> Incubator project:
> >>>>>
> >>>>>>
> >>>>>>  https://cwiki.apache.org/**confluence/display/DeltaSpike/**
> >>>> Reviewing+a+Release<https://cwiki.apache.org/confluence/display/DeltaSpike/Reviewing+a+Release>
> >>>>
> >>>>> LieGrue,
> >>>>>> strub
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>
> >>>>>>> From: Séven Le Mesle<sevenlemesle@gmail.com>
> >>>>>>> To: "deft-dev@incubator.apache.org**"<deft-dev@incubator.apache.**
> >>>>>>> org <deft-dev@incubator.apache.org>>
> >>>>>>> Cc:
> >>>>>>> Sent: Monday, February 6, 2012 11:55 PM
> >>>>>>> Subject: Re: Any activity soon ?
> >>>>>>>
> >>>>>>>
> >>>>>>> Good to have such answers, Michele I surely can get youre
patches and
> >>>>>>>
> >>>>>> merge them
> >>>>>
> >>>>>> in the source tree.
> >>>>>>> We chose a new name for the project, should I refactor the
packages
> >>>>>>>
> >>>>>> to
> >>>>
> >>>>> use the
> >>>>>
> >>>>>> new name as well as the pom's ?
> >>>>>>> My idea to keep the community up and running, is first to
make the ML
> >>>>>>>
> >>>>>> more
> >>>>>
> >>>>>> active so new users can have more feedback. I also want to write
one
> >>>>>>>
> >>>>>> article
> >>>>>
> >>>>>> about on my company blog: blog.xebia.fr it has good visibility
for
> >>>>>>>
> >>>>>> Java IT in
> >>>>>
> >>>>>> France.
> >>>>>>> Now here is the question what should we do now ?
> >>>>>>> By priority:
> >>>>>>> 1- improve http rfc support (streaming / parsing)
> >>>>>>> 2- improve buffering with pools
> >>>>>>> 3- create a builder pattern or something to simplify server
creation
> >>>>>>> (multi-thread included)
> >>>>>>> There is many fine tuning we can do to improve performances
and
> >>>>>>>
> >>>>>> usability.
> >>>>>
> >>>>>> One more thing, we need to release a full apache version.
> >>>>>>> I hope this sounds good to all of you, just tell me.
> >>>>>>>
> >>>>>>> Séven.
> >>>>>>>
> >>>>>>> Le 6 févr. 2012 à 22:57, Emmanuel Lécharny<elecharny@apache.org>
 a
> >>>>>>>
> >>>>>> écrit
> >>>>>
> >>>>>> :
> >>>>>>>
> >>>>>>>   On 2/6/12 10:23 PM, Michele Zuccala' wrote:
> >>>>>>>>
> >>>>>>>>>  Guys, I want to tell you that I never stop using
deft.
> >>>>>>>>>  When I have seen no more update, I looked for
something similar,
> >>>>>>>>>
> >>>>>>>> but
> >>>>
> >>>>> there
> >>>>>>>
> >>>>>>>>  is currently no framework that is simple to use, light
and fast
> >>>>>>>>>
> >>>>>>>> like
> >>>>
> >>>>> this (
> >>>>>>>
> >>>>>>>>  netty is good, but too generic)
> >>>>>>>>>
> >>>>>>>>>  After several months of use I can say that it
is already stable
> >>>>>>>>>
> >>>>>>>> enough
> >>>>>
> >>>>>> to be
> >>>>>>>
> >>>>>>>>  used in production (I'm not crazy: D is the engine
of my api REST)
> >>>>>>>>>
> >>>>>>>> and my
> >>>>>>>
> >>>>>>>>  boss is pleased of the results
> >>>>>>>>>
> >>>>>>>>>  So long life to deft and I would be happy to help
you with ideas
> >>>>>>>>>
> >>>>>>>> and
> >>>>
> >>>>>  patches that I have developed up to now.
> >>>>>>>>>
> >>>>>>>>  Any patch would be very welcomed ! You know, Michele,
becoming a
> >>>>>>>>
> >>>>>>> contributor is as easy as providing some patches and being
voted in
> >>>>>>>
> >>>>>> as
> >>>>
> >>>>> a
> >>>>>
> >>>>>> committer.
> >>>>>>>
> >>>>>>>>  Regarding the project status, I would also say that
the most
> >>>>>>>>
> >>>>>>> difficult part
> >>>>>
> >>>>>> of being in the incubator, is to get out and becoming a TLP.
It's all
> >>>>>>>
> >>>>>> about
> >>>>>
> >>>>>> attracting new committers, to increase the number of active
> >>>>>>>
> >>>>>> contributors, as an
> >>>>>
> >>>>>> ASF project is all about the community, not the code.
> >>>>>>>
> >>>>>>>>  Some of you may decide to stop the effort, because
they don't have
> >>>>>>>>
> >>>>>>> time, energy, or have switch to some other project, that's
just fine.
> >>>>>>> It's a collaborative effort, people get in, people get out.
And some
> >>>>>>>
> >>>>>> other
> >>>>>
> >>>>>> still have an interest in it, this is how the project keeps
going on.
> >>>>>>>
> >>>>>>>>  So let's make this baby shake !
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>  --
> >>>>>>>>  Regards,
> >>>>>>>>  Cordialement,
> >>>>>>>>  Emmanuel Lécharny
> >>>>>>>>  www.iktek.com
> >>>>>>>>
> >>>>>>>>
> >>>>>
> >>>>>
> >>>> --
> >>>> Séven Le Mesle
> >>>> Xebia IT Architects
> >>>>
> >>>> Email :  slemesle@xebia.fr
> >>>> Mobile :    +33(0)1 46 91 76 16
> >>>>
> >>>> http://www.xebia.fr
> >>>> http://blog.xebia.fr
> >>>>
> >>>> Siège Social
> >>>> La Défense Colisée
> >>>> 10 / 12  Avenue de l'arche
> >>>> Faubourg de l'Arche
> >>>> 92419 Courbevoie Cedex
> >>>>
> >>>>
> >>
> >
> > --
> > Regards,
> > Cordialement,
> > Emmanuel Lécharny
> > www.iktek.com
> >
> >
>
>
> --
> Séven Le Mesle
> Xebia IT Architects
>
> Email :  slemesle@xebia.fr
> Mobile :    +33(0)1 46 91 76 16
>
> http://www.xebia.fr
> http://blog.xebia.fr
>
> Siège Social
> La Défense Colisée
> 10 / 12  Avenue de l'arche
> Faubourg de l'Arche
> 92419 Courbevoie Cedex

Mime
View raw message