You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Palash Ray <pa...@gmail.com> on 2015/06/02 04:44:17 UTC
Mirroring to GitHub
Hi Devs,
We use lot of Jini as our middleware platform across various applications
in our organisations.
I see that there has been no activity for the last couple of years. To
spurt interest in this wonderful, and powerful project, we can actually
mirror it on github like Apache JMeter has done.
Please let me know your thoughts on this?
Thanks,
Palash.
Re: Mirroring to GitHub
Posted by Patricia Shanahan <pa...@acm.org>.
Greg Trasuk has already responded on the specifics. I am going to
comment on fixing the apparent lack of activity.
To make things happen, we need more developers.
The current activity is checking the
river/jtsk/skunk/qa-refactor-namespace branch as a basis for an upcoming
release. See the recent "[Vote] Namespace change from com.sun.jini and
com.artima to org.apache.river" thread in this mailing list. The more
people examining and testing it the better.
Please do anything you can to get the word out to people who might be
willing to help with Jini development.
Thanks for any help,
Patricia
On 6/1/2015 7:44 PM, Palash Ray wrote:
> Hi Devs,
>
> We use lot of Jini as our middleware platform across various applications
> in our organisations.
>
> I see that there has been no activity for the last couple of years. To
> spurt interest in this wonderful, and powerful project, we can actually
> mirror it on github like Apache JMeter has done.
>
> Please let me know your thoughts on this?
>
> Thanks,
> Palash.
>
Re: Clustered Jini Server? Was: Re: Mirroring to GitHub
Posted by Gregg Wonderly <gr...@gmail.com>.
Greg is on point here. You really should consider a Java Space (look at Dan Creswell's Blitz, [http://www.dancres.org/blitz/, for a very performant implementation). Your clients would then put requests for work into the Javaspace. Worker machines that you can add as many as you want of, would consume Entry’s from the Javaspace, do the work, and then put the results into the database and return a “work done” Entry to the Javaspace. Your clients would then see the entry arrive and proceed.
Gregg Wonderly
> On Jun 3, 2015, at 9:15 AM, Greg Trasuk <tr...@stratuscom.com> wrote:
>
>
>> On Jun 3, 2015, at 7:42 AM, Palash Ray <pa...@gmail.com> wrote:
>>
>> Interesting thought about using Java Spaces. However, for us, there is an
>> extra maintenance of the Java Spaces server in production, which is my
>> worry. Moreover, in our application, it is always a synchronous call from
>> the Swing client to the Jini server. It would be a lot of effort to make
>> this an asynchronous call to Java Sapces. So for our kind of application,
>> this would not be suitable.
>>
>
> What I’ve done in the past is have an RPC-based service that interacts with the JavaSpace (sort of an orchestration service). That way the UI can have a simplified interface mechanism, but you can still get the load-balancing aspects of the JavaSpace. Something like the River Container can host multiple services like the orchestration service and task executor services (JavaSpace workers) quite trivially. Put multiple copies of that instance on the network to scale the workers. Then you have another River Container instance that hosts your Java Space, Registrar and Transaction Manager services (i.e. your Jini infrastructure). In the case of River Container, it automatically adapts to multiple containers on one node (it auto-selects ports for the codebase server, etc), so you can develop and deploy in a flexible fashion.
>
> The above can also be done with the ServiceStarter framework, but with more manual config. No doubt Rio can manage trivially as well.
>
> Cheers,
>
> Greg Trasuk
>
>> Thanks,
>> Palash.
>>
>> On Wed, Jun 3, 2015 at 1:14 AM, Simon Roberts <
>> simon@dancingcloudservices.com> wrote:
>>
>>> Hard to be sure if this is a sensible comment without knowing more about
>>> what you're trying to do, but the typical "load balance" in a Jini
>>> environment has traditionally been a Java Spaces server, into which "jobs"
>>> (probably simply Runnable implementations) are placed. The clustered work
>>> engines are configured to take (in a transaction) a job from the space,
>>> process it, and put it back with an attribute indicating completion. On
>>> putting the job back, the original take transaction is committed.
>>> Therefore, if the server crashes before the job is completed, the "take"
>>> evaporates, and some other work engine gets to re-take, hopefully
>>> completing successfully. This model allows any number of work engines to be
>>> load balanced for essentially zero communication between them, and no
>>> actual load balancer exists (in the sense that no active component has to
>>> keep track of the work engines). The workers take as fast at they're able
>>> to do work, but no faster, so they don't get overloaded. You can bring
>>> workers up, and shut them down, with zero reconfiguration.
>>>
>>> Cheers,
>>> Simon
>>>
>>>
>>> On Tue, Jun 2, 2015 at 8:13 PM, Palash Ray <pa...@gmail.com> wrote:
>>>
>>>> Thanks Dennis, I will definitely explore that option.
>>>>
>>>> On Tue, Jun 2, 2015 at 9:37 PM, Dennis Reedy <de...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Palash,
>>>>>
>>>>> Using reggie as a load balancer does not make the most sense, what you
>>>> may
>>>>> want to consider to to maintain a collection of discovered services and
>>>>> simply round robin across them. You might want to start looking at the
>>>>> ServiceDiscoveryManager and the LookupCache for this.
>>>>>
>>>>> HTH
>>>>>
>>>>> Dennis
>>>>>
>>>>>
>>>>> On Tue, Jun 2, 2015 at 9:16 PM, Palash Ray <pa...@gmail.com> wrote:
>>>>>
>>>>>> Excellent. May be we can help each other here.
>>>>>>
>>>>>> Let me start by giving some more context around the problem.
>>>>>>
>>>>>> *Problem*
>>>>>> Our middle tier that is a Jini-based rmi server. We have a Swing
>>> client
>>>>>> that connects to it. In the middle tier, we have lot of processing
>>>> logic:
>>>>>> fetch something from the database, do some calculation intensive
>>>>>> processing, write the results back to the database.
>>>>>>
>>>>>> Of late there has been a huge increase of the loads: the no. of Swing
>>>>>> clients has increased, as has the bulk of the data to be processed.
>>> It
>>>>> has
>>>>>> come to a point, where our production server, which is a single
>>>> machine,
>>>>> is
>>>>>> creaking under the load.
>>>>>>
>>>>>> So, we have decided to cluster it. We are planning to have at least 3
>>>> or
>>>>> 4
>>>>>> Jini servers and a load balancer to spread out the load evenly.
>>>>>>
>>>>>> I was doing a proof of concept using the Jini infrasctrure itself.
>>>> These
>>>>>> were my thoughts:
>>>>>>
>>>>>> *Option 1*
>>>>>>
>>>>>>
>>>>>
>>>>
>>> https://github.com/paawak/blog/tree/master/code/jini/unsecure/load-balancing
>>>>>>
>>>>>> The load balancing architecture here is very very simple. There is a
>>>>>> single load balancer with its own reggie running at 6670. This is the
>>>>>> primary contact point for all clients.
>>>>>>
>>>>>> There are multiple reggie involved for load balancing. The following
>>>>>> convention is followed:
>>>>>>
>>>>>> 1. The reggie for load balancer is at 6670
>>>>>> 2. The reggie for the actual jini servers are at 5561, 5562, 5563,
>>> etc.
>>>>>>
>>>>>> When the load-balancer recieves a request from client, it does the
>>>>>> look-up at the appropriate jini-server and returns the remote
>>> service.
>>>>>>
>>>>>> *Option 2*
>>>>>> https://github.com/paawak/jini-in-a-war
>>>>>>
>>>>>> I figured that if we can embed the Jini in a Tomcat and then
>>> clustering
>>>>> the
>>>>>> Tomcat would be very easy. But this is still work in progress, and
>>>> there
>>>>>> are lot of details that I need to figure out.
>>>>>>
>>>>>> Please let me know if the above makes sense or is around the same
>>>> things
>>>>>> that interest you. I would like to have a out of the box Jini
>>> solution
>>>>>> that *just
>>>>>> works*. And I am happy to code for any solution that you guys think
>>>>> should
>>>>>> be the way forward.
>>>>>>
>>>>>> Thanks,
>>>>>> Palash.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Jun 2, 2015 at 2:14 PM, Patricia Shanahan <pa...@acm.org>
>>>> wrote:
>>>>>>
>>>>>>> Also, if there is any chance the bottleneck is in River, I would be
>>>>> very,
>>>>>>> very interested in constructing a benchmark based on your workload
>>>> that
>>>>>>> demonstrates the scaling problem. I would like to run it against
>>> the
>>>>>> latest
>>>>>>> unreleased version, which I think may fix some scaling issues. If
>>> it
>>>>>> still
>>>>>>> shows scaling problems, I want to track them down and see whether
>>>> they
>>>>>> are
>>>>>>> fixable without clustering.
>>>>>>>
>>>>>>> My most recent professional background, before retiring, was as a
>>>>>>> performance architect working on multiprocessor servers for Cray
>>>>> Research
>>>>>>> and Sun Microsystems. When I first got involved in River I was
>>>> thinking
>>>>>> of
>>>>>>> doing some performance analysis and improvement, one of my favorite
>>>>>> games,
>>>>>>> but could not find a suitable benchmark, or an actual user with a
>>>>> scaling
>>>>>>> problem.
>>>>>>>
>>>>>>> Patricia
>>>>>>>
>>>>>>>
>>>>>>> On 6/2/2015 10:24 AM, Greg Trasuk wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> Palash:
>>>>>>>>
>>>>>>>> Could you expand on your need for a “clustered Jini server”? What
>>>>>>>> features are you looking for, and what aspects of the application
>>>> need
>>>>>> to
>>>>>>>> be clustered? This might provide fertile grounds for development.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Greg Trasuk
>>>>>>>>
>>>>>>>> On Jun 2, 2015, at 12:38 PM, Palash Ray <pa...@gmail.com>
>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi Greg, Patricia,
>>>>>>>>>
>>>>>>>>> Really happy to see:
>>>>>>>>> https://github.com/trasukg/river-container
>>>>>>>>>
>>>>>>>>> I think we are off in the right direction. I have been using
>>> river
>>>>> for
>>>>>>>>> almost 2 years now, but only recently started taking an interest
>>> in
>>>>>>>>> the code that makes it tick.
>>>>>>>>>
>>>>>>>>> Our organisation is facing some scalability issues with Jini of
>>>> late,
>>>>>>>>> well, I am not blaming Jini here, its just that we need a
>>> clustered
>>>>>>>>> Jini server.
>>>>>>>>>
>>>>>>>>> To that end I was playing around the code a bit. I have some
>>> ideas
>>>>>>>>> which I can discuss with this group later.
>>>>>>>>>
>>>>>>>>> I have created a small proof of concept of embedding Jini in a
>>> war
>>>>> and
>>>>>>>>> running it in a webserver:
>>>>>>>>> https://github.com/paawak/jini-in-a-war
>>>>>>>>>
>>>>>>>>> Also, I keep blogging about Jini with whatever little
>>>> understanding I
>>>>>>>>> have:
>>>>>>>>> http://palashray.com/java/jini/
>>>>>>>>>
>>>>>>>>> In the coming days, I look forward to contributing to the river
>>>>>> project.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Palash.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 6/2/15, Greg Trasuk <tr...@stratuscom.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks, Jukka. And by the way, I’m happy to see you’re still
>>>>> watching
>>>>>>>>>> River!
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>>
>>>>>>>>>> Greg Trasuk.
>>>>>>>>>>
>>>>>>>>>> On Jun 2, 2015, at 11:14 AM, Jukka Zitting <
>>>>> jukka.zitting@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> 2015-06-02 1:17 GMT-04:00 Greg Trasuk <trasukg@stratuscom.com
>>>> :
>>>>>>>>>>>
>>>>>>>>>>>> I notice that for some reason, the 2.1 branch shows up as
>>>> current,
>>>>>> so
>>>>>>>>>>>> you
>>>>>>>>>>>> need to switch
>>>>>>>>>>>> to the 2.2 branch explicitly to see the latest releases. I’m
>>>> not
>>>>>> sure
>>>>>>>>>>>> how to change that.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> You can file an INFRA issue to get the default branch and other
>>>>>> GitHub
>>>>>>>>>>> metadata changed.
>>>>>>>>>>>
>>>>>>>>>>> Jukka
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Simon Roberts
>>> (303) 249 3613
>>>
>
Re: Clustered Jini Server? Was: Re: Mirroring to GitHub
Posted by Greg Trasuk <tr...@stratuscom.com>.
> On Jun 3, 2015, at 7:42 AM, Palash Ray <pa...@gmail.com> wrote:
>
> Interesting thought about using Java Spaces. However, for us, there is an
> extra maintenance of the Java Spaces server in production, which is my
> worry. Moreover, in our application, it is always a synchronous call from
> the Swing client to the Jini server. It would be a lot of effort to make
> this an asynchronous call to Java Sapces. So for our kind of application,
> this would not be suitable.
>
What I’ve done in the past is have an RPC-based service that interacts with the JavaSpace (sort of an orchestration service). That way the UI can have a simplified interface mechanism, but you can still get the load-balancing aspects of the JavaSpace. Something like the River Container can host multiple services like the orchestration service and task executor services (JavaSpace workers) quite trivially. Put multiple copies of that instance on the network to scale the workers. Then you have another River Container instance that hosts your Java Space, Registrar and Transaction Manager services (i.e. your Jini infrastructure). In the case of River Container, it automatically adapts to multiple containers on one node (it auto-selects ports for the codebase server, etc), so you can develop and deploy in a flexible fashion.
The above can also be done with the ServiceStarter framework, but with more manual config. No doubt Rio can manage trivially as well.
Cheers,
Greg Trasuk
> Thanks,
> Palash.
>
> On Wed, Jun 3, 2015 at 1:14 AM, Simon Roberts <
> simon@dancingcloudservices.com> wrote:
>
>> Hard to be sure if this is a sensible comment without knowing more about
>> what you're trying to do, but the typical "load balance" in a Jini
>> environment has traditionally been a Java Spaces server, into which "jobs"
>> (probably simply Runnable implementations) are placed. The clustered work
>> engines are configured to take (in a transaction) a job from the space,
>> process it, and put it back with an attribute indicating completion. On
>> putting the job back, the original take transaction is committed.
>> Therefore, if the server crashes before the job is completed, the "take"
>> evaporates, and some other work engine gets to re-take, hopefully
>> completing successfully. This model allows any number of work engines to be
>> load balanced for essentially zero communication between them, and no
>> actual load balancer exists (in the sense that no active component has to
>> keep track of the work engines). The workers take as fast at they're able
>> to do work, but no faster, so they don't get overloaded. You can bring
>> workers up, and shut them down, with zero reconfiguration.
>>
>> Cheers,
>> Simon
>>
>>
>> On Tue, Jun 2, 2015 at 8:13 PM, Palash Ray <pa...@gmail.com> wrote:
>>
>>> Thanks Dennis, I will definitely explore that option.
>>>
>>> On Tue, Jun 2, 2015 at 9:37 PM, Dennis Reedy <de...@gmail.com>
>>> wrote:
>>>
>>>> Hi Palash,
>>>>
>>>> Using reggie as a load balancer does not make the most sense, what you
>>> may
>>>> want to consider to to maintain a collection of discovered services and
>>>> simply round robin across them. You might want to start looking at the
>>>> ServiceDiscoveryManager and the LookupCache for this.
>>>>
>>>> HTH
>>>>
>>>> Dennis
>>>>
>>>>
>>>> On Tue, Jun 2, 2015 at 9:16 PM, Palash Ray <pa...@gmail.com> wrote:
>>>>
>>>>> Excellent. May be we can help each other here.
>>>>>
>>>>> Let me start by giving some more context around the problem.
>>>>>
>>>>> *Problem*
>>>>> Our middle tier that is a Jini-based rmi server. We have a Swing
>> client
>>>>> that connects to it. In the middle tier, we have lot of processing
>>> logic:
>>>>> fetch something from the database, do some calculation intensive
>>>>> processing, write the results back to the database.
>>>>>
>>>>> Of late there has been a huge increase of the loads: the no. of Swing
>>>>> clients has increased, as has the bulk of the data to be processed.
>> It
>>>> has
>>>>> come to a point, where our production server, which is a single
>>> machine,
>>>> is
>>>>> creaking under the load.
>>>>>
>>>>> So, we have decided to cluster it. We are planning to have at least 3
>>> or
>>>> 4
>>>>> Jini servers and a load balancer to spread out the load evenly.
>>>>>
>>>>> I was doing a proof of concept using the Jini infrasctrure itself.
>>> These
>>>>> were my thoughts:
>>>>>
>>>>> *Option 1*
>>>>>
>>>>>
>>>>
>>>
>> https://github.com/paawak/blog/tree/master/code/jini/unsecure/load-balancing
>>>>>
>>>>> The load balancing architecture here is very very simple. There is a
>>>>> single load balancer with its own reggie running at 6670. This is the
>>>>> primary contact point for all clients.
>>>>>
>>>>> There are multiple reggie involved for load balancing. The following
>>>>> convention is followed:
>>>>>
>>>>> 1. The reggie for load balancer is at 6670
>>>>> 2. The reggie for the actual jini servers are at 5561, 5562, 5563,
>> etc.
>>>>>
>>>>> When the load-balancer recieves a request from client, it does the
>>>>> look-up at the appropriate jini-server and returns the remote
>> service.
>>>>>
>>>>> *Option 2*
>>>>> https://github.com/paawak/jini-in-a-war
>>>>>
>>>>> I figured that if we can embed the Jini in a Tomcat and then
>> clustering
>>>> the
>>>>> Tomcat would be very easy. But this is still work in progress, and
>>> there
>>>>> are lot of details that I need to figure out.
>>>>>
>>>>> Please let me know if the above makes sense or is around the same
>>> things
>>>>> that interest you. I would like to have a out of the box Jini
>> solution
>>>>> that *just
>>>>> works*. And I am happy to code for any solution that you guys think
>>>> should
>>>>> be the way forward.
>>>>>
>>>>> Thanks,
>>>>> Palash.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jun 2, 2015 at 2:14 PM, Patricia Shanahan <pa...@acm.org>
>>> wrote:
>>>>>
>>>>>> Also, if there is any chance the bottleneck is in River, I would be
>>>> very,
>>>>>> very interested in constructing a benchmark based on your workload
>>> that
>>>>>> demonstrates the scaling problem. I would like to run it against
>> the
>>>>> latest
>>>>>> unreleased version, which I think may fix some scaling issues. If
>> it
>>>>> still
>>>>>> shows scaling problems, I want to track them down and see whether
>>> they
>>>>> are
>>>>>> fixable without clustering.
>>>>>>
>>>>>> My most recent professional background, before retiring, was as a
>>>>>> performance architect working on multiprocessor servers for Cray
>>>> Research
>>>>>> and Sun Microsystems. When I first got involved in River I was
>>> thinking
>>>>> of
>>>>>> doing some performance analysis and improvement, one of my favorite
>>>>> games,
>>>>>> but could not find a suitable benchmark, or an actual user with a
>>>> scaling
>>>>>> problem.
>>>>>>
>>>>>> Patricia
>>>>>>
>>>>>>
>>>>>> On 6/2/2015 10:24 AM, Greg Trasuk wrote:
>>>>>>
>>>>>>>
>>>>>>> Palash:
>>>>>>>
>>>>>>> Could you expand on your need for a “clustered Jini server”? What
>>>>>>> features are you looking for, and what aspects of the application
>>> need
>>>>> to
>>>>>>> be clustered? This might provide fertile grounds for development.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Greg Trasuk
>>>>>>>
>>>>>>> On Jun 2, 2015, at 12:38 PM, Palash Ray <pa...@gmail.com>
>> wrote:
>>>>>>>>
>>>>>>>> Hi Greg, Patricia,
>>>>>>>>
>>>>>>>> Really happy to see:
>>>>>>>> https://github.com/trasukg/river-container
>>>>>>>>
>>>>>>>> I think we are off in the right direction. I have been using
>> river
>>>> for
>>>>>>>> almost 2 years now, but only recently started taking an interest
>> in
>>>>>>>> the code that makes it tick.
>>>>>>>>
>>>>>>>> Our organisation is facing some scalability issues with Jini of
>>> late,
>>>>>>>> well, I am not blaming Jini here, its just that we need a
>> clustered
>>>>>>>> Jini server.
>>>>>>>>
>>>>>>>> To that end I was playing around the code a bit. I have some
>> ideas
>>>>>>>> which I can discuss with this group later.
>>>>>>>>
>>>>>>>> I have created a small proof of concept of embedding Jini in a
>> war
>>>> and
>>>>>>>> running it in a webserver:
>>>>>>>> https://github.com/paawak/jini-in-a-war
>>>>>>>>
>>>>>>>> Also, I keep blogging about Jini with whatever little
>>> understanding I
>>>>>>>> have:
>>>>>>>> http://palashray.com/java/jini/
>>>>>>>>
>>>>>>>> In the coming days, I look forward to contributing to the river
>>>>> project.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Palash.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 6/2/15, Greg Trasuk <tr...@stratuscom.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks, Jukka. And by the way, I’m happy to see you’re still
>>>> watching
>>>>>>>>> River!
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>>
>>>>>>>>> Greg Trasuk.
>>>>>>>>>
>>>>>>>>> On Jun 2, 2015, at 11:14 AM, Jukka Zitting <
>>>> jukka.zitting@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> 2015-06-02 1:17 GMT-04:00 Greg Trasuk <trasukg@stratuscom.com
>>> :
>>>>>>>>>>
>>>>>>>>>>> I notice that for some reason, the 2.1 branch shows up as
>>> current,
>>>>> so
>>>>>>>>>>> you
>>>>>>>>>>> need to switch
>>>>>>>>>>> to the 2.2 branch explicitly to see the latest releases. I’m
>>> not
>>>>> sure
>>>>>>>>>>> how to change that.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> You can file an INFRA issue to get the default branch and other
>>>>> GitHub
>>>>>>>>>> metadata changed.
>>>>>>>>>>
>>>>>>>>>> Jukka
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>> --
>> Simon Roberts
>> (303) 249 3613
>>
Re: Clustered Jini Server? Was: Re: Mirroring to GitHub
Posted by Greg Trasuk <tr...@stratuscom.com>.
There’s never a bad time to point out the excellent Jiniology series that’s still up on Artima.com <http://artima.com/>:
http://www.artima.com/jini/jiniology/index.html <http://www.artima.com/jini/jiniology/index.html>
In particular, the explanation of JavaSpaces:
http://www.artima.com/jini/jiniology/js1.html <http://www.artima.com/jini/jiniology/js1.html>
Cheers,
Greg Trasuk
> On Jun 3, 2015, at 7:42 AM, Palash Ray <pa...@gmail.com> wrote:
>
> Interesting thought about using Java Spaces. However, for us, there is an
> extra maintenance of the Java Spaces server in production, which is my
> worry. Moreover, in our application, it is always a synchronous call from
> the Swing client to the Jini server. It would be a lot of effort to make
> this an asynchronous call to Java Sapces. So for our kind of application,
> this would not be suitable.
>
> Thanks,
> Palash.
>
> On Wed, Jun 3, 2015 at 1:14 AM, Simon Roberts <
> simon@dancingcloudservices.com> wrote:
>
>> Hard to be sure if this is a sensible comment without knowing more about
>> what you're trying to do, but the typical "load balance" in a Jini
>> environment has traditionally been a Java Spaces server, into which "jobs"
>> (probably simply Runnable implementations) are placed. The clustered work
>> engines are configured to take (in a transaction) a job from the space,
>> process it, and put it back with an attribute indicating completion. On
>> putting the job back, the original take transaction is committed.
>> Therefore, if the server crashes before the job is completed, the "take"
>> evaporates, and some other work engine gets to re-take, hopefully
>> completing successfully. This model allows any number of work engines to be
>> load balanced for essentially zero communication between them, and no
>> actual load balancer exists (in the sense that no active component has to
>> keep track of the work engines). The workers take as fast at they're able
>> to do work, but no faster, so they don't get overloaded. You can bring
>> workers up, and shut them down, with zero reconfiguration.
>>
>> Cheers,
>> Simon
>>
>>
>> On Tue, Jun 2, 2015 at 8:13 PM, Palash Ray <pa...@gmail.com> wrote:
>>
>>> Thanks Dennis, I will definitely explore that option.
>>>
>>> On Tue, Jun 2, 2015 at 9:37 PM, Dennis Reedy <de...@gmail.com>
>>> wrote:
>>>
>>>> Hi Palash,
>>>>
>>>> Using reggie as a load balancer does not make the most sense, what you
>>> may
>>>> want to consider to to maintain a collection of discovered services and
>>>> simply round robin across them. You might want to start looking at the
>>>> ServiceDiscoveryManager and the LookupCache for this.
>>>>
>>>> HTH
>>>>
>>>> Dennis
>>>>
>>>>
>>>> On Tue, Jun 2, 2015 at 9:16 PM, Palash Ray <pa...@gmail.com> wrote:
>>>>
>>>>> Excellent. May be we can help each other here.
>>>>>
>>>>> Let me start by giving some more context around the problem.
>>>>>
>>>>> *Problem*
>>>>> Our middle tier that is a Jini-based rmi server. We have a Swing
>> client
>>>>> that connects to it. In the middle tier, we have lot of processing
>>> logic:
>>>>> fetch something from the database, do some calculation intensive
>>>>> processing, write the results back to the database.
>>>>>
>>>>> Of late there has been a huge increase of the loads: the no. of Swing
>>>>> clients has increased, as has the bulk of the data to be processed.
>> It
>>>> has
>>>>> come to a point, where our production server, which is a single
>>> machine,
>>>> is
>>>>> creaking under the load.
>>>>>
>>>>> So, we have decided to cluster it. We are planning to have at least 3
>>> or
>>>> 4
>>>>> Jini servers and a load balancer to spread out the load evenly.
>>>>>
>>>>> I was doing a proof of concept using the Jini infrasctrure itself.
>>> These
>>>>> were my thoughts:
>>>>>
>>>>> *Option 1*
>>>>>
>>>>>
>>>>
>>>
>> https://github.com/paawak/blog/tree/master/code/jini/unsecure/load-balancing
>>>>>
>>>>> The load balancing architecture here is very very simple. There is a
>>>>> single load balancer with its own reggie running at 6670. This is the
>>>>> primary contact point for all clients.
>>>>>
>>>>> There are multiple reggie involved for load balancing. The following
>>>>> convention is followed:
>>>>>
>>>>> 1. The reggie for load balancer is at 6670
>>>>> 2. The reggie for the actual jini servers are at 5561, 5562, 5563,
>> etc.
>>>>>
>>>>> When the load-balancer recieves a request from client, it does the
>>>>> look-up at the appropriate jini-server and returns the remote
>> service.
>>>>>
>>>>> *Option 2*
>>>>> https://github.com/paawak/jini-in-a-war
>>>>>
>>>>> I figured that if we can embed the Jini in a Tomcat and then
>> clustering
>>>> the
>>>>> Tomcat would be very easy. But this is still work in progress, and
>>> there
>>>>> are lot of details that I need to figure out.
>>>>>
>>>>> Please let me know if the above makes sense or is around the same
>>> things
>>>>> that interest you. I would like to have a out of the box Jini
>> solution
>>>>> that *just
>>>>> works*. And I am happy to code for any solution that you guys think
>>>> should
>>>>> be the way forward.
>>>>>
>>>>> Thanks,
>>>>> Palash.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jun 2, 2015 at 2:14 PM, Patricia Shanahan <pa...@acm.org>
>>> wrote:
>>>>>
>>>>>> Also, if there is any chance the bottleneck is in River, I would be
>>>> very,
>>>>>> very interested in constructing a benchmark based on your workload
>>> that
>>>>>> demonstrates the scaling problem. I would like to run it against
>> the
>>>>> latest
>>>>>> unreleased version, which I think may fix some scaling issues. If
>> it
>>>>> still
>>>>>> shows scaling problems, I want to track them down and see whether
>>> they
>>>>> are
>>>>>> fixable without clustering.
>>>>>>
>>>>>> My most recent professional background, before retiring, was as a
>>>>>> performance architect working on multiprocessor servers for Cray
>>>> Research
>>>>>> and Sun Microsystems. When I first got involved in River I was
>>> thinking
>>>>> of
>>>>>> doing some performance analysis and improvement, one of my favorite
>>>>> games,
>>>>>> but could not find a suitable benchmark, or an actual user with a
>>>> scaling
>>>>>> problem.
>>>>>>
>>>>>> Patricia
>>>>>>
>>>>>>
>>>>>> On 6/2/2015 10:24 AM, Greg Trasuk wrote:
>>>>>>
>>>>>>>
>>>>>>> Palash:
>>>>>>>
>>>>>>> Could you expand on your need for a “clustered Jini server”? What
>>>>>>> features are you looking for, and what aspects of the application
>>> need
>>>>> to
>>>>>>> be clustered? This might provide fertile grounds for development.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Greg Trasuk
>>>>>>>
>>>>>>> On Jun 2, 2015, at 12:38 PM, Palash Ray <pa...@gmail.com>
>> wrote:
>>>>>>>>
>>>>>>>> Hi Greg, Patricia,
>>>>>>>>
>>>>>>>> Really happy to see:
>>>>>>>> https://github.com/trasukg/river-container
>>>>>>>>
>>>>>>>> I think we are off in the right direction. I have been using
>> river
>>>> for
>>>>>>>> almost 2 years now, but only recently started taking an interest
>> in
>>>>>>>> the code that makes it tick.
>>>>>>>>
>>>>>>>> Our organisation is facing some scalability issues with Jini of
>>> late,
>>>>>>>> well, I am not blaming Jini here, its just that we need a
>> clustered
>>>>>>>> Jini server.
>>>>>>>>
>>>>>>>> To that end I was playing around the code a bit. I have some
>> ideas
>>>>>>>> which I can discuss with this group later.
>>>>>>>>
>>>>>>>> I have created a small proof of concept of embedding Jini in a
>> war
>>>> and
>>>>>>>> running it in a webserver:
>>>>>>>> https://github.com/paawak/jini-in-a-war
>>>>>>>>
>>>>>>>> Also, I keep blogging about Jini with whatever little
>>> understanding I
>>>>>>>> have:
>>>>>>>> http://palashray.com/java/jini/
>>>>>>>>
>>>>>>>> In the coming days, I look forward to contributing to the river
>>>>> project.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Palash.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 6/2/15, Greg Trasuk <tr...@stratuscom.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks, Jukka. And by the way, I’m happy to see you’re still
>>>> watching
>>>>>>>>> River!
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>>
>>>>>>>>> Greg Trasuk.
>>>>>>>>>
>>>>>>>>> On Jun 2, 2015, at 11:14 AM, Jukka Zitting <
>>>> jukka.zitting@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> 2015-06-02 1:17 GMT-04:00 Greg Trasuk <trasukg@stratuscom.com
>>> :
>>>>>>>>>>
>>>>>>>>>>> I notice that for some reason, the 2.1 branch shows up as
>>> current,
>>>>> so
>>>>>>>>>>> you
>>>>>>>>>>> need to switch
>>>>>>>>>>> to the 2.2 branch explicitly to see the latest releases. I’m
>>> not
>>>>> sure
>>>>>>>>>>> how to change that.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> You can file an INFRA issue to get the default branch and other
>>>>> GitHub
>>>>>>>>>> metadata changed.
>>>>>>>>>>
>>>>>>>>>> Jukka
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>> --
>> Simon Roberts
>> (303) 249 3613
>>
Re: Clustered Jini Server? Was: Re: Mirroring to GitHub
Posted by Gregg Wonderly <gr...@wonderly.org>.
Any Java spaces client spends most of its time blocked on a read/take from the space which makes it a very synchronous interface.
You would put work into the space and then turn right around an make a blocking take in most cases.
Gregg
Sent from my iPhone
> On Jun 3, 2015, at 6:42 AM, Palash Ray <pa...@gmail.com> wrote:
>
> Interesting thought about using Java Spaces. However, for us, there is an
> extra maintenance of the Java Spaces server in production, which is my
> worry. Moreover, in our application, it is always a synchronous call from
> the Swing client to the Jini server. It would be a lot of effort to make
> this an asynchronous call to Java Sapces. So for our kind of application,
> this would not be suitable.
>
> Thanks,
> Palash.
>
> On Wed, Jun 3, 2015 at 1:14 AM, Simon Roberts <
> simon@dancingcloudservices.com> wrote:
>
>> Hard to be sure if this is a sensible comment without knowing more about
>> what you're trying to do, but the typical "load balance" in a Jini
>> environment has traditionally been a Java Spaces server, into which "jobs"
>> (probably simply Runnable implementations) are placed. The clustered work
>> engines are configured to take (in a transaction) a job from the space,
>> process it, and put it back with an attribute indicating completion. On
>> putting the job back, the original take transaction is committed.
>> Therefore, if the server crashes before the job is completed, the "take"
>> evaporates, and some other work engine gets to re-take, hopefully
>> completing successfully. This model allows any number of work engines to be
>> load balanced for essentially zero communication between them, and no
>> actual load balancer exists (in the sense that no active component has to
>> keep track of the work engines). The workers take as fast at they're able
>> to do work, but no faster, so they don't get overloaded. You can bring
>> workers up, and shut them down, with zero reconfiguration.
>>
>> Cheers,
>> Simon
>>
>>
>>> On Tue, Jun 2, 2015 at 8:13 PM, Palash Ray <pa...@gmail.com> wrote:
>>>
>>> Thanks Dennis, I will definitely explore that option.
>>>
>>> On Tue, Jun 2, 2015 at 9:37 PM, Dennis Reedy <de...@gmail.com>
>>> wrote:
>>>
>>>> Hi Palash,
>>>>
>>>> Using reggie as a load balancer does not make the most sense, what you
>>> may
>>>> want to consider to to maintain a collection of discovered services and
>>>> simply round robin across them. You might want to start looking at the
>>>> ServiceDiscoveryManager and the LookupCache for this.
>>>>
>>>> HTH
>>>>
>>>> Dennis
>>>>
>>>>
>>>>> On Tue, Jun 2, 2015 at 9:16 PM, Palash Ray <pa...@gmail.com> wrote:
>>>>>
>>>>> Excellent. May be we can help each other here.
>>>>>
>>>>> Let me start by giving some more context around the problem.
>>>>>
>>>>> *Problem*
>>>>> Our middle tier that is a Jini-based rmi server. We have a Swing
>> client
>>>>> that connects to it. In the middle tier, we have lot of processing
>>> logic:
>>>>> fetch something from the database, do some calculation intensive
>>>>> processing, write the results back to the database.
>>>>>
>>>>> Of late there has been a huge increase of the loads: the no. of Swing
>>>>> clients has increased, as has the bulk of the data to be processed.
>> It
>>>> has
>>>>> come to a point, where our production server, which is a single
>>> machine,
>>>> is
>>>>> creaking under the load.
>>>>>
>>>>> So, we have decided to cluster it. We are planning to have at least 3
>>> or
>>>> 4
>>>>> Jini servers and a load balancer to spread out the load evenly.
>>>>>
>>>>> I was doing a proof of concept using the Jini infrasctrure itself.
>>> These
>>>>> were my thoughts:
>>>>>
>>>>> *Option 1*
>> https://github.com/paawak/blog/tree/master/code/jini/unsecure/load-balancing
>>>>>
>>>>> The load balancing architecture here is very very simple. There is a
>>>>> single load balancer with its own reggie running at 6670. This is the
>>>>> primary contact point for all clients.
>>>>>
>>>>> There are multiple reggie involved for load balancing. The following
>>>>> convention is followed:
>>>>>
>>>>> 1. The reggie for load balancer is at 6670
>>>>> 2. The reggie for the actual jini servers are at 5561, 5562, 5563,
>> etc.
>>>>>
>>>>> When the load-balancer recieves a request from client, it does the
>>>>> look-up at the appropriate jini-server and returns the remote
>> service.
>>>>>
>>>>> *Option 2*
>>>>> https://github.com/paawak/jini-in-a-war
>>>>>
>>>>> I figured that if we can embed the Jini in a Tomcat and then
>> clustering
>>>> the
>>>>> Tomcat would be very easy. But this is still work in progress, and
>>> there
>>>>> are lot of details that I need to figure out.
>>>>>
>>>>> Please let me know if the above makes sense or is around the same
>>> things
>>>>> that interest you. I would like to have a out of the box Jini
>> solution
>>>>> that *just
>>>>> works*. And I am happy to code for any solution that you guys think
>>>> should
>>>>> be the way forward.
>>>>>
>>>>> Thanks,
>>>>> Palash.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jun 2, 2015 at 2:14 PM, Patricia Shanahan <pa...@acm.org>
>>> wrote:
>>>>>
>>>>>> Also, if there is any chance the bottleneck is in River, I would be
>>>> very,
>>>>>> very interested in constructing a benchmark based on your workload
>>> that
>>>>>> demonstrates the scaling problem. I would like to run it against
>> the
>>>>> latest
>>>>>> unreleased version, which I think may fix some scaling issues. If
>> it
>>>>> still
>>>>>> shows scaling problems, I want to track them down and see whether
>>> they
>>>>> are
>>>>>> fixable without clustering.
>>>>>>
>>>>>> My most recent professional background, before retiring, was as a
>>>>>> performance architect working on multiprocessor servers for Cray
>>>> Research
>>>>>> and Sun Microsystems. When I first got involved in River I was
>>> thinking
>>>>> of
>>>>>> doing some performance analysis and improvement, one of my favorite
>>>>> games,
>>>>>> but could not find a suitable benchmark, or an actual user with a
>>>> scaling
>>>>>> problem.
>>>>>>
>>>>>> Patricia
>>>>>>
>>>>>>
>>>>>>> On 6/2/2015 10:24 AM, Greg Trasuk wrote:
>>>>>>>
>>>>>>>
>>>>>>> Palash:
>>>>>>>
>>>>>>> Could you expand on your need for a “clustered Jini server”? What
>>>>>>> features are you looking for, and what aspects of the application
>>> need
>>>>> to
>>>>>>> be clustered? This might provide fertile grounds for development.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Greg Trasuk
>>>>>>>
>>>>>>> On Jun 2, 2015, at 12:38 PM, Palash Ray <pa...@gmail.com>
>> wrote:
>>>>>>>>
>>>>>>>> Hi Greg, Patricia,
>>>>>>>>
>>>>>>>> Really happy to see:
>>>>>>>> https://github.com/trasukg/river-container
>>>>>>>>
>>>>>>>> I think we are off in the right direction. I have been using
>> river
>>>> for
>>>>>>>> almost 2 years now, but only recently started taking an interest
>> in
>>>>>>>> the code that makes it tick.
>>>>>>>>
>>>>>>>> Our organisation is facing some scalability issues with Jini of
>>> late,
>>>>>>>> well, I am not blaming Jini here, its just that we need a
>> clustered
>>>>>>>> Jini server.
>>>>>>>>
>>>>>>>> To that end I was playing around the code a bit. I have some
>> ideas
>>>>>>>> which I can discuss with this group later.
>>>>>>>>
>>>>>>>> I have created a small proof of concept of embedding Jini in a
>> war
>>>> and
>>>>>>>> running it in a webserver:
>>>>>>>> https://github.com/paawak/jini-in-a-war
>>>>>>>>
>>>>>>>> Also, I keep blogging about Jini with whatever little
>>> understanding I
>>>>>>>> have:
>>>>>>>> http://palashray.com/java/jini/
>>>>>>>>
>>>>>>>> In the coming days, I look forward to contributing to the river
>>>>> project.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Palash.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 6/2/15, Greg Trasuk <tr...@stratuscom.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks, Jukka. And by the way, I’m happy to see you’re still
>>>> watching
>>>>>>>>> River!
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>>
>>>>>>>>> Greg Trasuk.
>>>>>>>>>
>>>>>>>>> On Jun 2, 2015, at 11:14 AM, Jukka Zitting <
>>>> jukka.zitting@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> 2015-06-02 1:17 GMT-04:00 Greg Trasuk <trasukg@stratuscom.com
>>> :
>>>>>>>>>>
>>>>>>>>>>> I notice that for some reason, the 2.1 branch shows up as
>>> current,
>>>>> so
>>>>>>>>>>> you
>>>>>>>>>>> need to switch
>>>>>>>>>>> to the 2.2 branch explicitly to see the latest releases. I’m
>>> not
>>>>> sure
>>>>>>>>>>> how to change that.
>>>>>>>>>>
>>>>>>>>>> You can file an INFRA issue to get the default branch and other
>>>>> GitHub
>>>>>>>>>> metadata changed.
>>>>>>>>>>
>>>>>>>>>> Jukka
>>
>>
>>
>> --
>> Simon Roberts
>> (303) 249 3613
>>
Re: Clustered Jini Server? Was: Re: Mirroring to GitHub
Posted by Palash Ray <pa...@gmail.com>.
Interesting thought about using Java Spaces. However, for us, there is an
extra maintenance of the Java Spaces server in production, which is my
worry. Moreover, in our application, it is always a synchronous call from
the Swing client to the Jini server. It would be a lot of effort to make
this an asynchronous call to Java Sapces. So for our kind of application,
this would not be suitable.
Thanks,
Palash.
On Wed, Jun 3, 2015 at 1:14 AM, Simon Roberts <
simon@dancingcloudservices.com> wrote:
> Hard to be sure if this is a sensible comment without knowing more about
> what you're trying to do, but the typical "load balance" in a Jini
> environment has traditionally been a Java Spaces server, into which "jobs"
> (probably simply Runnable implementations) are placed. The clustered work
> engines are configured to take (in a transaction) a job from the space,
> process it, and put it back with an attribute indicating completion. On
> putting the job back, the original take transaction is committed.
> Therefore, if the server crashes before the job is completed, the "take"
> evaporates, and some other work engine gets to re-take, hopefully
> completing successfully. This model allows any number of work engines to be
> load balanced for essentially zero communication between them, and no
> actual load balancer exists (in the sense that no active component has to
> keep track of the work engines). The workers take as fast at they're able
> to do work, but no faster, so they don't get overloaded. You can bring
> workers up, and shut them down, with zero reconfiguration.
>
> Cheers,
> Simon
>
>
> On Tue, Jun 2, 2015 at 8:13 PM, Palash Ray <pa...@gmail.com> wrote:
>
> > Thanks Dennis, I will definitely explore that option.
> >
> > On Tue, Jun 2, 2015 at 9:37 PM, Dennis Reedy <de...@gmail.com>
> > wrote:
> >
> > > Hi Palash,
> > >
> > > Using reggie as a load balancer does not make the most sense, what you
> > may
> > > want to consider to to maintain a collection of discovered services and
> > > simply round robin across them. You might want to start looking at the
> > > ServiceDiscoveryManager and the LookupCache for this.
> > >
> > > HTH
> > >
> > > Dennis
> > >
> > >
> > > On Tue, Jun 2, 2015 at 9:16 PM, Palash Ray <pa...@gmail.com> wrote:
> > >
> > > > Excellent. May be we can help each other here.
> > > >
> > > > Let me start by giving some more context around the problem.
> > > >
> > > > *Problem*
> > > > Our middle tier that is a Jini-based rmi server. We have a Swing
> client
> > > > that connects to it. In the middle tier, we have lot of processing
> > logic:
> > > > fetch something from the database, do some calculation intensive
> > > > processing, write the results back to the database.
> > > >
> > > > Of late there has been a huge increase of the loads: the no. of Swing
> > > > clients has increased, as has the bulk of the data to be processed.
> It
> > > has
> > > > come to a point, where our production server, which is a single
> > machine,
> > > is
> > > > creaking under the load.
> > > >
> > > > So, we have decided to cluster it. We are planning to have at least 3
> > or
> > > 4
> > > > Jini servers and a load balancer to spread out the load evenly.
> > > >
> > > > I was doing a proof of concept using the Jini infrasctrure itself.
> > These
> > > > were my thoughts:
> > > >
> > > > *Option 1*
> > > >
> > > >
> > >
> >
> https://github.com/paawak/blog/tree/master/code/jini/unsecure/load-balancing
> > > >
> > > > The load balancing architecture here is very very simple. There is a
> > > > single load balancer with its own reggie running at 6670. This is the
> > > > primary contact point for all clients.
> > > >
> > > > There are multiple reggie involved for load balancing. The following
> > > > convention is followed:
> > > >
> > > > 1. The reggie for load balancer is at 6670
> > > > 2. The reggie for the actual jini servers are at 5561, 5562, 5563,
> etc.
> > > >
> > > > When the load-balancer recieves a request from client, it does the
> > > > look-up at the appropriate jini-server and returns the remote
> service.
> > > >
> > > > *Option 2*
> > > > https://github.com/paawak/jini-in-a-war
> > > >
> > > > I figured that if we can embed the Jini in a Tomcat and then
> clustering
> > > the
> > > > Tomcat would be very easy. But this is still work in progress, and
> > there
> > > > are lot of details that I need to figure out.
> > > >
> > > > Please let me know if the above makes sense or is around the same
> > things
> > > > that interest you. I would like to have a out of the box Jini
> solution
> > > > that *just
> > > > works*. And I am happy to code for any solution that you guys think
> > > should
> > > > be the way forward.
> > > >
> > > > Thanks,
> > > > Palash.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, Jun 2, 2015 at 2:14 PM, Patricia Shanahan <pa...@acm.org>
> > wrote:
> > > >
> > > > > Also, if there is any chance the bottleneck is in River, I would be
> > > very,
> > > > > very interested in constructing a benchmark based on your workload
> > that
> > > > > demonstrates the scaling problem. I would like to run it against
> the
> > > > latest
> > > > > unreleased version, which I think may fix some scaling issues. If
> it
> > > > still
> > > > > shows scaling problems, I want to track them down and see whether
> > they
> > > > are
> > > > > fixable without clustering.
> > > > >
> > > > > My most recent professional background, before retiring, was as a
> > > > > performance architect working on multiprocessor servers for Cray
> > > Research
> > > > > and Sun Microsystems. When I first got involved in River I was
> > thinking
> > > > of
> > > > > doing some performance analysis and improvement, one of my favorite
> > > > games,
> > > > > but could not find a suitable benchmark, or an actual user with a
> > > scaling
> > > > > problem.
> > > > >
> > > > > Patricia
> > > > >
> > > > >
> > > > > On 6/2/2015 10:24 AM, Greg Trasuk wrote:
> > > > >
> > > > >>
> > > > >> Palash:
> > > > >>
> > > > >> Could you expand on your need for a “clustered Jini server”? What
> > > > >> features are you looking for, and what aspects of the application
> > need
> > > > to
> > > > >> be clustered? This might provide fertile grounds for development.
> > > > >>
> > > > >> Cheers,
> > > > >>
> > > > >> Greg Trasuk
> > > > >>
> > > > >> On Jun 2, 2015, at 12:38 PM, Palash Ray <pa...@gmail.com>
> wrote:
> > > > >>>
> > > > >>> Hi Greg, Patricia,
> > > > >>>
> > > > >>> Really happy to see:
> > > > >>> https://github.com/trasukg/river-container
> > > > >>>
> > > > >>> I think we are off in the right direction. I have been using
> river
> > > for
> > > > >>> almost 2 years now, but only recently started taking an interest
> in
> > > > >>> the code that makes it tick.
> > > > >>>
> > > > >>> Our organisation is facing some scalability issues with Jini of
> > late,
> > > > >>> well, I am not blaming Jini here, its just that we need a
> clustered
> > > > >>> Jini server.
> > > > >>>
> > > > >>> To that end I was playing around the code a bit. I have some
> ideas
> > > > >>> which I can discuss with this group later.
> > > > >>>
> > > > >>> I have created a small proof of concept of embedding Jini in a
> war
> > > and
> > > > >>> running it in a webserver:
> > > > >>> https://github.com/paawak/jini-in-a-war
> > > > >>>
> > > > >>> Also, I keep blogging about Jini with whatever little
> > understanding I
> > > > >>> have:
> > > > >>> http://palashray.com/java/jini/
> > > > >>>
> > > > >>> In the coming days, I look forward to contributing to the river
> > > > project.
> > > > >>>
> > > > >>> Thanks,
> > > > >>> Palash.
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> On 6/2/15, Greg Trasuk <tr...@stratuscom.com> wrote:
> > > > >>>
> > > > >>>>
> > > > >>>> Thanks, Jukka. And by the way, I’m happy to see you’re still
> > > watching
> > > > >>>> River!
> > > > >>>>
> > > > >>>> Cheers,
> > > > >>>>
> > > > >>>> Greg Trasuk.
> > > > >>>>
> > > > >>>> On Jun 2, 2015, at 11:14 AM, Jukka Zitting <
> > > jukka.zitting@gmail.com>
> > > > >>>>> wrote:
> > > > >>>>>
> > > > >>>>> Hi,
> > > > >>>>>
> > > > >>>>> 2015-06-02 1:17 GMT-04:00 Greg Trasuk <trasukg@stratuscom.com
> >:
> > > > >>>>>
> > > > >>>>>> I notice that for some reason, the 2.1 branch shows up as
> > current,
> > > > so
> > > > >>>>>> you
> > > > >>>>>> need to switch
> > > > >>>>>> to the 2.2 branch explicitly to see the latest releases. I’m
> > not
> > > > sure
> > > > >>>>>> how to change that.
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>> You can file an INFRA issue to get the default branch and other
> > > > GitHub
> > > > >>>>> metadata changed.
> > > > >>>>>
> > > > >>>>> Jukka
> > > > >>>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>
> > > >
> > >
> >
>
>
>
> --
> Simon Roberts
> (303) 249 3613
>
Re: Clustered Jini Server? Was: Re: Mirroring to GitHub
Posted by Simon Roberts <si...@dancingcloudservices.com>.
Hard to be sure if this is a sensible comment without knowing more about
what you're trying to do, but the typical "load balance" in a Jini
environment has traditionally been a Java Spaces server, into which "jobs"
(probably simply Runnable implementations) are placed. The clustered work
engines are configured to take (in a transaction) a job from the space,
process it, and put it back with an attribute indicating completion. On
putting the job back, the original take transaction is committed.
Therefore, if the server crashes before the job is completed, the "take"
evaporates, and some other work engine gets to re-take, hopefully
completing successfully. This model allows any number of work engines to be
load balanced for essentially zero communication between them, and no
actual load balancer exists (in the sense that no active component has to
keep track of the work engines). The workers take as fast at they're able
to do work, but no faster, so they don't get overloaded. You can bring
workers up, and shut them down, with zero reconfiguration.
Cheers,
Simon
On Tue, Jun 2, 2015 at 8:13 PM, Palash Ray <pa...@gmail.com> wrote:
> Thanks Dennis, I will definitely explore that option.
>
> On Tue, Jun 2, 2015 at 9:37 PM, Dennis Reedy <de...@gmail.com>
> wrote:
>
> > Hi Palash,
> >
> > Using reggie as a load balancer does not make the most sense, what you
> may
> > want to consider to to maintain a collection of discovered services and
> > simply round robin across them. You might want to start looking at the
> > ServiceDiscoveryManager and the LookupCache for this.
> >
> > HTH
> >
> > Dennis
> >
> >
> > On Tue, Jun 2, 2015 at 9:16 PM, Palash Ray <pa...@gmail.com> wrote:
> >
> > > Excellent. May be we can help each other here.
> > >
> > > Let me start by giving some more context around the problem.
> > >
> > > *Problem*
> > > Our middle tier that is a Jini-based rmi server. We have a Swing client
> > > that connects to it. In the middle tier, we have lot of processing
> logic:
> > > fetch something from the database, do some calculation intensive
> > > processing, write the results back to the database.
> > >
> > > Of late there has been a huge increase of the loads: the no. of Swing
> > > clients has increased, as has the bulk of the data to be processed. It
> > has
> > > come to a point, where our production server, which is a single
> machine,
> > is
> > > creaking under the load.
> > >
> > > So, we have decided to cluster it. We are planning to have at least 3
> or
> > 4
> > > Jini servers and a load balancer to spread out the load evenly.
> > >
> > > I was doing a proof of concept using the Jini infrasctrure itself.
> These
> > > were my thoughts:
> > >
> > > *Option 1*
> > >
> > >
> >
> https://github.com/paawak/blog/tree/master/code/jini/unsecure/load-balancing
> > >
> > > The load balancing architecture here is very very simple. There is a
> > > single load balancer with its own reggie running at 6670. This is the
> > > primary contact point for all clients.
> > >
> > > There are multiple reggie involved for load balancing. The following
> > > convention is followed:
> > >
> > > 1. The reggie for load balancer is at 6670
> > > 2. The reggie for the actual jini servers are at 5561, 5562, 5563, etc.
> > >
> > > When the load-balancer recieves a request from client, it does the
> > > look-up at the appropriate jini-server and returns the remote service.
> > >
> > > *Option 2*
> > > https://github.com/paawak/jini-in-a-war
> > >
> > > I figured that if we can embed the Jini in a Tomcat and then clustering
> > the
> > > Tomcat would be very easy. But this is still work in progress, and
> there
> > > are lot of details that I need to figure out.
> > >
> > > Please let me know if the above makes sense or is around the same
> things
> > > that interest you. I would like to have a out of the box Jini solution
> > > that *just
> > > works*. And I am happy to code for any solution that you guys think
> > should
> > > be the way forward.
> > >
> > > Thanks,
> > > Palash.
> > >
> > >
> > >
> > >
> > >
> > > On Tue, Jun 2, 2015 at 2:14 PM, Patricia Shanahan <pa...@acm.org>
> wrote:
> > >
> > > > Also, if there is any chance the bottleneck is in River, I would be
> > very,
> > > > very interested in constructing a benchmark based on your workload
> that
> > > > demonstrates the scaling problem. I would like to run it against the
> > > latest
> > > > unreleased version, which I think may fix some scaling issues. If it
> > > still
> > > > shows scaling problems, I want to track them down and see whether
> they
> > > are
> > > > fixable without clustering.
> > > >
> > > > My most recent professional background, before retiring, was as a
> > > > performance architect working on multiprocessor servers for Cray
> > Research
> > > > and Sun Microsystems. When I first got involved in River I was
> thinking
> > > of
> > > > doing some performance analysis and improvement, one of my favorite
> > > games,
> > > > but could not find a suitable benchmark, or an actual user with a
> > scaling
> > > > problem.
> > > >
> > > > Patricia
> > > >
> > > >
> > > > On 6/2/2015 10:24 AM, Greg Trasuk wrote:
> > > >
> > > >>
> > > >> Palash:
> > > >>
> > > >> Could you expand on your need for a “clustered Jini server”? What
> > > >> features are you looking for, and what aspects of the application
> need
> > > to
> > > >> be clustered? This might provide fertile grounds for development.
> > > >>
> > > >> Cheers,
> > > >>
> > > >> Greg Trasuk
> > > >>
> > > >> On Jun 2, 2015, at 12:38 PM, Palash Ray <pa...@gmail.com> wrote:
> > > >>>
> > > >>> Hi Greg, Patricia,
> > > >>>
> > > >>> Really happy to see:
> > > >>> https://github.com/trasukg/river-container
> > > >>>
> > > >>> I think we are off in the right direction. I have been using river
> > for
> > > >>> almost 2 years now, but only recently started taking an interest in
> > > >>> the code that makes it tick.
> > > >>>
> > > >>> Our organisation is facing some scalability issues with Jini of
> late,
> > > >>> well, I am not blaming Jini here, its just that we need a clustered
> > > >>> Jini server.
> > > >>>
> > > >>> To that end I was playing around the code a bit. I have some ideas
> > > >>> which I can discuss with this group later.
> > > >>>
> > > >>> I have created a small proof of concept of embedding Jini in a war
> > and
> > > >>> running it in a webserver:
> > > >>> https://github.com/paawak/jini-in-a-war
> > > >>>
> > > >>> Also, I keep blogging about Jini with whatever little
> understanding I
> > > >>> have:
> > > >>> http://palashray.com/java/jini/
> > > >>>
> > > >>> In the coming days, I look forward to contributing to the river
> > > project.
> > > >>>
> > > >>> Thanks,
> > > >>> Palash.
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> On 6/2/15, Greg Trasuk <tr...@stratuscom.com> wrote:
> > > >>>
> > > >>>>
> > > >>>> Thanks, Jukka. And by the way, I’m happy to see you’re still
> > watching
> > > >>>> River!
> > > >>>>
> > > >>>> Cheers,
> > > >>>>
> > > >>>> Greg Trasuk.
> > > >>>>
> > > >>>> On Jun 2, 2015, at 11:14 AM, Jukka Zitting <
> > jukka.zitting@gmail.com>
> > > >>>>> wrote:
> > > >>>>>
> > > >>>>> Hi,
> > > >>>>>
> > > >>>>> 2015-06-02 1:17 GMT-04:00 Greg Trasuk <tr...@stratuscom.com>:
> > > >>>>>
> > > >>>>>> I notice that for some reason, the 2.1 branch shows up as
> current,
> > > so
> > > >>>>>> you
> > > >>>>>> need to switch
> > > >>>>>> to the 2.2 branch explicitly to see the latest releases. I’m
> not
> > > sure
> > > >>>>>> how to change that.
> > > >>>>>>
> > > >>>>>
> > > >>>>> You can file an INFRA issue to get the default branch and other
> > > GitHub
> > > >>>>> metadata changed.
> > > >>>>>
> > > >>>>> Jukka
> > > >>>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>
> > >
> >
>
--
Simon Roberts
(303) 249 3613
Re: Clustered Jini Server? Was: Re: Mirroring to GitHub
Posted by Palash Ray <pa...@gmail.com>.
Thanks Dennis, I will definitely explore that option.
On Tue, Jun 2, 2015 at 9:37 PM, Dennis Reedy <de...@gmail.com> wrote:
> Hi Palash,
>
> Using reggie as a load balancer does not make the most sense, what you may
> want to consider to to maintain a collection of discovered services and
> simply round robin across them. You might want to start looking at the
> ServiceDiscoveryManager and the LookupCache for this.
>
> HTH
>
> Dennis
>
>
> On Tue, Jun 2, 2015 at 9:16 PM, Palash Ray <pa...@gmail.com> wrote:
>
> > Excellent. May be we can help each other here.
> >
> > Let me start by giving some more context around the problem.
> >
> > *Problem*
> > Our middle tier that is a Jini-based rmi server. We have a Swing client
> > that connects to it. In the middle tier, we have lot of processing logic:
> > fetch something from the database, do some calculation intensive
> > processing, write the results back to the database.
> >
> > Of late there has been a huge increase of the loads: the no. of Swing
> > clients has increased, as has the bulk of the data to be processed. It
> has
> > come to a point, where our production server, which is a single machine,
> is
> > creaking under the load.
> >
> > So, we have decided to cluster it. We are planning to have at least 3 or
> 4
> > Jini servers and a load balancer to spread out the load evenly.
> >
> > I was doing a proof of concept using the Jini infrasctrure itself. These
> > were my thoughts:
> >
> > *Option 1*
> >
> >
> https://github.com/paawak/blog/tree/master/code/jini/unsecure/load-balancing
> >
> > The load balancing architecture here is very very simple. There is a
> > single load balancer with its own reggie running at 6670. This is the
> > primary contact point for all clients.
> >
> > There are multiple reggie involved for load balancing. The following
> > convention is followed:
> >
> > 1. The reggie for load balancer is at 6670
> > 2. The reggie for the actual jini servers are at 5561, 5562, 5563, etc.
> >
> > When the load-balancer recieves a request from client, it does the
> > look-up at the appropriate jini-server and returns the remote service.
> >
> > *Option 2*
> > https://github.com/paawak/jini-in-a-war
> >
> > I figured that if we can embed the Jini in a Tomcat and then clustering
> the
> > Tomcat would be very easy. But this is still work in progress, and there
> > are lot of details that I need to figure out.
> >
> > Please let me know if the above makes sense or is around the same things
> > that interest you. I would like to have a out of the box Jini solution
> > that *just
> > works*. And I am happy to code for any solution that you guys think
> should
> > be the way forward.
> >
> > Thanks,
> > Palash.
> >
> >
> >
> >
> >
> > On Tue, Jun 2, 2015 at 2:14 PM, Patricia Shanahan <pa...@acm.org> wrote:
> >
> > > Also, if there is any chance the bottleneck is in River, I would be
> very,
> > > very interested in constructing a benchmark based on your workload that
> > > demonstrates the scaling problem. I would like to run it against the
> > latest
> > > unreleased version, which I think may fix some scaling issues. If it
> > still
> > > shows scaling problems, I want to track them down and see whether they
> > are
> > > fixable without clustering.
> > >
> > > My most recent professional background, before retiring, was as a
> > > performance architect working on multiprocessor servers for Cray
> Research
> > > and Sun Microsystems. When I first got involved in River I was thinking
> > of
> > > doing some performance analysis and improvement, one of my favorite
> > games,
> > > but could not find a suitable benchmark, or an actual user with a
> scaling
> > > problem.
> > >
> > > Patricia
> > >
> > >
> > > On 6/2/2015 10:24 AM, Greg Trasuk wrote:
> > >
> > >>
> > >> Palash:
> > >>
> > >> Could you expand on your need for a “clustered Jini server”? What
> > >> features are you looking for, and what aspects of the application need
> > to
> > >> be clustered? This might provide fertile grounds for development.
> > >>
> > >> Cheers,
> > >>
> > >> Greg Trasuk
> > >>
> > >> On Jun 2, 2015, at 12:38 PM, Palash Ray <pa...@gmail.com> wrote:
> > >>>
> > >>> Hi Greg, Patricia,
> > >>>
> > >>> Really happy to see:
> > >>> https://github.com/trasukg/river-container
> > >>>
> > >>> I think we are off in the right direction. I have been using river
> for
> > >>> almost 2 years now, but only recently started taking an interest in
> > >>> the code that makes it tick.
> > >>>
> > >>> Our organisation is facing some scalability issues with Jini of late,
> > >>> well, I am not blaming Jini here, its just that we need a clustered
> > >>> Jini server.
> > >>>
> > >>> To that end I was playing around the code a bit. I have some ideas
> > >>> which I can discuss with this group later.
> > >>>
> > >>> I have created a small proof of concept of embedding Jini in a war
> and
> > >>> running it in a webserver:
> > >>> https://github.com/paawak/jini-in-a-war
> > >>>
> > >>> Also, I keep blogging about Jini with whatever little understanding I
> > >>> have:
> > >>> http://palashray.com/java/jini/
> > >>>
> > >>> In the coming days, I look forward to contributing to the river
> > project.
> > >>>
> > >>> Thanks,
> > >>> Palash.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On 6/2/15, Greg Trasuk <tr...@stratuscom.com> wrote:
> > >>>
> > >>>>
> > >>>> Thanks, Jukka. And by the way, I’m happy to see you’re still
> watching
> > >>>> River!
> > >>>>
> > >>>> Cheers,
> > >>>>
> > >>>> Greg Trasuk.
> > >>>>
> > >>>> On Jun 2, 2015, at 11:14 AM, Jukka Zitting <
> jukka.zitting@gmail.com>
> > >>>>> wrote:
> > >>>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>> 2015-06-02 1:17 GMT-04:00 Greg Trasuk <tr...@stratuscom.com>:
> > >>>>>
> > >>>>>> I notice that for some reason, the 2.1 branch shows up as current,
> > so
> > >>>>>> you
> > >>>>>> need to switch
> > >>>>>> to the 2.2 branch explicitly to see the latest releases. I’m not
> > sure
> > >>>>>> how to change that.
> > >>>>>>
> > >>>>>
> > >>>>> You can file an INFRA issue to get the default branch and other
> > GitHub
> > >>>>> metadata changed.
> > >>>>>
> > >>>>> Jukka
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>
> >
>
Re: Clustered Jini Server? Was: Re: Mirroring to GitHub
Posted by Gregg Wonderly <gr...@wonderly.org>.
One of the primary issues with trying to scale join applications is all of the locking and blocking through the security subsystems. Peter's work in this area should be a tremendously visible performance boost for any app which has a high call load, such as data processing.
Gregg
Sent from my iPhone
> On Jun 2, 2015, at 8:37 PM, Dennis Reedy <de...@gmail.com> wrote:
>
> Hi Palash,
>
> Using reggie as a load balancer does not make the most sense, what you may
> want to consider to to maintain a collection of discovered services and
> simply round robin across them. You might want to start looking at the
> ServiceDiscoveryManager and the LookupCache for this.
>
> HTH
>
> Dennis
>
>
>> On Tue, Jun 2, 2015 at 9:16 PM, Palash Ray <pa...@gmail.com> wrote:
>>
>> Excellent. May be we can help each other here.
>>
>> Let me start by giving some more context around the problem.
>>
>> *Problem*
>> Our middle tier that is a Jini-based rmi server. We have a Swing client
>> that connects to it. In the middle tier, we have lot of processing logic:
>> fetch something from the database, do some calculation intensive
>> processing, write the results back to the database.
>>
>> Of late there has been a huge increase of the loads: the no. of Swing
>> clients has increased, as has the bulk of the data to be processed. It has
>> come to a point, where our production server, which is a single machine, is
>> creaking under the load.
>>
>> So, we have decided to cluster it. We are planning to have at least 3 or 4
>> Jini servers and a load balancer to spread out the load evenly.
>>
>> I was doing a proof of concept using the Jini infrasctrure itself. These
>> were my thoughts:
>>
>> *Option 1*
>>
>> https://github.com/paawak/blog/tree/master/code/jini/unsecure/load-balancing
>>
>> The load balancing architecture here is very very simple. There is a
>> single load balancer with its own reggie running at 6670. This is the
>> primary contact point for all clients.
>>
>> There are multiple reggie involved for load balancing. The following
>> convention is followed:
>>
>> 1. The reggie for load balancer is at 6670
>> 2. The reggie for the actual jini servers are at 5561, 5562, 5563, etc.
>>
>> When the load-balancer recieves a request from client, it does the
>> look-up at the appropriate jini-server and returns the remote service.
>>
>> *Option 2*
>> https://github.com/paawak/jini-in-a-war
>>
>> I figured that if we can embed the Jini in a Tomcat and then clustering the
>> Tomcat would be very easy. But this is still work in progress, and there
>> are lot of details that I need to figure out.
>>
>> Please let me know if the above makes sense or is around the same things
>> that interest you. I would like to have a out of the box Jini solution
>> that *just
>> works*. And I am happy to code for any solution that you guys think should
>> be the way forward.
>>
>> Thanks,
>> Palash.
>>
>>
>>
>>
>>
>>> On Tue, Jun 2, 2015 at 2:14 PM, Patricia Shanahan <pa...@acm.org> wrote:
>>>
>>> Also, if there is any chance the bottleneck is in River, I would be very,
>>> very interested in constructing a benchmark based on your workload that
>>> demonstrates the scaling problem. I would like to run it against the
>> latest
>>> unreleased version, which I think may fix some scaling issues. If it
>> still
>>> shows scaling problems, I want to track them down and see whether they
>> are
>>> fixable without clustering.
>>>
>>> My most recent professional background, before retiring, was as a
>>> performance architect working on multiprocessor servers for Cray Research
>>> and Sun Microsystems. When I first got involved in River I was thinking
>> of
>>> doing some performance analysis and improvement, one of my favorite
>> games,
>>> but could not find a suitable benchmark, or an actual user with a scaling
>>> problem.
>>>
>>> Patricia
>>>
>>>
>>>> On 6/2/2015 10:24 AM, Greg Trasuk wrote:
>>>>
>>>>
>>>> Palash:
>>>>
>>>> Could you expand on your need for a “clustered Jini server”? What
>>>> features are you looking for, and what aspects of the application need
>> to
>>>> be clustered? This might provide fertile grounds for development.
>>>>
>>>> Cheers,
>>>>
>>>> Greg Trasuk
>>>>
>>>>> On Jun 2, 2015, at 12:38 PM, Palash Ray <pa...@gmail.com> wrote:
>>>>>
>>>>> Hi Greg, Patricia,
>>>>>
>>>>> Really happy to see:
>>>>> https://github.com/trasukg/river-container
>>>>>
>>>>> I think we are off in the right direction. I have been using river for
>>>>> almost 2 years now, but only recently started taking an interest in
>>>>> the code that makes it tick.
>>>>>
>>>>> Our organisation is facing some scalability issues with Jini of late,
>>>>> well, I am not blaming Jini here, its just that we need a clustered
>>>>> Jini server.
>>>>>
>>>>> To that end I was playing around the code a bit. I have some ideas
>>>>> which I can discuss with this group later.
>>>>>
>>>>> I have created a small proof of concept of embedding Jini in a war and
>>>>> running it in a webserver:
>>>>> https://github.com/paawak/jini-in-a-war
>>>>>
>>>>> Also, I keep blogging about Jini with whatever little understanding I
>>>>> have:
>>>>> http://palashray.com/java/jini/
>>>>>
>>>>> In the coming days, I look forward to contributing to the river
>> project.
>>>>>
>>>>> Thanks,
>>>>> Palash.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On 6/2/15, Greg Trasuk <tr...@stratuscom.com> wrote:
>>>>>>
>>>>>>
>>>>>> Thanks, Jukka. And by the way, I’m happy to see you’re still watching
>>>>>> River!
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Greg Trasuk.
>>>>>>
>>>>>> On Jun 2, 2015, at 11:14 AM, Jukka Zitting <ju...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> 2015-06-02 1:17 GMT-04:00 Greg Trasuk <tr...@stratuscom.com>:
>>>>>>>
>>>>>>>> I notice that for some reason, the 2.1 branch shows up as current,
>> so
>>>>>>>> you
>>>>>>>> need to switch
>>>>>>>> to the 2.2 branch explicitly to see the latest releases. I’m not
>> sure
>>>>>>>> how to change that.
>>>>>>>
>>>>>>> You can file an INFRA issue to get the default branch and other
>> GitHub
>>>>>>> metadata changed.
>>>>>>>
>>>>>>> Jukka
>>
Re: Clustered Jini Server? Was: Re: Mirroring to GitHub
Posted by Dennis Reedy <de...@gmail.com>.
Hi Palash,
Using reggie as a load balancer does not make the most sense, what you may
want to consider to to maintain a collection of discovered services and
simply round robin across them. You might want to start looking at the
ServiceDiscoveryManager and the LookupCache for this.
HTH
Dennis
On Tue, Jun 2, 2015 at 9:16 PM, Palash Ray <pa...@gmail.com> wrote:
> Excellent. May be we can help each other here.
>
> Let me start by giving some more context around the problem.
>
> *Problem*
> Our middle tier that is a Jini-based rmi server. We have a Swing client
> that connects to it. In the middle tier, we have lot of processing logic:
> fetch something from the database, do some calculation intensive
> processing, write the results back to the database.
>
> Of late there has been a huge increase of the loads: the no. of Swing
> clients has increased, as has the bulk of the data to be processed. It has
> come to a point, where our production server, which is a single machine, is
> creaking under the load.
>
> So, we have decided to cluster it. We are planning to have at least 3 or 4
> Jini servers and a load balancer to spread out the load evenly.
>
> I was doing a proof of concept using the Jini infrasctrure itself. These
> were my thoughts:
>
> *Option 1*
>
> https://github.com/paawak/blog/tree/master/code/jini/unsecure/load-balancing
>
> The load balancing architecture here is very very simple. There is a
> single load balancer with its own reggie running at 6670. This is the
> primary contact point for all clients.
>
> There are multiple reggie involved for load balancing. The following
> convention is followed:
>
> 1. The reggie for load balancer is at 6670
> 2. The reggie for the actual jini servers are at 5561, 5562, 5563, etc.
>
> When the load-balancer recieves a request from client, it does the
> look-up at the appropriate jini-server and returns the remote service.
>
> *Option 2*
> https://github.com/paawak/jini-in-a-war
>
> I figured that if we can embed the Jini in a Tomcat and then clustering the
> Tomcat would be very easy. But this is still work in progress, and there
> are lot of details that I need to figure out.
>
> Please let me know if the above makes sense or is around the same things
> that interest you. I would like to have a out of the box Jini solution
> that *just
> works*. And I am happy to code for any solution that you guys think should
> be the way forward.
>
> Thanks,
> Palash.
>
>
>
>
>
> On Tue, Jun 2, 2015 at 2:14 PM, Patricia Shanahan <pa...@acm.org> wrote:
>
> > Also, if there is any chance the bottleneck is in River, I would be very,
> > very interested in constructing a benchmark based on your workload that
> > demonstrates the scaling problem. I would like to run it against the
> latest
> > unreleased version, which I think may fix some scaling issues. If it
> still
> > shows scaling problems, I want to track them down and see whether they
> are
> > fixable without clustering.
> >
> > My most recent professional background, before retiring, was as a
> > performance architect working on multiprocessor servers for Cray Research
> > and Sun Microsystems. When I first got involved in River I was thinking
> of
> > doing some performance analysis and improvement, one of my favorite
> games,
> > but could not find a suitable benchmark, or an actual user with a scaling
> > problem.
> >
> > Patricia
> >
> >
> > On 6/2/2015 10:24 AM, Greg Trasuk wrote:
> >
> >>
> >> Palash:
> >>
> >> Could you expand on your need for a “clustered Jini server”? What
> >> features are you looking for, and what aspects of the application need
> to
> >> be clustered? This might provide fertile grounds for development.
> >>
> >> Cheers,
> >>
> >> Greg Trasuk
> >>
> >> On Jun 2, 2015, at 12:38 PM, Palash Ray <pa...@gmail.com> wrote:
> >>>
> >>> Hi Greg, Patricia,
> >>>
> >>> Really happy to see:
> >>> https://github.com/trasukg/river-container
> >>>
> >>> I think we are off in the right direction. I have been using river for
> >>> almost 2 years now, but only recently started taking an interest in
> >>> the code that makes it tick.
> >>>
> >>> Our organisation is facing some scalability issues with Jini of late,
> >>> well, I am not blaming Jini here, its just that we need a clustered
> >>> Jini server.
> >>>
> >>> To that end I was playing around the code a bit. I have some ideas
> >>> which I can discuss with this group later.
> >>>
> >>> I have created a small proof of concept of embedding Jini in a war and
> >>> running it in a webserver:
> >>> https://github.com/paawak/jini-in-a-war
> >>>
> >>> Also, I keep blogging about Jini with whatever little understanding I
> >>> have:
> >>> http://palashray.com/java/jini/
> >>>
> >>> In the coming days, I look forward to contributing to the river
> project.
> >>>
> >>> Thanks,
> >>> Palash.
> >>>
> >>>
> >>>
> >>>
> >>> On 6/2/15, Greg Trasuk <tr...@stratuscom.com> wrote:
> >>>
> >>>>
> >>>> Thanks, Jukka. And by the way, I’m happy to see you’re still watching
> >>>> River!
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Greg Trasuk.
> >>>>
> >>>> On Jun 2, 2015, at 11:14 AM, Jukka Zitting <ju...@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> 2015-06-02 1:17 GMT-04:00 Greg Trasuk <tr...@stratuscom.com>:
> >>>>>
> >>>>>> I notice that for some reason, the 2.1 branch shows up as current,
> so
> >>>>>> you
> >>>>>> need to switch
> >>>>>> to the 2.2 branch explicitly to see the latest releases. I’m not
> sure
> >>>>>> how to change that.
> >>>>>>
> >>>>>
> >>>>> You can file an INFRA issue to get the default branch and other
> GitHub
> >>>>> metadata changed.
> >>>>>
> >>>>> Jukka
> >>>>>
> >>>>
> >>>>
> >>>>
> >>
>
Re: Clustered Jini Server? Was: Re: Mirroring to GitHub
Posted by Palash Ray <pa...@gmail.com>.
Excellent. May be we can help each other here.
Let me start by giving some more context around the problem.
*Problem*
Our middle tier that is a Jini-based rmi server. We have a Swing client
that connects to it. In the middle tier, we have lot of processing logic:
fetch something from the database, do some calculation intensive
processing, write the results back to the database.
Of late there has been a huge increase of the loads: the no. of Swing
clients has increased, as has the bulk of the data to be processed. It has
come to a point, where our production server, which is a single machine, is
creaking under the load.
So, we have decided to cluster it. We are planning to have at least 3 or 4
Jini servers and a load balancer to spread out the load evenly.
I was doing a proof of concept using the Jini infrasctrure itself. These
were my thoughts:
*Option 1*
https://github.com/paawak/blog/tree/master/code/jini/unsecure/load-balancing
The load balancing architecture here is very very simple. There is a
single load balancer with its own reggie running at 6670. This is the
primary contact point for all clients.
There are multiple reggie involved for load balancing. The following
convention is followed:
1. The reggie for load balancer is at 6670
2. The reggie for the actual jini servers are at 5561, 5562, 5563, etc.
When the load-balancer recieves a request from client, it does the
look-up at the appropriate jini-server and returns the remote service.
*Option 2*
https://github.com/paawak/jini-in-a-war
I figured that if we can embed the Jini in a Tomcat and then clustering the
Tomcat would be very easy. But this is still work in progress, and there
are lot of details that I need to figure out.
Please let me know if the above makes sense or is around the same things
that interest you. I would like to have a out of the box Jini solution
that *just
works*. And I am happy to code for any solution that you guys think should
be the way forward.
Thanks,
Palash.
On Tue, Jun 2, 2015 at 2:14 PM, Patricia Shanahan <pa...@acm.org> wrote:
> Also, if there is any chance the bottleneck is in River, I would be very,
> very interested in constructing a benchmark based on your workload that
> demonstrates the scaling problem. I would like to run it against the latest
> unreleased version, which I think may fix some scaling issues. If it still
> shows scaling problems, I want to track them down and see whether they are
> fixable without clustering.
>
> My most recent professional background, before retiring, was as a
> performance architect working on multiprocessor servers for Cray Research
> and Sun Microsystems. When I first got involved in River I was thinking of
> doing some performance analysis and improvement, one of my favorite games,
> but could not find a suitable benchmark, or an actual user with a scaling
> problem.
>
> Patricia
>
>
> On 6/2/2015 10:24 AM, Greg Trasuk wrote:
>
>>
>> Palash:
>>
>> Could you expand on your need for a “clustered Jini server”? What
>> features are you looking for, and what aspects of the application need to
>> be clustered? This might provide fertile grounds for development.
>>
>> Cheers,
>>
>> Greg Trasuk
>>
>> On Jun 2, 2015, at 12:38 PM, Palash Ray <pa...@gmail.com> wrote:
>>>
>>> Hi Greg, Patricia,
>>>
>>> Really happy to see:
>>> https://github.com/trasukg/river-container
>>>
>>> I think we are off in the right direction. I have been using river for
>>> almost 2 years now, but only recently started taking an interest in
>>> the code that makes it tick.
>>>
>>> Our organisation is facing some scalability issues with Jini of late,
>>> well, I am not blaming Jini here, its just that we need a clustered
>>> Jini server.
>>>
>>> To that end I was playing around the code a bit. I have some ideas
>>> which I can discuss with this group later.
>>>
>>> I have created a small proof of concept of embedding Jini in a war and
>>> running it in a webserver:
>>> https://github.com/paawak/jini-in-a-war
>>>
>>> Also, I keep blogging about Jini with whatever little understanding I
>>> have:
>>> http://palashray.com/java/jini/
>>>
>>> In the coming days, I look forward to contributing to the river project.
>>>
>>> Thanks,
>>> Palash.
>>>
>>>
>>>
>>>
>>> On 6/2/15, Greg Trasuk <tr...@stratuscom.com> wrote:
>>>
>>>>
>>>> Thanks, Jukka. And by the way, I’m happy to see you’re still watching
>>>> River!
>>>>
>>>> Cheers,
>>>>
>>>> Greg Trasuk.
>>>>
>>>> On Jun 2, 2015, at 11:14 AM, Jukka Zitting <ju...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> 2015-06-02 1:17 GMT-04:00 Greg Trasuk <tr...@stratuscom.com>:
>>>>>
>>>>>> I notice that for some reason, the 2.1 branch shows up as current, so
>>>>>> you
>>>>>> need to switch
>>>>>> to the 2.2 branch explicitly to see the latest releases. I’m not sure
>>>>>> how to change that.
>>>>>>
>>>>>
>>>>> You can file an INFRA issue to get the default branch and other GitHub
>>>>> metadata changed.
>>>>>
>>>>> Jukka
>>>>>
>>>>
>>>>
>>>>
>>
Re: Clustered Jini Server? Was: Re: Mirroring to GitHub
Posted by Patricia Shanahan <pa...@acm.org>.
Also, if there is any chance the bottleneck is in River, I would be
very, very interested in constructing a benchmark based on your workload
that demonstrates the scaling problem. I would like to run it against
the latest unreleased version, which I think may fix some scaling
issues. If it still shows scaling problems, I want to track them down
and see whether they are fixable without clustering.
My most recent professional background, before retiring, was as a
performance architect working on multiprocessor servers for Cray
Research and Sun Microsystems. When I first got involved in River I was
thinking of doing some performance analysis and improvement, one of my
favorite games, but could not find a suitable benchmark, or an actual
user with a scaling problem.
Patricia
On 6/2/2015 10:24 AM, Greg Trasuk wrote:
>
> Palash:
>
> Could you expand on your need for a “clustered Jini server”? What features are you looking for, and what aspects of the application need to be clustered? This might provide fertile grounds for development.
>
> Cheers,
>
> Greg Trasuk
>
>> On Jun 2, 2015, at 12:38 PM, Palash Ray <pa...@gmail.com> wrote:
>>
>> Hi Greg, Patricia,
>>
>> Really happy to see:
>> https://github.com/trasukg/river-container
>>
>> I think we are off in the right direction. I have been using river for
>> almost 2 years now, but only recently started taking an interest in
>> the code that makes it tick.
>>
>> Our organisation is facing some scalability issues with Jini of late,
>> well, I am not blaming Jini here, its just that we need a clustered
>> Jini server.
>>
>> To that end I was playing around the code a bit. I have some ideas
>> which I can discuss with this group later.
>>
>> I have created a small proof of concept of embedding Jini in a war and
>> running it in a webserver:
>> https://github.com/paawak/jini-in-a-war
>>
>> Also, I keep blogging about Jini with whatever little understanding I have:
>> http://palashray.com/java/jini/
>>
>> In the coming days, I look forward to contributing to the river project.
>>
>> Thanks,
>> Palash.
>>
>>
>>
>>
>> On 6/2/15, Greg Trasuk <tr...@stratuscom.com> wrote:
>>>
>>> Thanks, Jukka. And by the way, I’m happy to see you’re still watching
>>> River!
>>>
>>> Cheers,
>>>
>>> Greg Trasuk.
>>>
>>>> On Jun 2, 2015, at 11:14 AM, Jukka Zitting <ju...@gmail.com>
>>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> 2015-06-02 1:17 GMT-04:00 Greg Trasuk <tr...@stratuscom.com>:
>>>>> I notice that for some reason, the 2.1 branch shows up as current, so you
>>>>> need to switch
>>>>> to the 2.2 branch explicitly to see the latest releases. I’m not sure
>>>>> how to change that.
>>>>
>>>> You can file an INFRA issue to get the default branch and other GitHub
>>>> metadata changed.
>>>>
>>>> Jukka
>>>
>>>
>
Clustered Jini Server? Was: Re: Mirroring to GitHub
Posted by Greg Trasuk <tr...@stratuscom.com>.
Palash:
Could you expand on your need for a “clustered Jini server”? What features are you looking for, and what aspects of the application need to be clustered? This might provide fertile grounds for development.
Cheers,
Greg Trasuk
> On Jun 2, 2015, at 12:38 PM, Palash Ray <pa...@gmail.com> wrote:
>
> Hi Greg, Patricia,
>
> Really happy to see:
> https://github.com/trasukg/river-container
>
> I think we are off in the right direction. I have been using river for
> almost 2 years now, but only recently started taking an interest in
> the code that makes it tick.
>
> Our organisation is facing some scalability issues with Jini of late,
> well, I am not blaming Jini here, its just that we need a clustered
> Jini server.
>
> To that end I was playing around the code a bit. I have some ideas
> which I can discuss with this group later.
>
> I have created a small proof of concept of embedding Jini in a war and
> running it in a webserver:
> https://github.com/paawak/jini-in-a-war
>
> Also, I keep blogging about Jini with whatever little understanding I have:
> http://palashray.com/java/jini/
>
> In the coming days, I look forward to contributing to the river project.
>
> Thanks,
> Palash.
>
>
>
>
> On 6/2/15, Greg Trasuk <tr...@stratuscom.com> wrote:
>>
>> Thanks, Jukka. And by the way, I’m happy to see you’re still watching
>> River!
>>
>> Cheers,
>>
>> Greg Trasuk.
>>
>>> On Jun 2, 2015, at 11:14 AM, Jukka Zitting <ju...@gmail.com>
>>> wrote:
>>>
>>> Hi,
>>>
>>> 2015-06-02 1:17 GMT-04:00 Greg Trasuk <tr...@stratuscom.com>:
>>>> I notice that for some reason, the 2.1 branch shows up as current, so you
>>>> need to switch
>>>> to the 2.2 branch explicitly to see the latest releases. I’m not sure
>>>> how to change that.
>>>
>>> You can file an INFRA issue to get the default branch and other GitHub
>>> metadata changed.
>>>
>>> Jukka
>>
>>
Re: Mirroring to GitHub
Posted by Palash Ray <pa...@gmail.com>.
Hi Greg, Patricia,
Really happy to see:
https://github.com/trasukg/river-container
I think we are off in the right direction. I have been using river for
almost 2 years now, but only recently started taking an interest in
the code that makes it tick.
Our organisation is facing some scalability issues with Jini of late,
well, I am not blaming Jini here, its just that we need a clustered
Jini server.
To that end I was playing around the code a bit. I have some ideas
which I can discuss with this group later.
I have created a small proof of concept of embedding Jini in a war and
running it in a webserver:
https://github.com/paawak/jini-in-a-war
Also, I keep blogging about Jini with whatever little understanding I have:
http://palashray.com/java/jini/
In the coming days, I look forward to contributing to the river project.
Thanks,
Palash.
On 6/2/15, Greg Trasuk <tr...@stratuscom.com> wrote:
>
> Thanks, Jukka. And by the way, I’m happy to see you’re still watching
> River!
>
> Cheers,
>
> Greg Trasuk.
>
>> On Jun 2, 2015, at 11:14 AM, Jukka Zitting <ju...@gmail.com>
>> wrote:
>>
>> Hi,
>>
>> 2015-06-02 1:17 GMT-04:00 Greg Trasuk <tr...@stratuscom.com>:
>>> I notice that for some reason, the 2.1 branch shows up as current, so you
>>> need to switch
>>> to the 2.2 branch explicitly to see the latest releases. I’m not sure
>>> how to change that.
>>
>> You can file an INFRA issue to get the default branch and other GitHub
>> metadata changed.
>>
>> Jukka
>
>
Re: Mirroring to GitHub
Posted by Greg Trasuk <tr...@stratuscom.com>.
Thanks, Jukka. And by the way, I’m happy to see you’re still watching River!
Cheers,
Greg Trasuk.
> On Jun 2, 2015, at 11:14 AM, Jukka Zitting <ju...@gmail.com> wrote:
>
> Hi,
>
> 2015-06-02 1:17 GMT-04:00 Greg Trasuk <tr...@stratuscom.com>:
>> I notice that for some reason, the 2.1 branch shows up as current, so you need to switch
>> to the 2.2 branch explicitly to see the latest releases. I’m not sure how to change that.
>
> You can file an INFRA issue to get the default branch and other GitHub
> metadata changed.
>
> Jukka
Re: Mirroring to GitHub
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
2015-06-02 1:17 GMT-04:00 Greg Trasuk <tr...@stratuscom.com>:
> I notice that for some reason, the 2.1 branch shows up as current, so you need to switch
> to the 2.2 branch explicitly to see the latest releases. I’m not sure how to change that.
You can file an INFRA issue to get the default branch and other GitHub
metadata changed.
Jukka
Re: Mirroring to GitHub
Posted by Greg Trasuk <tr...@stratuscom.com>.
Hello Palash:
It’s most excellent to see you posting to the list, as well as to JMeter. I have to confess, I’ve had a JMeter plugin on my “TODO” list for quite some time, so it’s great to see you proposing it.
We are actually already mirrored to github ( as is the entire Apache svn repository):
https://github.com/apache/river/tree/2.2 <https://github.com/apache/river/tree/2.2>
I notice that for some reason, the 2.1 branch shows up as current, so you need to switch to the 2.2 branch explicitly to see the latest releases. I’m not sure how to change that.
Also, if I could make a suggestion, you might want to take a look at the river-container project hosted at https://github.com/trasukg/river-container <https://github.com/trasukg/river-container> and also the rio project at https://github.com/dreedyman/Rio <https://github.com/dreedyman/Rio>
Also the river examples project (as yet unreleased) that is in development at https://svn.apache.org/repos/asf/river/river-examples/river-examples/trunk <https://svn.apache.org/repos/asf/river/river-examples/river-examples/trunk>
Cheers,
Greg Trasuk
> On Jun 1, 2015, at 10:44 PM, Palash Ray <pa...@gmail.com> wrote:
>
> Hi Devs,
>
> We use lot of Jini as our middleware platform across various applications
> in our organisations.
>
> I see that there has been no activity for the last couple of years. To
> spurt interest in this wonderful, and powerful project, we can actually
> mirror it on github like Apache JMeter has done.
>
> Please let me know your thoughts on this?
>
> Thanks,
> Palash.