Hi All, I performed a code review on the new dispatcher mechanism, added my comments to AMDATU-282 and reopened the issue. I'm busy with testing of 0.1.0 and found/resolved some minor issues already (like AMDATU-293, AMDATU-294 and AMDATU-295). I will continue testing of 0.1.0 and take a look at the failing oAuth integration test. After that, I will dive into performance testing once again as there are some concerns that there is a considerable performance decrease in the BlueConic project, using Amdatu 0.1.0 compared to 0.0.6.
Regards, Ivo -----Original Message----- From: amdatu-developers-bounces at amdatu.org [mailto:[email protected]] On Behalf Of Bram de Kruijff Sent: dinsdag 8 februari 2011 12:52 To: amdatu-developers at amdatu.org Subject: Re: [Amdatu-developers] Status / Preparing for release 0.1.0 Hi, I have refactorred dispatcher as proposed below and comitted it to the branch. In addition internalized the tenant matcher logic (not resolver) as the mechanism was questionable an we have no real use case for it yet. Therefore I thought it better to remove it from the api. Finally a lot of javadoc / synchronization improvement etc etc. Still fighting with the good old OAuth and REST integration tests that are still broken on both trunk and branch. As nobody seems to really care I propose to merge the dispatcher branch back today so we can fight the battle on one front. Subsequently I would like to tag a 0.1.0 RC1 so projects can start integration testing and we can kick of a release vote. Ps. Be quick with a -1 if you do not want me to merge. I'll start this afternoon. Regards, Bram On Mon, Feb 7, 2011 at 1:56 PM, Bram de Kruijff <bdekruijff at gmail.com> wrote: > Hi list, > > as discussed we would like to get a 0.1.0 release vote going this week > but we still need to resolve some issues. Most pressing and high > impact is merging the dispatcher, tenantresolving and tenant aware > service into the trunk before we tag a release candidate. > > Right now we have a nasty blocker called > http://jira.amdatu.org/jira/browse/AMDATU-285 which is kind of a > fundamental issue because of the way filterchains work and stacksize > vm limitations. I propose to resolve this by changing the tenant > matching logic from passive to active. Eg. in the 50 tenants / 50 > filters case not building a chain of 2500 filters and matching upon > invocation but match the tenant beforehand which would roughly leave a > cacheable chain of 50 filters. Obvisouly the fundamental concern is > that intermediate changes (eg. by a filter in the chain itself) can no > longer affect the matching process, but I think with regard to tenant > awareness we can defend this. Obvisouly this will also dramatically > improve performance and throughput characteristics. I probably can > implement this approach this afternoon to complete all functional > issues for 0.1.0. > > A couple of questions: > > 1) Do you agree with the active tenant matching approach? Am I > overlooking something here? > 2) Can you guys look into other open/resolved issues and retest/close > them today/tomorrow? > > http://jira.amdatu.org/jira/browse/AMDATU/fixforversion/10030 > > If we can resolve everythiung today I would like to propose a merge > tomorrow after which we can tag a first rc. > > WDYT? > Bram > > > Ps. Ivo is not available and probably want be all week due to paternal > concerns ;) > _______________________________________________ Amdatu-developers mailing list Amdatu-developers at amdatu.org http://lists.amdatu.org/mailman/listinfo/amdatu-developers
