Hi Luis, This seems to be a good idea, with some important issues. (If designed well, we could have a good system with something like a 'dll cache' on the Executor side. It might be a good idea to check out if there are any helper classes in the .Net framework which help with maintaining this kind of a cache. Essentially, I would think, we need somehting like a Alchemi-owned/managed GAC-like store on the Executor, which is accessible & managed only to the Executor, and nothing else on that machine. We will probably run into versioning and various other issues and will need to consider that when designing such a system.
I am happy for you to build it, and will provide any help / ideas as needed. Currently though, there are some very important changes I am making. We should base your changes on the outcome of my current round of changes. Basically, what I am doing is adding some security features such as sandboxed thread execution (using CAS), and operation of Alchemi under a least-privilege-account to prevent grid-based 'malware' from being run via Alchemi. This will mean some important changes in the way files are stored, and managed on the Manager and the Executor. I am also changing the way multiple CPUs and handled on an Executor. Currently the solution is to host more than one GExecutor remote object in the same ExecutorContainer, meaning there would be more number of ports it listens to. I think this causes deployment issues. I believe it is best to leave the 'scheduling' for multiple CPUs in the Manager, and have code in the Executor which lets the manager know about how many CPUs / cores it has etc... and the Manager can decide whether to schedule more than one job at a time to an Executor with multi-CPU / multi-core capabilities. This will give us more flexibility in scheduling. Anyway, after the initial set of changes, I think Alchemi will be usable again, hopefully within a week. So I suppose you can begin designing the 'dll cache' now, and implement it into the new Alchemi. Please let me know your thoughts. Cheers Krishna. Luis Cota wrote: > > Krishna, > > > > I was speaking with Tibor recently about some proposed changes > regarding assembly version control across a grid. He mentioned that I > should speak with you before undertaking any such changes because you > were working on making lots of changes to the code base. > > > > What I was proposing is some method to keep assemblies loaded within > each executor. In addition, each time an Executor is requested by a > Manager, the Manager/Executor perform a version sync operation to > prevent unnecessary file transfers. While using Alchemi with Excel to > (financial app), I noticed that the benefit of using Alchemi rapidly > diminishes because of network latency. > > > > What are your thoughts about this? > > > > - Luis > -- Krishna Nadiminti Research Programmer, GRIDS laboratory, Department of Computer Science and Software Engineering, The University of Melbourne. e: [EMAIL PROTECTED] p: +61 3 8344 1347 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Alchemi-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/alchemi-developers
