Future of Galaxy

[Sergey Stupin]

Hello, guys!

First of all I wanted to thank you for creating Galaxy. It is a really brave attempt to solve complex distributed problems but as we can see Galaxy is not actively developed at this moment. So I would like to know are there any further plans in supporting Galaxy? 

p.s. Imho is it's not stable enough to be a production ready solution because even in our test environments we've got some strange runtime exceptions, SQL persistency don't work and not tested at all (unfortunately BerkeleyDB has unsuitable licence for us). And is seems that test coverage should be much larger for such a complex framework. Please take my words easy, I just want to help if I can. 

Again just wanted to mention Galaxy has reasonable design principles and nice quasar-actors integration, and it could become best in place framework for distributed JVM actors if someone could pay more attention to it. 

Thanks.

[pron]

Hi Sergey!

Most of my personal work these days is on Galaxy, with the goal of making sure it is suitable for serving as a distributed grid for distributed databases. This work is done as part of the closed-source SpaceBase project, but all modifications to Galaxy will find their way to the public repo once their ready. However, the work concentrates on the more algorithmic aspects of Galaxy (and includes formal verification of the underlying algorithms) rather than the more “mundane” tasks of bringing integrations (like SQL persistence) up to speed. Obviously, the latter is more important if you only use Galaxy as a messaging platform for actors.

Galaxy, at this point, is not production ready. However, if all you need is actor messaging it may be good enough (and the work you’ve been contributing is first rate and much appreciated). If that is not good enough for you, Quasar actors are easily integrated with any other messaging solution. Remember, actors are free to do IO, to use channels, or make use of Quasar’s integration with the ReactiveStreams API that some IO solutions already support.

As to BerkeleyDB, note that 1/ we don’t redistribute it with Galaxy, and therefore the license doesn’t infect Galaxy itself, 2/ it is only used in the Galaxy main server which your users don’t access over the network directly, therefore, none of the code running on the Galaxy server nor any of your application code running on any other Galaxy node is infected. It is a completely isolated process, running as an internal service, isolated from other Galaxy nodes as well as your application through network access. Its license therefore shouldn’t pose a problem to anyone making use of it unless you have code that runs in the same process as Galaxy's central server. It shouldn't infect anyone's software with the AGPL license any more than the Linux kernel infects user processes with the GPL license.

Ron

[Sergey Stupin]

Hi, Ron. Thanks for the quick reply.

If understand you write Galaxy provides nothing for quasar-actors except:

1. message-transport protocol (via peer-2-peer UDP channels)
   
2. GlobalActorRegistry

By saying "nothing" foremost I mean that quasar-actors doesn't benefit from Galaxy's fault-tolerance feature provided by capability of running peer-groups with slave-peer nodes? 

I think at this point we don't really need Galaxy for an operation distributed actor system, cause it brings some overhead on testing, configurating and startup stages. So the main question is - could I just replace 

1. Galaxy message-transport with a netty implementation. It would be great If you could point me out some ReactiveStreams IO implementations and how could I link actor messaging wit ReactiveStreams.
2. And GalaxyActorRegistry with a simple discovery service provided by apache ZooKeeper? 
   

What pitfails should I expect on my way? I think it could be worth to open source those solutions to make distributed quasar-actors more friendly and easy to start with.

--
You received this message because you are subscribed to a topic in the Google Groups "galaxy-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/galaxy-user/uNIJ8SDhUuY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to galaxy-user...@googlegroups.com.
To post to this group, send email to galax...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/galaxy-user/f1f68ca7-0571-48ec-8d16-08282b1fec7d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Best regards,
Stupin Sergey.

[pron]

On Tuesday, September 29, 2015 at 3:58:05 PM UTC+3, Sergey Stupin wrote:

If understand you write Galaxy provides nothing for quasar-actors except:

1. message-transport protocol (via peer-2-peer UDP channels)
   
2. GlobalActorRegistry

Well, there's actor migration too (and that already uses Galaxy's core capabilities.

 

