Hi chaps, sorry for butting in - was interested in passing!

 

Richard - it looks to me like the GExecutor was intended to be a purely
local workload handler, and for the Container to handle connections to the
rest of the infrastructure. It does at least create the needed endpoints,
and configure and create the Executor.

 

That said, the Executor then goes off and talks to the manager on its own
account, so either the design is flawed, or my interpretation of what
they're trying to do is.

 

In any case, I'd expect the Executor to talk to the Container purely about
workload, and for the Container to talk to the Manager on its behalf - and
therefore for the Container to fire Disconnected events rather than the
Executor.

 

(I'm assuming that ExecutorService, Container and GExecutor all form a
single worker process in this ..)

 

BTW - interesting framework; have spotted a couple of things I'd like to do
about resilience etc as well, I definitely agree on that point Jonathan.

 

Cheers, let me know if I'd wide of the mark,

Tim

 

 

From: Jonathan Mitchem [mailto:[email protected]] 
Sent: 28 March 2011 21:28
To: Richard Foreman
Cc: [email protected]
Subject: Re: [Alchemi-users] A few more questions

 

I'm not sure why a lot of Alchemi was designed the way it was.  There's
plenty of architectural decisions I questioned when I started, and continue
to question.  

 

If you followed what Matt and I tried to do, we were trying to take the best
ideas from Alchemi, and then rebuild from scratch supporting them, taking
what we liked and leaving the rest.

 

see: http://tools.assembla.com/alchemireloaded/wiki/OriginalAlchemiBreakdown

also: http://tools.assembla.com/alchemireloaded/wiki/BrainstormingArea

 

Probably the biggest complaint is that the resiliency simply isn't there.
The second is related to dependency management, as you've seen.  We were
going to try experimenting with resource-based scheduling, where each
executor has capabilities and each GApplication has requirements, and match
executors based upon those needs.  In your case, certain Java dependencies. 

 

I know the GridBus team at Melbourne was focused on that, but using one of
the open grid frameworks, not Alchemi.  http://www.cloudbus.org/intro.html

 

(I guess it's now CloudBus, and I guess they're still claiming Alchemi, even
though I don't think anyone there's touched it for 5+ years.)

 

Oftentimes I still feel in the same boat of "they did it this way for a
reason, right?"  Usually if I can't figure it out, I just do it my way, test
it, and occasionally realize that "ok, they had a point, if you don't do it
that way it doesn't work."

 

It's quite likely that at this point you have a better understanding of the
framework than I do.  And at the risk of offending someone, I think it's far
more complicated than it needs to be.

 

Anyway, glad to hear you've found a way to play with it without getting too
overwhelmed with newness.

 

 

Jonathan

On Mon, Mar 28, 2011 at 4:01 PM, Richard Foreman <[email protected]>
wrote:

Hello again Jonathan,

 

  I understand your busy so dont worry to much about it.  I just figured Id
throw it out there to see if you remembered enough about the inner workings
that you might be able to whip out an answer (or tell me Im freaking stupid
for not seeing the abvious lol).  Not to mention oe of the other people on
the list has been talking to me a little about it.

 

  As far as why I chose C++ as my second language, it was because of a
particular project that Ive been working on in VB for a few years, my own
bignumber class, and I figured c++ would be the best choice for it in order
to get the speed I wanted out of it, well turned out to be quite a lot
harder learning then I thought it would be, Ive literally spent hundreds of
hours reading and wading through other folks code to figure out how to do
things, now that I finally have a good enough grasp of it so that I can sit
down and actually tackle most anything I want with it, and I am afraid Id
loose it if I tackled another language full bore.  Until I started this, I
had allways thought tht C# was pretty close to C++, now I see that they are
completely different.  I have managed to get about 2/3 of the main classes
in C++ in the last 3 days (thats about 100 classes it turns out) without
hardly changing any of the functionality.  I had t make a couple of subtle
changes in order to get it to work.  

 

  The good news is, I am finally getting a grasp on th layout of the
framework so that I might actually be able to implement the changes I want
to make.  Like I said, given enough time, I can figure anything out.

 

 SIP? you working on that for voip or something?

 

  _____  

From: Jonathan Mitchem <[email protected]>
To: Richard Foreman <[email protected]>
Cc: [email protected]
Sent: Mon, March 28, 2011 12:36:43 PM
Subject: Re: [Alchemi-users] A few more questions


Gimme a day or three to respond.  I got this and started reading, but it
deserves more than just a cursory read. 

 

