[Building Sakai] cluster service and internode communication

John Bush john.bush at rsmart.com
Tue Mar 19 10:58:31 PDT 2013


The other idea we have is via the server configuration service.  We
have already built a database back end for configuration that is node
aware, we are beginning to think through how to make certain
properties runtime changeable.  Really all you need in that case is

getString(property, serverId)

you can already get the serverId's from the cluster service. Earle and
I will bring this up on the cle call tomorrow, if we can agree on a
path forward, we have the capacity to do the work.  I'm going to
articulate some of the reqs regarding an event/messaging system in
confluence today.  I'm actually leaning towards activemq now.  apollo
is going to become the broker for activemq in a new version. So if we
continue along the activemq path, we will get that speed and mgmt
improvements when they are ready.  Apollo feels a little not ready for
prime time to me, but it looks really promising.

I think really all that is needed is to make configuration simple and
easy and we can simply start with the messageservice that is in
contrib already, that we have been using for years.  It just needs a
better ootb experience that is easy to configure and cluster friendly.

On Tue, Mar 19, 2013 at 4:05 AM, Adams, David <da1 at vt.edu> wrote:
> I don't have any experience to share in this area, but based on my understanding of the cluster service, I think that a sakai_cluster_property or something similar is probably the safest and easiest way to add this kind of functionality. Or, if the message server could be split off optionally onto a separate machine altogether which was not also a Sakai server, then perhaps a similar but differently named table would be in order. Say, sakai_cluster_other or something better than that. :)
>
> -dave
> ________________________________________
> From: sakai-dev-bounces at collab.sakaiproject.org [sakai-dev-bounces at collab.sakaiproject.org] On Behalf Of John Bush [john.bush at rsmart.com]
> Sent: Monday, March 18, 2013 5:59 PM
> To: Sakai-Dev
> Subject: [Building Sakai] cluster service and internode communication
>
> Has anyone, maybe mobile guys ? Crossed the bridge of how to get sakai
> nodes talking to other nodes directly via http ?  I know the
> entitybroker type stuff uses cookies to go back to the right node.
> What I'm talking about is I need a way to talk to a sakai node
> directly from another node.
>
> The use case I have is for creating a discovery service for a message
> queuing service.  I want each node to be able to query other nodes and
> notify them when they go up and down.  This is to enable auto
> discovery and avoid multicast and make configuration as simply as
> possible.
>
> One thought I had was to tie into the clusterservice which already
> knows the serverIds, but it doesn't know direct url or ports for
> specific node communication.  So for example if we extended
> sakai_cluster tables to also have sakai_cluster_property table, I
> could have nodes register direct urls to talk to for my specific
> service as properties, maybe some new interface could be created where
> services and tools could register their own call backs for other
> properties.  It would take a simply change to the maintenance thread
> to do this, but avoid another thread and maybe be useful for some
> other use case.
>
> Or I could just totally bypass the clusterservice and do this my own
> way, or maybe someone else has already solved this another way?
> Thoughts ?
>
> --
> John Bush
> 602-490-0470
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"



-- 
John Bush
602-490-0470


More information about the sakai-dev mailing list