Rio versions

[Zsolt Kúti]

Hello Denis,

The list is a bit quiet recently let's stirr it up a little :-)

There was a change around Sun's internal Logging.Level that caused
Jini and hence Rio to throw exception
(https://issues.apache.org/jira/browse/RIVER-416) and a quick fix in
River was released. We use Rio 4.2, but that was released earlier and
has probably a before-fix version of River. So we use 4.2 with a Java
version that does not show the sympthoms, but it is not too healthy.
We are seeking a remedy for the situation. Two options I see is to
keep using 4.2 by changing to fixed JINI/River code, or switching to
5.x.
As to the latter, how smooth is the transition to 5.x? Is there a
description what's new and possible breaking changes?
As to the former can we safely try changing jars under lib and
lib-dl? Anything else to be aware of?

Thanks!

Zsolt

[Dennis Reedy]

Hi Zsolt,

I'd recommend moving to 5.0-M4, there has been tons of bug fixes and enhancements along the way. When this issue first came up, I developed an Ant script to assist in the upgrade. I haven;t run it in a bit, but if you do want to deal with some package name modification in your code, this would be the easiest way to do that.

Also, if your code does use Java util logging, I'd recommend changing that over to SLF4J, with Rio 5.x, thats the default logging approach. I've attached the Ant script for you here, I hope it helps.

Regards

Dennis

[Zsolt Kúti]

Thanks, Dennis!

Then version change is certainly something we have to do in the near
future.
Till then we stick with what we have now.

Zsolt

[Dawid Loubser]

We've been happily running 5.0-M4 for quite some time now (running a
JavaSpaces-based corporate travel approval system, servicing a couple of
major companies here in South Africa) - I can highly recommend it. We
haven't had a single crash or problem caused by Rio itself (we did kill
Blitz JavaSpaces once or twice, which takes some doing...).

kind regard,
Dawid Loubser

[Zsolt Kúti]

On Thu, 19 Jun 2014 11:00:25 +0200
Dawid Loubser <dawid....@gmail.com> wrote:


> We've been happily running 5.0-M4 for quite some time now (running a
> JavaSpaces-based corporate travel approval system, servicing a
> couple of
> major companies here in South Africa) - I can highly recommend it. We
> haven't had a single crash or problem caused by Rio itself (we did
> kill

Dawid, thanks for the (re)assuring words :-)

> Blitz JavaSpaces once or twice, which takes some doing...).

While we are at it, can you shed some light on what was the driving
force to use Blitz instead of the default?


Zsolt

[Dawid Loubser]

On 19/06/2014 11:19, Zsolt Kúti wrote:
> Blitz JavaSpaces once or twice, which takes some doing...).
> While we are at it, can you shed some light on what was the driving
> force to use Blitz instead of the default?

Persistent Outrigger rapidly slowed down to a crawl and crashed with our
data volumes.
In-memory Outrigger handled it fine, but these are long-running
processes (something weeks) where we could not afford to lose the
process state.

The issue was not, I think, the overall size (around 4GB), but the fact
that our entries were very large / complex domain objects - sometimes up
to 1MB each. One could argue that our design was not ideal for what
Outrigger caters for, but I wanted to go for a pure space-based
solution, as opposed to storing the larger objects in some other storage
medium.

Some people use JavaSpaces either as a cache, or as a means to
distribute requests to manage workload. In our case, we are using it to
represent the state of some complex, long-running processes, so
durability of that state is important to us. Blitz certainly slows down
badly when you hit 10GB or so (and has a startup time of several minutes
to load that state from disk), but since this is just "active" process
state (we're not using it as a historical database, which really goes
against the idea of JavaSpaces) we will deal with that problem when we
hit those volumes.

What you are you building with JavaSpaces, if you don't mind sharing?

kind regards,
Dawid Loubser

[Zsolt Kúti]

On Thu, 19 Jun 2014 11:43:28 +0200
Dawid Loubser <dawid....@gmail.com> wrote:


