On Thu, Dec 9, 2010 at 12:43 PM, Rickard Öberg <[email protected]> wrote: > On 2010-12-09 12.28, Niclas Hedhman wrote: >> >> FTR, While having an AssemblyException in my domain code, Apache Karaf >> (my OSGi container of choice) and my Qi4j started, was trying to >> create the Qi4j app every 15 secs or something, over night. When I >> came in the morning, 1.2 million classes had been loaded and unloaded, >> with a delta of 4000 (kind of expected). And memory had not grown over >> the top; From a minimum of ~12MB to ~22MB. Let's say there was 7000 >> (only every 30sec) Qi4j starts per hour, times 15 hours, gives us >> ~100,000 tried starts. That would be 100 bytes leak per start, and I >> doubt a ASM generated class would fit in that, assuming only a single >> Mixin subclass was created. > > Well that's pretty cool! As I said, the problem we had was with FileInstall > having funky ideas of what to do when the bundles changed, so that is a very > specific issue. But one that should have been fixed, like, aaaages ago. That > was the sad part. OSGi as such I have no problem with (not anything serious > anyway).
I think FileInstall is used in Karaf as well, but I have not checked. I build straight into the deploy folder, and have not noticed any peculiar behavior yet. > The idea is that an event tells you what happened > in another system, and if you want to react on it by creating a command on > your domain model, which in turn creates a new event, that is fine. Ok, so bare with me to spin this with actual numbers; External events are (or could be) well-defined, and most likely will be required to arrive via a transactional delivery mechansim, like MQseries. So, I can put a handful of workers consuming those feeds, and issue a "request-response" style command to each system which it knows need this (typically only one, since the feeds are 'purchased' individually). I have already created a Cache Affinity Request Router, which looks at a request and can route it to the same node for the same key pattern, that increases cache hit ratios in the service nodes. So far so good; The external event boundary is data affinity friendly, well-defined, scalable, resilient (well only as resilient as MQ installation is), hard to test, so need to be kept as simple as possible. The external interfaces don't receive more than 100,000 events per day. But then; An event [IBM announcing that on 2011-01-25 it will pay $0.35 per share in dividend, according to Bloomberg] arrives. This is a "market observable", which we will need to capture "as-is", since we minutes later can receive the 'same' announcement from another vendor, with different data in it. So, the command from 'vendor receiver' application would be something like DividendsService[resource=IBM/observations, operation=post[2011-01-25, $0.35, Bloomberg]]... The 'downside' is that I will now have 2 separate applications per domain, instead of my initial expectation of a single one. Can probably manage this. So now at the main model, things start becoming 'massive'. This 'observation' needs to be forwarded to up to 700 clients. It will also affect the extrapolations of future dividends for IBM, so we need to notify each 'IBM dividend view' (each being an entity, but can be directly referenced from the IBM entity), so they can notify the clients of each view. We will also need to notify every Index (separate entity cluster, but same system) where IBM is a constituent, possibly hundreds and being changed often. So these indexes/baskets should associate themselves with "IBM" entity as "listeners". At this point, S&P index can not expect IBM stock to understand why S&P is interested in IBM updates. So going "event-to-command" here seems very illogical, yet I suspect you will suggest that. ALSO, don't forget that *I* am developing the infrastructure that "just runs" domain models created by 'mere mortals' and not by geniuses. So at domain model level (dividends above), I need things to be dirt simple, not requiring a master mind in modeling and abstractions. -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
