You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@river.apache.org by Greg Trasuk <tr...@trasuk.com> on 2015/11/13 16:21:47 UTC
[Discuss] Drop support for Activation?
Hello all:
Last week I asked about removing activation from River, both the 2.2 and 3.0 branches. There didn’t seem to be a lot of anti-removal feeling, so I’d like to formally propose removing Activation. There are a couple of other things that we could possibly remove, like JRMP support (i.e. pre-compiled proxy classes), but we should probably discuss those separately.
The main reason for this is that unused code still requires maintenance and increases the chance of bugs. Also I think that as we go forward with refactoring, renaming, restructuring the build and so on, it seems wasteful to do that work on code that isn’t actually in use.
Obviously, the code remains in Subversion and in the 2.2.2 release, so if someone wants to get it back, we (or they) could package it into a different deliverable. But I wouldn’t plan on doing that unless there’s actual demand for it.
My thought is to put this out there for discussion - If there is consensus after a few days I’ll call a lazy-consensus vote. I’ll be happy to do the work in the 2.2 branch.
So, I propose to drop support for the following:
Activation -
com.sun.jini.phoenix.*
com.sun.jini.phoenix.resources.*
net.jini.activation.*
Norm / LeaseRenewalService - is pretty much unneeded without activation
com.sun.jini.norm.**
Activatable implementation of the infrastructure services
com.sun.jini.fiddler.ActivatableFiddlerImpl
com.sun.jini.mahalo.ActivatableMahaloImpl
com.sun.jini.mercury.ActivatableMercuryImpl
com.sun.jini.reggie.PersistentRegistrarImpl
Starter for Activatable Services
com.sun.jini.start.ActivateWrapper
com.sun.jini.start.SharedActivatableServiceDescriptor
com.sun.jini.start.SharedGroupImpl
QA Harness classes that test any of the above.
Cheers,
Greg Trasuk
Re: [Discuss] Drop support for Activation?
Posted by Bryan Thompson <br...@systap.com>.
Sounds just like the overhead of object relational mappers. Fine for one
object. Death if you are trying to chase object graphs....
On Nov 13, 2015 3:11 PM, "Greg Trasuk" <tr...@stratuscom.com> wrote:
>
> > On Nov 13, 2015, at 2:21 PM, Bryan Thompson <br...@systap.com> wrote:
> >
> > I was trying to remember precisely what is in "activation". I found this
> > [1]. From [1]:
> >
> > "Distributed object systems are designed to support long-lived persistent
> > objects. Given that these systems will be made up of many thousands
> > (perhaps millions) of such objects, it would be unreasonable for object
> > implementations to become active and remain active, taking up valuable
> > system resources for indefinite periods of time. In addition, clients
> need
> > the ability to store persistent references to objects so that
> communication
> > among objects can be re-established after a system crash, since
> typically a
> > reference to a distributed object is valid only while the object is
> active."
> >
> > So the concept here was long lived object references and robustness of
> > those references.
> >
> > This all seems very appropriate for IoT, but perhaps the goal of such
> > durable / robust / on demand (re-)activation of services is now met
> through
> > other mechanisms? Something that does not need to be part of River?
> >
>
> “Long-lived persistent objects” reminds me of the Entity EJBs in EJB 1 and
> 2. The metaphor there was that every entity (e.g. a User) was represented
> by a persistent object, identified by a primary key, and you interacted
> with the entity by making remote method calls on the entity’s proxy. The
> problem was that the typical interaction would be ‘getName()’,
> ‘getEmail()’, 'getUserId()’, ‘getPhoneNumber()’, etc. By the time you had
> any useful interaction you might have made 10-15 remote method calls. Put
> twenty entities on a web page, and you might need to make hundreds of
> remote calls to display the page. In other words, the distributed objects
> were at the wrong level of granularity.
>
> If we have distributed services, on the other hand, we can readily
> accommodate the right granularity in the service design. In that case,
> though, activation only makes sense if we have so many services that it
> isn’t practical to keep them all alive at the same time. Typically you
> have a reasonable number of services in any given virtual machine
> instance. I suspect that if you really did have that many services that
> needed activation, you’d end up with a really slow system because the
> overhead of activating and passivating services would far outweigh the time
> spend in actual service calls.
>
> So, I don’t see much of a use case for Activation. I’m interested to see
> if anyone else does.
>
> Cheers,
>
> Greg Trasuk
>
> > Thanks,
> > Bryan
> >
> > [1]
> >
> http://www.javaworld.com/article/2076173/soa/activatable-jini-services--part-1--implement-rmi-activation.html
> >
> > ----
> > Bryan Thompson
> > Chief Scientist & Founder
> > SYSTAP, LLC
> > 4501 Tower Road
> > Greensboro, NC 27410
> > bryan@systap.com
> > http://blazegraph.com
> > http://blog.blazegraph.com
> >
> > Blazegraph™ <http://www.blazegraph.com/> is our ultra high-performance
> > graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints
> > APIs. Blazegraph is now available with GPU acceleration using our
> disruptive
> > technology to accelerate data-parallel graph analytics and graph query.
> >
> > CONFIDENTIALITY NOTICE: This email and its contents and attachments are
> > for the sole use of the intended recipient(s) and are confidential or
> > proprietary to SYSTAP. Any unauthorized review, use, disclosure,
> > dissemination or copying of this email or its contents or attachments is
> > prohibited. If you have received this communication in error, please
> notify
> > the sender by reply email and permanently delete all copies of the email
> > and its contents and attachments.
> >
> > On Fri, Nov 13, 2015 at 10:21 AM, Greg Trasuk <tr...@trasuk.com>
> wrote:
> >
> >> Hello all:
> >>
> >> Last week I asked about removing activation from River, both the 2.2 and
> >> 3.0 branches. There didn’t seem to be a lot of anti-removal feeling, so
> >> I’d like to formally propose removing Activation. There are a couple of
> >> other things that we could possibly remove, like JRMP support (i.e.
> >> pre-compiled proxy classes), but we should probably discuss those
> >> separately.
> >>
> >> The main reason for this is that unused code still requires maintenance
> >> and increases the chance of bugs. Also I think that as we go forward
> with
> >> refactoring, renaming, restructuring the build and so on, it seems
> wasteful
> >> to do that work on code that isn’t actually in use.
> >>
> >> Obviously, the code remains in Subversion and in the 2.2.2 release, so
> if
> >> someone wants to get it back, we (or they) could package it into a
> >> different deliverable. But I wouldn’t plan on doing that unless there’s
> >> actual demand for it.
> >>
> >> My thought is to put this out there for discussion - If there is
> consensus
> >> after a few days I’ll call a lazy-consensus vote. I’ll be happy to do
> the
> >> work in the 2.2 branch.
> >>
> >> So, I propose to drop support for the following:
> >>
> >> Activation -
> >> com.sun.jini.phoenix.*
> >> com.sun.jini.phoenix.resources.*
> >> net.jini.activation.*
> >>
> >> Norm / LeaseRenewalService - is pretty much unneeded without activation
> >> com.sun.jini.norm.**
> >>
> >> Activatable implementation of the infrastructure services
> >> com.sun.jini.fiddler.ActivatableFiddlerImpl
> >> com.sun.jini.mahalo.ActivatableMahaloImpl
> >> com.sun.jini.mercury.ActivatableMercuryImpl
> >> com.sun.jini.reggie.PersistentRegistrarImpl
> >>
> >> Starter for Activatable Services
> >> com.sun.jini.start.ActivateWrapper
> >> com.sun.jini.start.SharedActivatableServiceDescriptor
> >> com.sun.jini.start.SharedGroupImpl
> >>
> >> QA Harness classes that test any of the above.
> >>
> >>
> >> Cheers,
> >>
> >> Greg Trasuk
> >>
> >>
>
>
Re: [Discuss] Drop support for Activation?
Posted by Bryan Thompson <br...@systap.com>.
Sounds just like the overhead of object relational mappers. Fine for one
object. Death if you are trying to chase object graphs....
On Nov 13, 2015 3:11 PM, "Greg Trasuk" <tr...@stratuscom.com> wrote:
>
> > On Nov 13, 2015, at 2:21 PM, Bryan Thompson <br...@systap.com> wrote:
> >
> > I was trying to remember precisely what is in "activation". I found this
> > [1]. From [1]:
> >
> > "Distributed object systems are designed to support long-lived persistent
> > objects. Given that these systems will be made up of many thousands
> > (perhaps millions) of such objects, it would be unreasonable for object
> > implementations to become active and remain active, taking up valuable
> > system resources for indefinite periods of time. In addition, clients
> need
> > the ability to store persistent references to objects so that
> communication
> > among objects can be re-established after a system crash, since
> typically a
> > reference to a distributed object is valid only while the object is
> active."
> >
> > So the concept here was long lived object references and robustness of
> > those references.
> >
> > This all seems very appropriate for IoT, but perhaps the goal of such
> > durable / robust / on demand (re-)activation of services is now met
> through
> > other mechanisms? Something that does not need to be part of River?
> >
>
> “Long-lived persistent objects” reminds me of the Entity EJBs in EJB 1 and
> 2. The metaphor there was that every entity (e.g. a User) was represented
> by a persistent object, identified by a primary key, and you interacted
> with the entity by making remote method calls on the entity’s proxy. The
> problem was that the typical interaction would be ‘getName()’,
> ‘getEmail()’, 'getUserId()’, ‘getPhoneNumber()’, etc. By the time you had
> any useful interaction you might have made 10-15 remote method calls. Put
> twenty entities on a web page, and you might need to make hundreds of
> remote calls to display the page. In other words, the distributed objects
> were at the wrong level of granularity.
>
> If we have distributed services, on the other hand, we can readily
> accommodate the right granularity in the service design. In that case,
> though, activation only makes sense if we have so many services that it
> isn’t practical to keep them all alive at the same time. Typically you
> have a reasonable number of services in any given virtual machine
> instance. I suspect that if you really did have that many services that
> needed activation, you’d end up with a really slow system because the
> overhead of activating and passivating services would far outweigh the time
> spend in actual service calls.
>
> So, I don’t see much of a use case for Activation. I’m interested to see
> if anyone else does.
>
> Cheers,
>
> Greg Trasuk
>
> > Thanks,
> > Bryan
> >
> > [1]
> >
> http://www.javaworld.com/article/2076173/soa/activatable-jini-services--part-1--implement-rmi-activation.html
> >
> > ----
> > Bryan Thompson
> > Chief Scientist & Founder
> > SYSTAP, LLC
> > 4501 Tower Road
> > Greensboro, NC 27410
> > bryan@systap.com
> > http://blazegraph.com
> > http://blog.blazegraph.com
> >
> > Blazegraph™ <http://www.blazegraph.com/> is our ultra high-performance
> > graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints
> > APIs. Blazegraph is now available with GPU acceleration using our
> disruptive
> > technology to accelerate data-parallel graph analytics and graph query.
> >
> > CONFIDENTIALITY NOTICE: This email and its contents and attachments are
> > for the sole use of the intended recipient(s) and are confidential or
> > proprietary to SYSTAP. Any unauthorized review, use, disclosure,
> > dissemination or copying of this email or its contents or attachments is
> > prohibited. If you have received this communication in error, please
> notify
> > the sender by reply email and permanently delete all copies of the email
> > and its contents and attachments.
> >
> > On Fri, Nov 13, 2015 at 10:21 AM, Greg Trasuk <tr...@trasuk.com>
> wrote:
> >
> >> Hello all:
> >>
> >> Last week I asked about removing activation from River, both the 2.2 and
> >> 3.0 branches. There didn’t seem to be a lot of anti-removal feeling, so
> >> I’d like to formally propose removing Activation. There are a couple of
> >> other things that we could possibly remove, like JRMP support (i.e.
> >> pre-compiled proxy classes), but we should probably discuss those
> >> separately.
> >>
> >> The main reason for this is that unused code still requires maintenance
> >> and increases the chance of bugs. Also I think that as we go forward
> with
> >> refactoring, renaming, restructuring the build and so on, it seems
> wasteful
> >> to do that work on code that isn’t actually in use.
> >>
> >> Obviously, the code remains in Subversion and in the 2.2.2 release, so
> if
> >> someone wants to get it back, we (or they) could package it into a
> >> different deliverable. But I wouldn’t plan on doing that unless there’s
> >> actual demand for it.
> >>
> >> My thought is to put this out there for discussion - If there is
> consensus
> >> after a few days I’ll call a lazy-consensus vote. I’ll be happy to do
> the
> >> work in the 2.2 branch.
> >>
> >> So, I propose to drop support for the following:
> >>
> >> Activation -
> >> com.sun.jini.phoenix.*
> >> com.sun.jini.phoenix.resources.*
> >> net.jini.activation.*
> >>
> >> Norm / LeaseRenewalService - is pretty much unneeded without activation
> >> com.sun.jini.norm.**
> >>
> >> Activatable implementation of the infrastructure services
> >> com.sun.jini.fiddler.ActivatableFiddlerImpl
> >> com.sun.jini.mahalo.ActivatableMahaloImpl
> >> com.sun.jini.mercury.ActivatableMercuryImpl
> >> com.sun.jini.reggie.PersistentRegistrarImpl
> >>
> >> Starter for Activatable Services
> >> com.sun.jini.start.ActivateWrapper
> >> com.sun.jini.start.SharedActivatableServiceDescriptor
> >> com.sun.jini.start.SharedGroupImpl
> >>
> >> QA Harness classes that test any of the above.
> >>
> >>
> >> Cheers,
> >>
> >> Greg Trasuk
> >>
> >>
>
>
Re: [Discuss] Drop support for Activation?
Posted by Greg Trasuk <tr...@stratuscom.com>.
> On Nov 13, 2015, at 2:21 PM, Bryan Thompson <br...@systap.com> wrote:
>
> I was trying to remember precisely what is in "activation". I found this
> [1]. From [1]:
>
> "Distributed object systems are designed to support long-lived persistent
> objects. Given that these systems will be made up of many thousands
> (perhaps millions) of such objects, it would be unreasonable for object
> implementations to become active and remain active, taking up valuable
> system resources for indefinite periods of time. In addition, clients need
> the ability to store persistent references to objects so that communication
> among objects can be re-established after a system crash, since typically a
> reference to a distributed object is valid only while the object is active."
>
> So the concept here was long lived object references and robustness of
> those references.
>
> This all seems very appropriate for IoT, but perhaps the goal of such
> durable / robust / on demand (re-)activation of services is now met through
> other mechanisms? Something that does not need to be part of River?
>
“Long-lived persistent objects” reminds me of the Entity EJBs in EJB 1 and 2. The metaphor there was that every entity (e.g. a User) was represented by a persistent object, identified by a primary key, and you interacted with the entity by making remote method calls on the entity’s proxy. The problem was that the typical interaction would be ‘getName()’, ‘getEmail()’, 'getUserId()’, ‘getPhoneNumber()’, etc. By the time you had any useful interaction you might have made 10-15 remote method calls. Put twenty entities on a web page, and you might need to make hundreds of remote calls to display the page. In other words, the distributed objects were at the wrong level of granularity.
If we have distributed services, on the other hand, we can readily accommodate the right granularity in the service design. In that case, though, activation only makes sense if we have so many services that it isn’t practical to keep them all alive at the same time. Typically you have a reasonable number of services in any given virtual machine instance. I suspect that if you really did have that many services that needed activation, you’d end up with a really slow system because the overhead of activating and passivating services would far outweigh the time spend in actual service calls.
So, I don’t see much of a use case for Activation. I’m interested to see if anyone else does.
Cheers,
Greg Trasuk
> Thanks,
> Bryan
>
> [1]
> http://www.javaworld.com/article/2076173/soa/activatable-jini-services--part-1--implement-rmi-activation.html
>
> ----
> Bryan Thompson
> Chief Scientist & Founder
> SYSTAP, LLC
> 4501 Tower Road
> Greensboro, NC 27410
> bryan@systap.com
> http://blazegraph.com
> http://blog.blazegraph.com
>
> Blazegraph™ <http://www.blazegraph.com/> is our ultra high-performance
> graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints
> APIs. Blazegraph is now available with GPU acceleration using our disruptive
> technology to accelerate data-parallel graph analytics and graph query.
>
> CONFIDENTIALITY NOTICE: This email and its contents and attachments are
> for the sole use of the intended recipient(s) and are confidential or
> proprietary to SYSTAP. Any unauthorized review, use, disclosure,
> dissemination or copying of this email or its contents or attachments is
> prohibited. If you have received this communication in error, please notify
> the sender by reply email and permanently delete all copies of the email
> and its contents and attachments.
>
> On Fri, Nov 13, 2015 at 10:21 AM, Greg Trasuk <tr...@trasuk.com> wrote:
>
>> Hello all:
>>
>> Last week I asked about removing activation from River, both the 2.2 and
>> 3.0 branches. There didn’t seem to be a lot of anti-removal feeling, so
>> I’d like to formally propose removing Activation. There are a couple of
>> other things that we could possibly remove, like JRMP support (i.e.
>> pre-compiled proxy classes), but we should probably discuss those
>> separately.
>>
>> The main reason for this is that unused code still requires maintenance
>> and increases the chance of bugs. Also I think that as we go forward with
>> refactoring, renaming, restructuring the build and so on, it seems wasteful
>> to do that work on code that isn’t actually in use.
>>
>> Obviously, the code remains in Subversion and in the 2.2.2 release, so if
>> someone wants to get it back, we (or they) could package it into a
>> different deliverable. But I wouldn’t plan on doing that unless there’s
>> actual demand for it.
>>
>> My thought is to put this out there for discussion - If there is consensus
>> after a few days I’ll call a lazy-consensus vote. I’ll be happy to do the
>> work in the 2.2 branch.
>>
>> So, I propose to drop support for the following:
>>
>> Activation -
>> com.sun.jini.phoenix.*
>> com.sun.jini.phoenix.resources.*
>> net.jini.activation.*
>>
>> Norm / LeaseRenewalService - is pretty much unneeded without activation
>> com.sun.jini.norm.**
>>
>> Activatable implementation of the infrastructure services
>> com.sun.jini.fiddler.ActivatableFiddlerImpl
>> com.sun.jini.mahalo.ActivatableMahaloImpl
>> com.sun.jini.mercury.ActivatableMercuryImpl
>> com.sun.jini.reggie.PersistentRegistrarImpl
>>
>> Starter for Activatable Services
>> com.sun.jini.start.ActivateWrapper
>> com.sun.jini.start.SharedActivatableServiceDescriptor
>> com.sun.jini.start.SharedGroupImpl
>>
>> QA Harness classes that test any of the above.
>>
>>
>> Cheers,
>>
>> Greg Trasuk
>>
>>
Re: [Discuss] Drop support for Activation?
Posted by Greg Trasuk <tr...@stratuscom.com>.
> On Nov 13, 2015, at 2:21 PM, Bryan Thompson <br...@systap.com> wrote:
>
> I was trying to remember precisely what is in "activation". I found this
> [1]. From [1]:
>
> "Distributed object systems are designed to support long-lived persistent
> objects. Given that these systems will be made up of many thousands
> (perhaps millions) of such objects, it would be unreasonable for object
> implementations to become active and remain active, taking up valuable
> system resources for indefinite periods of time. In addition, clients need
> the ability to store persistent references to objects so that communication
> among objects can be re-established after a system crash, since typically a
> reference to a distributed object is valid only while the object is active."
>
> So the concept here was long lived object references and robustness of
> those references.
>
> This all seems very appropriate for IoT, but perhaps the goal of such
> durable / robust / on demand (re-)activation of services is now met through
> other mechanisms? Something that does not need to be part of River?
>
“Long-lived persistent objects” reminds me of the Entity EJBs in EJB 1 and 2. The metaphor there was that every entity (e.g. a User) was represented by a persistent object, identified by a primary key, and you interacted with the entity by making remote method calls on the entity’s proxy. The problem was that the typical interaction would be ‘getName()’, ‘getEmail()’, 'getUserId()’, ‘getPhoneNumber()’, etc. By the time you had any useful interaction you might have made 10-15 remote method calls. Put twenty entities on a web page, and you might need to make hundreds of remote calls to display the page. In other words, the distributed objects were at the wrong level of granularity.
If we have distributed services, on the other hand, we can readily accommodate the right granularity in the service design. In that case, though, activation only makes sense if we have so many services that it isn’t practical to keep them all alive at the same time. Typically you have a reasonable number of services in any given virtual machine instance. I suspect that if you really did have that many services that needed activation, you’d end up with a really slow system because the overhead of activating and passivating services would far outweigh the time spend in actual service calls.
So, I don’t see much of a use case for Activation. I’m interested to see if anyone else does.
Cheers,
Greg Trasuk
> Thanks,
> Bryan
>
> [1]
> http://www.javaworld.com/article/2076173/soa/activatable-jini-services--part-1--implement-rmi-activation.html
>
> ----
> Bryan Thompson
> Chief Scientist & Founder
> SYSTAP, LLC
> 4501 Tower Road
> Greensboro, NC 27410
> bryan@systap.com
> http://blazegraph.com
> http://blog.blazegraph.com
>
> Blazegraph™ <http://www.blazegraph.com/> is our ultra high-performance
> graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints
> APIs. Blazegraph is now available with GPU acceleration using our disruptive
> technology to accelerate data-parallel graph analytics and graph query.
>
> CONFIDENTIALITY NOTICE: This email and its contents and attachments are
> for the sole use of the intended recipient(s) and are confidential or
> proprietary to SYSTAP. Any unauthorized review, use, disclosure,
> dissemination or copying of this email or its contents or attachments is
> prohibited. If you have received this communication in error, please notify
> the sender by reply email and permanently delete all copies of the email
> and its contents and attachments.
>
> On Fri, Nov 13, 2015 at 10:21 AM, Greg Trasuk <tr...@trasuk.com> wrote:
>
>> Hello all:
>>
>> Last week I asked about removing activation from River, both the 2.2 and
>> 3.0 branches. There didn’t seem to be a lot of anti-removal feeling, so
>> I’d like to formally propose removing Activation. There are a couple of
>> other things that we could possibly remove, like JRMP support (i.e.
>> pre-compiled proxy classes), but we should probably discuss those
>> separately.
>>
>> The main reason for this is that unused code still requires maintenance
>> and increases the chance of bugs. Also I think that as we go forward with
>> refactoring, renaming, restructuring the build and so on, it seems wasteful
>> to do that work on code that isn’t actually in use.
>>
>> Obviously, the code remains in Subversion and in the 2.2.2 release, so if
>> someone wants to get it back, we (or they) could package it into a
>> different deliverable. But I wouldn’t plan on doing that unless there’s
>> actual demand for it.
>>
>> My thought is to put this out there for discussion - If there is consensus
>> after a few days I’ll call a lazy-consensus vote. I’ll be happy to do the
>> work in the 2.2 branch.
>>
>> So, I propose to drop support for the following:
>>
>> Activation -
>> com.sun.jini.phoenix.*
>> com.sun.jini.phoenix.resources.*
>> net.jini.activation.*
>>
>> Norm / LeaseRenewalService - is pretty much unneeded without activation
>> com.sun.jini.norm.**
>>
>> Activatable implementation of the infrastructure services
>> com.sun.jini.fiddler.ActivatableFiddlerImpl
>> com.sun.jini.mahalo.ActivatableMahaloImpl
>> com.sun.jini.mercury.ActivatableMercuryImpl
>> com.sun.jini.reggie.PersistentRegistrarImpl
>>
>> Starter for Activatable Services
>> com.sun.jini.start.ActivateWrapper
>> com.sun.jini.start.SharedActivatableServiceDescriptor
>> com.sun.jini.start.SharedGroupImpl
>>
>> QA Harness classes that test any of the above.
>>
>>
>> Cheers,
>>
>> Greg Trasuk
>>
>>
Re: [Discuss] Drop support for Activation?
Posted by Bryan Thompson <br...@systap.com>.
I was trying to remember precisely what is in "activation". I found this
[1]. From [1]:
"Distributed object systems are designed to support long-lived persistent
objects. Given that these systems will be made up of many thousands
(perhaps millions) of such objects, it would be unreasonable for object
implementations to become active and remain active, taking up valuable
system resources for indefinite periods of time. In addition, clients need
the ability to store persistent references to objects so that communication
among objects can be re-established after a system crash, since typically a
reference to a distributed object is valid only while the object is active."
So the concept here was long lived object references and robustness of
those references.
This all seems very appropriate for IoT, but perhaps the goal of such
durable / robust / on demand (re-)activation of services is now met through
other mechanisms? Something that does not need to be part of River?
Thanks,
Bryan
[1]
http://www.javaworld.com/article/2076173/soa/activatable-jini-services--part-1--implement-rmi-activation.html
----
Bryan Thompson
Chief Scientist & Founder
SYSTAP, LLC
4501 Tower Road
Greensboro, NC 27410
bryan@systap.com
http://blazegraph.com
http://blog.blazegraph.com
Blazegraph™ <http://www.blazegraph.com/> is our ultra high-performance
graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints
APIs. Blazegraph is now available with GPU acceleration using our disruptive
technology to accelerate data-parallel graph analytics and graph query.
CONFIDENTIALITY NOTICE: This email and its contents and attachments are
for the sole use of the intended recipient(s) and are confidential or
proprietary to SYSTAP. Any unauthorized review, use, disclosure,
dissemination or copying of this email or its contents or attachments is
prohibited. If you have received this communication in error, please notify
the sender by reply email and permanently delete all copies of the email
and its contents and attachments.
On Fri, Nov 13, 2015 at 10:21 AM, Greg Trasuk <tr...@trasuk.com> wrote:
> Hello all:
>
> Last week I asked about removing activation from River, both the 2.2 and
> 3.0 branches. There didn’t seem to be a lot of anti-removal feeling, so
> I’d like to formally propose removing Activation. There are a couple of
> other things that we could possibly remove, like JRMP support (i.e.
> pre-compiled proxy classes), but we should probably discuss those
> separately.
>
> The main reason for this is that unused code still requires maintenance
> and increases the chance of bugs. Also I think that as we go forward with
> refactoring, renaming, restructuring the build and so on, it seems wasteful
> to do that work on code that isn’t actually in use.
>
> Obviously, the code remains in Subversion and in the 2.2.2 release, so if
> someone wants to get it back, we (or they) could package it into a
> different deliverable. But I wouldn’t plan on doing that unless there’s
> actual demand for it.
>
> My thought is to put this out there for discussion - If there is consensus
> after a few days I’ll call a lazy-consensus vote. I’ll be happy to do the
> work in the 2.2 branch.
>
> So, I propose to drop support for the following:
>
> Activation -
> com.sun.jini.phoenix.*
> com.sun.jini.phoenix.resources.*
> net.jini.activation.*
>
> Norm / LeaseRenewalService - is pretty much unneeded without activation
> com.sun.jini.norm.**
>
> Activatable implementation of the infrastructure services
> com.sun.jini.fiddler.ActivatableFiddlerImpl
> com.sun.jini.mahalo.ActivatableMahaloImpl
> com.sun.jini.mercury.ActivatableMercuryImpl
> com.sun.jini.reggie.PersistentRegistrarImpl
>
> Starter for Activatable Services
> com.sun.jini.start.ActivateWrapper
> com.sun.jini.start.SharedActivatableServiceDescriptor
> com.sun.jini.start.SharedGroupImpl
>
> QA Harness classes that test any of the above.
>
>
> Cheers,
>
> Greg Trasuk
>
>
Re: [Discuss] Drop support for Activation?
Posted by Bryan Thompson <br...@systap.com>.
I was trying to remember precisely what is in "activation". I found this
[1]. From [1]:
"Distributed object systems are designed to support long-lived persistent
objects. Given that these systems will be made up of many thousands
(perhaps millions) of such objects, it would be unreasonable for object
implementations to become active and remain active, taking up valuable
system resources for indefinite periods of time. In addition, clients need
the ability to store persistent references to objects so that communication
among objects can be re-established after a system crash, since typically a
reference to a distributed object is valid only while the object is active."
So the concept here was long lived object references and robustness of
those references.
This all seems very appropriate for IoT, but perhaps the goal of such
durable / robust / on demand (re-)activation of services is now met through
other mechanisms? Something that does not need to be part of River?
Thanks,
Bryan
[1]
http://www.javaworld.com/article/2076173/soa/activatable-jini-services--part-1--implement-rmi-activation.html
----
Bryan Thompson
Chief Scientist & Founder
SYSTAP, LLC
4501 Tower Road
Greensboro, NC 27410
bryan@systap.com
http://blazegraph.com
http://blog.blazegraph.com
Blazegraph™ <http://www.blazegraph.com/> is our ultra high-performance
graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints
APIs. Blazegraph is now available with GPU acceleration using our disruptive
technology to accelerate data-parallel graph analytics and graph query.
CONFIDENTIALITY NOTICE: This email and its contents and attachments are
for the sole use of the intended recipient(s) and are confidential or
proprietary to SYSTAP. Any unauthorized review, use, disclosure,
dissemination or copying of this email or its contents or attachments is
prohibited. If you have received this communication in error, please notify
the sender by reply email and permanently delete all copies of the email
and its contents and attachments.
On Fri, Nov 13, 2015 at 10:21 AM, Greg Trasuk <tr...@trasuk.com> wrote:
> Hello all:
>
> Last week I asked about removing activation from River, both the 2.2 and
> 3.0 branches. There didn’t seem to be a lot of anti-removal feeling, so
> I’d like to formally propose removing Activation. There are a couple of
> other things that we could possibly remove, like JRMP support (i.e.
> pre-compiled proxy classes), but we should probably discuss those
> separately.
>
> The main reason for this is that unused code still requires maintenance
> and increases the chance of bugs. Also I think that as we go forward with
> refactoring, renaming, restructuring the build and so on, it seems wasteful
> to do that work on code that isn’t actually in use.
>
> Obviously, the code remains in Subversion and in the 2.2.2 release, so if
> someone wants to get it back, we (or they) could package it into a
> different deliverable. But I wouldn’t plan on doing that unless there’s
> actual demand for it.
>
> My thought is to put this out there for discussion - If there is consensus
> after a few days I’ll call a lazy-consensus vote. I’ll be happy to do the
> work in the 2.2 branch.
>
> So, I propose to drop support for the following:
>
> Activation -
> com.sun.jini.phoenix.*
> com.sun.jini.phoenix.resources.*
> net.jini.activation.*
>
> Norm / LeaseRenewalService - is pretty much unneeded without activation
> com.sun.jini.norm.**
>
> Activatable implementation of the infrastructure services
> com.sun.jini.fiddler.ActivatableFiddlerImpl
> com.sun.jini.mahalo.ActivatableMahaloImpl
> com.sun.jini.mercury.ActivatableMercuryImpl
> com.sun.jini.reggie.PersistentRegistrarImpl
>
> Starter for Activatable Services
> com.sun.jini.start.ActivateWrapper
> com.sun.jini.start.SharedActivatableServiceDescriptor
> com.sun.jini.start.SharedGroupImpl
>
> QA Harness classes that test any of the above.
>
>
> Cheers,
>
> Greg Trasuk
>
>