I've still problems with JIRA 1907. So for now I have to refrain to create dynamic wiring for now, because ComponentUpdater doens't work as I intended. I misunderstand something that happens in wiring so i need more debugging on it but and now it's time for me to build performance test in our cluster. We want to see if your infrastructure is efficient. I'm going to use callable reference instead of calling back. My previous callback problem was due to the fact that in CallableReferenceImpl, there's not enough state to recreate a proper wire to callback. The Object callback is trasient, oif you set it and serialize and send away that reference, you'll loose it. What it miss is a way to recreate a callback properly in this case. I might investigate on how to solve this use case, but i lack of time. Any suggestions?
Let me explain better: Suppose the following scenario: - Scenario A The actors are : ComonentA, ComponentB, ComponentC * ComponentA holds a CallableReference's ComponentC (it contains ComponentC scdl) , send it to ComponentB sets itself as callback to ComponentC, calls a Component C method and the callback from Component C will fail. There are performance problems in using the current domain implementation. If you see the code, every nodes when it looks for a service, whether it's local gives out the endpoint string, but if the service is remote (not in that node) for each request to the service. The node queries the domain node, and this it don't scale up. I've created an endpoint's string cache with an expiring ttl to fix this problem.Just testing it now. That's because in my application i call the same method a lot of times. Looking into the future work, it will be nice: * having a membership support, that it scale up for a domain. A domain is a business enviroment, and it could be made of a lot of nodes. I looked Apache Tribes, it needs some work, using an hearthbeat is a scalability issue if the nodes are more then 100. And when i was looking P2P system research, I found a Scalable Membership protocol called SCAMP. You'll discover more in my homepage at cli : http://www.cli.di.unipi.it/~zoppi/scamp.pdf * having the possibility to move composite from a node to another node in order to achieve load balancing and fail over. This requires that a composite have to be stopped in a safe way: when all components/services inside it are stopped, you can stop the composite and move around. This is a lot of work and there're a lot of research papers about it. Just find the way that you think more appropriate for this task, and just find it, i.e: http://asna.ewi.utwente.nl/research/Ph.D.%20Theses/wegdam-PhD-dyn-reconf-load-distr-middleware-2003.pdf Well, these are my thoughts about current limitations in SCA scalability. Maybe i'll discover more after testing. The cool thing about SCA is its inherent simplicity, and it could be used for composing complex software distributed around Internet. Just 1 cent, to start a discussion. Cheers, Giorgio. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