By saying "nothing" foremost I mean that quasar-actors doesn't benefit from Galaxy's fault-tolerance feature provided by capability of running peer-groups with slave-peer nodes? 

Right. Actors are not yet connected to Galaxy's failover features. They will be in the future.

 

I think at this point we don't really need Galaxy for an operation distributed actor system, cause it brings some overhead on testing, configurating and startup stages. So the main question is - could I just replace 

1. Galaxy message-transport with a netty implementation. It would be great If you could point me out some ReactiveStreams IO implementations and how could I link actor messaging wit ReactiveStreams.
2. And GalaxyActorRegistry with a simple discovery service provided by apache ZooKeeper? 

The simplest thing, I guess, would be to simply not use treat actors as distributed actors, and simply let actors communicate over any messaging solution out there.  An actor that sends/receive messages to/from a remote actor would explicitly use the messaging solution.

 

I think it could be worth to open source those solutions to make distributed quasar-actors more friendly and easy to start with.

Our priority would be working on making Galaxy production ready. Anyone out there is, however, free to contribute such a solution. Alternatively, we'll be happy to discuss addressing specific requests of Galaxy bug-fixes/features as part of a support plan.

Ron

 

2015-09-29 14:44 GMT+03:00 pron <>:

Hi Sergey!

Most of my personal work these days is on Galaxy, with the goal of making sure it is suitable for serving as a distributed grid for distributed databases. This work is done as part of the closed-source SpaceBase project, but all modifications to Galaxy will find their way to the public repo once their ready. However, the work concentrates on the more algorithmic aspects of Galaxy (and includes formal verification of the underlying algorithms) rather than the more “mundane” tasks of bringing integrations (like SQL persistence) up to speed. Obviously, the latter is more important if you only use Galaxy as a messaging platform for actors.

Galaxy, at this point, is not production ready. However, if all you need is actor messaging it may be good enough (and the work you’ve been contributing is first rate and much appreciated). If that is not good enough for you, Quasar actors are easily integrated with any other messaging solution. Remember, actors are free to do IO, to use channels, or make use of Quasar’s integration with the ReactiveStreams API that some IO solutions already support.

As to BerkeleyDB, note that 1/ we don’t redistribute it with Galaxy, and therefore the license doesn’t infect Galaxy itself, 2/ it is only used in the Galaxy main server which your users don’t access over the network directly, therefore, none of the code running on the Galaxy server nor any of your application code running on any other Galaxy node is infected. It is a completely isolated process, running as an internal service, isolated from other Galaxy nodes as well as your application through network access. Its license therefore shouldn’t pose a problem to anyone making use of it unless you have code that runs in the same process as Galaxy's central server. It shouldn't infect anyone's software with the AGPL license any more than the Linux kernel infects user processes with the GPL license.

Ron

On Tuesday, September 29, 2015 at 12:24:33 PM UTC+3, Sergey Stupin wrote:

Hello, guys!

First of all I wanted to thank you for creating Galaxy. It is a really brave attempt to solve complex distributed problems but as we can see Galaxy is not actively developed at this moment. So I would like to know are there any further plans in supporting Galaxy? 

p.s. Imho is it's not stable enough to be a production ready solution because even in our test environments we've got some strange runtime exceptions, SQL persistency don't work and not tested at all (unfortunately BerkeleyDB has unsuitable licence for us). And is seems that test coverage should be much larger for such a complex framework. Please take my words easy, I just want to help if I can. 

Again just wanted to mention Galaxy has reasonable design principles and nice quasar-actors integration, and it could become best in place framework for distributed JVM actors if someone could pay more attention to it. 

Thanks.

--
You received this message because you are subscribed to a topic in the Google Groups "galaxy-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/galaxy-user/uNIJ8SDhUuY/unsubscribe.

To unsubscribe from this group and all its topics, send an email to galaxy-user+unsubscribe@googlegroups.com.

To post to this group, send email to galax...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/galaxy-user/f1f68ca7-0571-48ec-8d16-08282b1fec7d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.