> > > > btw, from the "what is it" in the incubator page, "intelligent standalone > > robot framework" indeed vague to me. other than "framework" that clearly > > mean it is not a complete application, the other 3 terms are not clear to > > me. does "standalone" refer to it's not distributed/clustered? > > > For now droids clustering is not supported but in the future I hope some > usecases will bring to that level. The standalone is thought to reflect > that you can generate different droids/robots that are working alone > without having to invoke them within the framework. > > > I actually > > expect it Droids to provide a clustered infrastructure to run Droid / > > execute Task. Say, for web crawling, one could easily get to the > bottleneck > > by adding more threads, and a cluster environment is needed. > > I guess it should not be hard to deploy droids to an clustered > environment. > > re. cluster, i attempted to make Droids run in more than one clustered node before. the first question will be what to be clustered. and the first item to consider is the queue. it should be possible to cluster-enable a queue easily by using Hazelcast's queue. I didn't test its performance at all but in general, I doubt if any clustered queue solution could be good in performance in different scenario. I concluded that, it's better for the Task Master and the Queue be run in a single JVM. (or maybe it's useful to have a active-passive setup for redundency, but not active-active)
for the other data, e.g. the "history", it's easily to be clustered. infinispan (successor of JBossCache) is probably the best solution right now. I didn't pursue it further as I found it's much better to split the components to run in cloud than in a cluster, for web crawling use case. regards, mingfai