Of course, my first question was "why C++".  I assumed it was because you'd
been using C++ for a long time, but it seems that's not really the case.  I
strongly suggest you become competent in C#.  C++ is good to know too, but
if you're going to be in a managed environment, stick with C#.

 

Beyond that, I need to actually read/digest the real content of the email.
I'm in the middle of work stuff and writing a SIP client at home, so I don't
have the time to give it justice yet.

On Sun, Mar 27, 2011 at 12:11 PM, Richard Foreman <[email protected]>
wrote:

  I told you I was going to bug you again.  Ive started porting the whole
framework over to managed C++,  I was having too many problems with it in
C#.  I actually got the Core ported over easily, and have started on the
Executor classes when I ran into a snag which I havent figured out how to
get around yet.  Evereything in the Core and the first set of Executor
classes (I allready ported over the Executor classes, and am currently
working on the ExecutorExec classes, leaving just the Executor service class
to do)  Allright, so everyting in the executorexec classes ported over just
fine with the exception of a few of the events.

 

  Specifically, there are a few events defined in GExecutor( 

public

event GotDisconnectedEventHandler GotDisconnected; and 

public

event NonDedicatedExecutingStatusChangedEventHandler
NonDedicatedExecutingStatusChanged;) both of which are fired from within
GExecutor through delegates.  The ExecutorContainer class subscribes to
these events through the delegates, however, ExecutorContainer also defines
these events within itself through the same delegates as GExecutor.  The
handler for the GotDisconnected event is defined within ExecutorContainer to
handle th event fired from within GExecutor, but, all the handler does (I
beleive) is refire the event which is declared within itself.  Whoever wrote
the class wrote a comment about "bubble the event to whoever handles this.".
The problem I am having is that the compiler will not let me subscribe to
these events no matter how I try to set them up(these are the only two
events I am having trouble with the rest of that set of classes crossed over
just fine). So, heres where I have a question or two.  Why would they set up
the container class to refire an event fired from within a class that is
instantiated within the container class?  The instances of GExecutor are in
an array marked public in the container class, so if someone wanted to
subscribe to the events they could easily do it directly (I would think),
and as I said, the event handler in the container class does not do anything
with the event.  Or am I completely missing something here? 

 

  If it is something basic, dont get too mad.  I am a self taught programmer
and have only been working in C++ for about 6 months now.  I work full time
and am a single dad that just does this for fun, but given the chance, I can
prove I am not completely stupid (most of the time lol).

 

  Now the other question I have is about the dependency manifests.  One of
the applications I put out on my network relies heavily on an implementation
of a BigNumber class I wrote myself.  Now my implementation uses the java
BigInteger class just as a container for the number and uses the java
implementation for just basic math(add, subtract, and multiply) all the
other functions I had to implement myself because java gets lost when the
numbers get over about 100 digits for some reason.  Anyways, I started out
just doing the basic dependency on my thread (derived from GThread), but the
BigNumber class did not carry out to the executors even though it was
referenced in the class, so then I actually copied the code for bignumber
straight into the same file as the thread class, but it still didnt get
pushed out to the executors (that statement may be incorrect though), so
then I actually added Bignumber as an additional dependency and finally got
an error saying that java did not cross over with the bignumber class, then
I tried adding vjslib (java) as another dependency but the executors just
continually failed thread after thread until I actually installed the java
redistributable on ALL of my computers.  I believe it was still failing
because java had a dependency of its own that I am not aware of.  I believe
I was coding the threads correctly, I havent had any problems with any of
the other applications Ive wrote on this framework.  I figured Id ask you
since you are the only one that knows anything about this framework (not to
mention you are the only one answering haha).

 

  I know it is kind of hard to picture without seeing the code, and Id be
willing to send it to you if youd like.  Ill also send the C++ version to
you once Ive finished it and debugged it.  It was going smoothly till last
night, so if this is the only hiccup in it, I should have the core,executor,
and manager classes done by the end of this week, though the changes I am
working on making to it will not be that quick.  Ive also started
documenting the class heirarchy so if anyone else comes along and wants to
plug away at it that may help some.  The documentation within the framework
is actually superb, but, for those of us with limited ability, wading
through all of it to figure out how to do something is a chore in itself.

 

  Anyhow, this email went on longer then I thought, Im just trying to
explain things as thorough as possible.  The more I get into this framework,
the more I cant believe that it is as dead as it is.  I do appreciate any
help you can give.

 

Richard

 


----------------------------------------------------------------------------
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
alchemi-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/alchemi-users

 

 

 

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
alchemi-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/alchemi-users

Reply via email to