> Persistent Outrigger rapidly slowed down to a crawl and crashed with
> our
> data volumes.
> In-memory Outrigger handled it fine, but these are long-running
> processes (something weeks) where we could not afford to lose the
> process state.

...

Thank you for your nice explanation, one can hardly hear what others
do with River.

> What you are you building with JavaSpaces, if you don't mind sharing?

Its purpose in our system is to help coordination among services
(minimal at present) and a means to facilitate distribution of load.
While the load is low at present that would not immediately require
this feature, it is definitly something that needs to be part of the
architecture. Our system should scale with the data coming from the
field and should be able to cope with the growing processing needs.

Zsolt

[Dennis Reedy]

Zsolt,

You may also be interested in using Rio's association management capabilities for accessing a pool of associated services. You can use round-robin, utilization based, or custom approach to dictate how services are used,

I'd go into more detail, but I'm entering thus using my iPhone at the moment.

Dennis



Sent from my iPhone

> --
> You received this message because you are subscribed to the Google Groups "Rio Users Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to rio-users+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Zsolt Kúti]

On Thu, 19 Jun 2014 07:38:20 -0400
Dennis Reedy <dennis...@gmail.com> wrote:


> Zsolt,

>

> You may also be interested in using Rio's association management
> capabilities for accessing a pool of associated services. You can use
> round-robin, utilization based, or custom approach to dictate how
> services are used,

AssociationManagement is already used to get AssociationS for service
dependencies. Although only single service instances are configured at
present, the above will allow smooth configuration changes to multiple
instances. I guess you referred to this, did you?

Thanks

Zsolt

[Dawid Loubser]

Agreed, it's great how Rio effectively gives you two options to achieve load balancing (as I see it):

• Rio Associations as a form of "push" load balancing, where it ensures that a services has an association to another service, where that other service continuously meets certain qualities (i.e. implied performance because of low load level, etc).
• JavaSpaces are a more natural "pull" form of load balancing, but you lose out on the key aspects of services-oriented architecture (components at different levels of granularity, each implementing some contract, and making use of other services via their contracts).
  

I can say from experiencing that building a purely space-based system as we have (across all 'levels of granularity' - although such levels don't physically exist, all workers exist on a flat plane, connected to the space) is distinctly weird. With the framework I've built, which takes some inspiration from functional programming a-la Haskell, it has some nice attributes, but it's certainly difficult to test, or reason about, the total behaviour of the system (as opposed to individual workflow steps, which are pure and simple).

Unless anybody really knows what they are doing, I would recommend sticking to the more classical contract-driven, top-down, services-oriented architecture. Ironically, I don't have a lot of experience in Rio building such systems (since we are heavy OSGi users), we started using Rio specifically for our space-based system. Would love to build a good Rio services-based SOA someday when the requirements call for it.

In our system, we can incur total failure at any point in the process without losing any process state (unless the JavaSpace dies, then the universe collapses) - which is a nice quality to have. A Rio-services-based SOA would require considerably more work within each service to never lose any workflow state / repeat any steps, but as a whole, has to ability to nicely evolve / heal itself as the environment or demands change, which is quite unique.

Those of you here also on the Jini (River) mailing list would know that the future of River is in a state of flux, and I am eager to see what direction it takes.

Thanks again Dennis, for your amazing work -
Dawid Loubser

[Zsolt Kúti]

I like your formulation of push/pull here.
The implicit service contract for pull is especially familiar pain.
Here the workflow is represented by the entries and JS clients involved,
the contract by entries' structure (fields). Even with a few clients to
follow my workflow I keep checking what entries are used by which
parties.
Also found useful your description regarding state persistence.

Thanks for sharing your thoughts.

Zsolt

On Thu, 19 Jun 2014 14:47:34 +0200
Dawid Loubser <dawid....@gmail.com> wrote:


> Agreed, it's great how Rio effectively gives you two options to
> achieve
> load balancing (as I see it):

...