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 ;)
