You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter Firmstone <ji...@zeus.net.au> on 2013/03/16 03:18:24 UTC
OutriggerImpl starts thread in constructor
I'd like to add a start() method to OutriggerImpl, so I can delay any
threads from being started until after construction is complete.
This is required for safe publication to comply with the JMM.
Before doing so, I'd like to know how people are using Outrigger, so I
can minimise unintended consequences / breakages.
Comments, opinions and thoughts?
Regards,
Peter.
Re: OutriggerImpl starts thread in constructor
Posted by Gregg Wonderly <gr...@wonderly.org>.
I'd suggest that we add a new interface that com.sun.jini.start provides which
lets all of the services declare this behavior, and let ServerStarter then have
something concrete to use.
ServiceDescriptor.create() could return this interface instead of Object.
Gregg Wonderly
On 3/15/2013 9:18 PM, Peter Firmstone wrote:
> I'd like to add a start() method to OutriggerImpl, so I can delay any threads
> from being started until after construction is complete.
>
> This is required for safe publication to comply with the JMM.
>
> Before doing so, I'd like to know how people are using Outrigger, so I can
> minimise unintended consequences / breakages.
>
> Comments, opinions and thoughts?
>
> Regards,
>
> Peter.
>
Re: Policy performance
Posted by Peter Firmstone <ji...@zeus.net.au>.
Ok,
This time I've attached a csv file (you should get that), it's from
jvisualvm.
Like I said, the new SecurityManager and Policy provider have really no
impact on application performance at all.
Regards,
Peter.
Peter Firmstone wrote:
> Thought you might like to see just how well the new Policy providers
> perform, see image attached (if it doesn't get scrubbed).
>
> Application performance is imperceptible with or without security
> enabled. The standard Java Policy provider has a much greater impact
> in comparison.
>
> Regards,
>
> Peter.
>
>
Policy performance
Posted by Peter Firmstone <ji...@zeus.net.au>.
Thought you might like to see just how well the new Policy providers
perform, see image attached (if it doesn't get scrubbed).
Application performance is imperceptible with or without security
enabled. The standard Java Policy provider has a much greater impact in
comparison.
Regards,
Peter.
Re: OutriggerImpl starts thread in constructor
Posted by Peter Firmstone <ji...@zeus.net.au>.
Provided it's used via com.sun.jini.start.ActivateWrapper it'll be ok.
NonActivatableServiceDescriptor also had to be modified to call the Starter.
Cheers,
Peter.
Dennis Reedy wrote:
> Gregg,
>
> You may be right. I'm curious, does anyone actually ever uses activation?
>
> Dennis
>
>
> On Mar 16, 2013, at 541PM, Gregg Wonderly wrote:
>
>
>> I don't think this will work with activation because the proxy is not what is returned in that case. It may be necessary to look at doing something in Phoenix as well, if we keep activation around.
>>
>> Gregg
>>
>> On Mar 16, 2013, at 4:22 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
>>
>>
>>> I dunno, it just seems to fit so well here, I didn't even have to change the documentation.
>>>
>>> /** Generic service creation method that attempts to start the
>>> * services defined by the provided <code>ServiceDescriptor[]</code>
>>> * argument.
>>> * @param descs The <code>ServiceDescriptor[]</code> that contains
>>> * the descriptors for the services to start.
>>> * @param config The associated <code>Configuration</code> object
>>> * used to customize the service creation process.
>>> * @return Returns a <code>Result[]</code> that is the same length as
>>> * <code>descs</code>, which contains the details for each
>>> * service creation attempt.
>>> * @throws Exception If there was a problem creating the service.
>>> * @see Result
>>> * @see ServiceDescriptor
>>> * @see net.jini.config.Configuration
>>> */
>>> private static Result[] create(final ServiceDescriptor[] descs,
>>> final Configuration config)
>>> throws Exception
>>> {
>>> logger.entering(ServiceStarter.class.getName(), "create",
>>> new Object[] {descs, config});
>>> ArrayList proxies = new ArrayList();
>>>
>>> Object result = null;
>>> Exception problem = null;
>>> ServiceDescriptor desc = null;
>>> for (int i=0; i < descs.length; i++) {
>>> desc = descs[i];
>>> result = null;
>>> problem = null;
>>> try {
>>> if (desc != null) {
>>> result = desc.create(config);
>>> if (result instanceof Starter) ((Starter) result).start();
>>> }
>>> } catch (Exception e) {
>>> problem = e;
>>> } finally {
>>> proxies.add(new Result(desc, result, problem));
>>> }
>>> }
>>> logger.exiting(ServiceStarter.class.getName(), "create", proxies);
>>> return (Result[])proxies.toArray(new Result[proxies.size()]);
>>> }
>>>
>>> Gregg Wonderly wrote:
>>>
>>>> Looking around briefly, it seems that there is a not so great set of returned values from ServiceDescriptor.create() with activation returning the RMI GID. So a little more work to wrap everything into something implementing an interface with lifecycle management in it would be required.
>>>>
>>>> Gregg
>>>>
>>>>
>>>> On 3/15/2013 9:18 PM, Peter Firmstone wrote:
>>>>
>>>>> I'd like to add a start() method to OutriggerImpl, so I can delay any threads from being started until after construction is complete.
>>>>>
>>>>> This is required for safe publication to comply with the JMM.
>>>>>
>>>>> Before doing so, I'd like to know how people are using Outrigger, so I can minimise unintended consequences / breakages.
>>>>>
>>>>> Comments, opinions and thoughts?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Peter.
>>>>>
>>>>>
>>>>
>
>
>
Re: OutriggerImpl starts thread in constructor
Posted by Dennis Reedy <de...@gmail.com>.
Gregg,
You may be right. I'm curious, does anyone actually ever uses activation?
Dennis
On Mar 16, 2013, at 541PM, Gregg Wonderly wrote:
> I don't think this will work with activation because the proxy is not what is returned in that case. It may be necessary to look at doing something in Phoenix as well, if we keep activation around.
>
> Gregg
>
> On Mar 16, 2013, at 4:22 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
>
>> I dunno, it just seems to fit so well here, I didn't even have to change the documentation.
>>
>> /** Generic service creation method that attempts to start the
>> * services defined by the provided <code>ServiceDescriptor[]</code>
>> * argument.
>> * @param descs The <code>ServiceDescriptor[]</code> that contains
>> * the descriptors for the services to start.
>> * @param config The associated <code>Configuration</code> object
>> * used to customize the service creation process.
>> * @return Returns a <code>Result[]</code> that is the same length as
>> * <code>descs</code>, which contains the details for each
>> * service creation attempt.
>> * @throws Exception If there was a problem creating the service.
>> * @see Result
>> * @see ServiceDescriptor
>> * @see net.jini.config.Configuration
>> */
>> private static Result[] create(final ServiceDescriptor[] descs,
>> final Configuration config)
>> throws Exception
>> {
>> logger.entering(ServiceStarter.class.getName(), "create",
>> new Object[] {descs, config});
>> ArrayList proxies = new ArrayList();
>>
>> Object result = null;
>> Exception problem = null;
>> ServiceDescriptor desc = null;
>> for (int i=0; i < descs.length; i++) {
>> desc = descs[i];
>> result = null;
>> problem = null;
>> try {
>> if (desc != null) {
>> result = desc.create(config);
>> if (result instanceof Starter) ((Starter) result).start();
>> }
>> } catch (Exception e) {
>> problem = e;
>> } finally {
>> proxies.add(new Result(desc, result, problem));
>> }
>> }
>> logger.exiting(ServiceStarter.class.getName(), "create", proxies);
>> return (Result[])proxies.toArray(new Result[proxies.size()]);
>> }
>>
>> Gregg Wonderly wrote:
>>> Looking around briefly, it seems that there is a not so great set of returned values from ServiceDescriptor.create() with activation returning the RMI GID. So a little more work to wrap everything into something implementing an interface with lifecycle management in it would be required.
>>>
>>> Gregg
>>>
>>>
>>> On 3/15/2013 9:18 PM, Peter Firmstone wrote:
>>>> I'd like to add a start() method to OutriggerImpl, so I can delay any threads from being started until after construction is complete.
>>>>
>>>> This is required for safe publication to comply with the JMM.
>>>>
>>>> Before doing so, I'd like to know how people are using Outrigger, so I can minimise unintended consequences / breakages.
>>>>
>>>> Comments, opinions and thoughts?
>>>>
>>>> Regards,
>>>>
>>>> Peter.
>>>>
>>>
>>>
>>
>
Re: OutriggerImpl starts thread in constructor
Posted by Gregg Wonderly <ge...@cox.net>.
I don't think this will work with activation because the proxy is not what is returned in that case. It may be necessary to look at doing something in Phoenix as well, if we keep activation around.
Gregg
On Mar 16, 2013, at 4:22 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
> I dunno, it just seems to fit so well here, I didn't even have to change the documentation.
>
> /** Generic service creation method that attempts to start the
> * services defined by the provided <code>ServiceDescriptor[]</code>
> * argument.
> * @param descs The <code>ServiceDescriptor[]</code> that contains
> * the descriptors for the services to start.
> * @param config The associated <code>Configuration</code> object
> * used to customize the service creation process.
> * @return Returns a <code>Result[]</code> that is the same length as
> * <code>descs</code>, which contains the details for each
> * service creation attempt.
> * @throws Exception If there was a problem creating the service.
> * @see Result
> * @see ServiceDescriptor
> * @see net.jini.config.Configuration
> */
> private static Result[] create(final ServiceDescriptor[] descs,
> final Configuration config)
> throws Exception
> {
> logger.entering(ServiceStarter.class.getName(), "create",
> new Object[] {descs, config});
> ArrayList proxies = new ArrayList();
>
> Object result = null;
> Exception problem = null;
> ServiceDescriptor desc = null;
> for (int i=0; i < descs.length; i++) {
> desc = descs[i];
> result = null;
> problem = null;
> try {
> if (desc != null) {
> result = desc.create(config);
> if (result instanceof Starter) ((Starter) result).start();
> }
> } catch (Exception e) {
> problem = e;
> } finally {
> proxies.add(new Result(desc, result, problem));
> }
> }
> logger.exiting(ServiceStarter.class.getName(), "create", proxies);
> return (Result[])proxies.toArray(new Result[proxies.size()]);
> }
>
> Gregg Wonderly wrote:
>> Looking around briefly, it seems that there is a not so great set of returned values from ServiceDescriptor.create() with activation returning the RMI GID. So a little more work to wrap everything into something implementing an interface with lifecycle management in it would be required.
>>
>> Gregg
>>
>>
>> On 3/15/2013 9:18 PM, Peter Firmstone wrote:
>>> I'd like to add a start() method to OutriggerImpl, so I can delay any threads from being started until after construction is complete.
>>>
>>> This is required for safe publication to comply with the JMM.
>>>
>>> Before doing so, I'd like to know how people are using Outrigger, so I can minimise unintended consequences / breakages.
>>>
>>> Comments, opinions and thoughts?
>>>
>>> Regards,
>>>
>>> Peter.
>>>
>>
>>
>
Re: OutriggerImpl starts thread in constructor
Posted by Peter Firmstone <ji...@zeus.net.au>.
I dunno, it just seems to fit so well here, I didn't even have to change
the documentation.
/** Generic service creation method that attempts to start the
* services defined by the provided <code>ServiceDescriptor[]</code>
* argument.
* @param descs The <code>ServiceDescriptor[]</code> that contains
* the descriptors for the services to start.
* @param config The associated <code>Configuration</code> object
* used to customize the service creation process.
* @return Returns a <code>Result[]</code> that is the same length as
* <code>descs</code>, which contains the details for each
* service creation attempt.
* @throws Exception If there was a problem creating the service.
* @see Result
* @see ServiceDescriptor
* @see net.jini.config.Configuration
*/
private static Result[] create(final ServiceDescriptor[] descs,
final Configuration config)
throws Exception
{
logger.entering(ServiceStarter.class.getName(), "create",
new Object[] {descs, config});
ArrayList proxies = new ArrayList();
Object result = null;
Exception problem = null;
ServiceDescriptor desc = null;
for (int i=0; i < descs.length; i++) {
desc = descs[i];
result = null;
problem = null;
try {
if (desc != null) {
result = desc.create(config);
if (result instanceof Starter) ((Starter)
result).start();
}
} catch (Exception e) {
problem = e;
} finally {
proxies.add(new Result(desc, result, problem));
}
}
logger.exiting(ServiceStarter.class.getName(), "create", proxies);
return (Result[])proxies.toArray(new Result[proxies.size()]);
}
Gregg Wonderly wrote:
> Looking around briefly, it seems that there is a not so great set of
> returned values from ServiceDescriptor.create() with activation
> returning the RMI GID. So a little more work to wrap everything into
> something implementing an interface with lifecycle management in it
> would be required.
>
> Gregg
>
>
> On 3/15/2013 9:18 PM, Peter Firmstone wrote:
>> I'd like to add a start() method to OutriggerImpl, so I can delay any
>> threads from being started until after construction is complete.
>>
>> This is required for safe publication to comply with the JMM.
>>
>> Before doing so, I'd like to know how people are using Outrigger, so
>> I can minimise unintended consequences / breakages.
>>
>> Comments, opinions and thoughts?
>>
>> Regards,
>>
>> Peter.
>>
>
>
Re: OutriggerImpl starts thread in constructor
Posted by Gregg Wonderly <gr...@wonderly.org>.
Looking around briefly, it seems that there is a not so great set of returned
values from ServiceDescriptor.create() with activation returning the RMI GID. So
a little more work to wrap everything into something implementing an interface
with lifecycle management in it would be required.
Gregg
On 3/15/2013 9:18 PM, Peter Firmstone wrote:
> I'd like to add a start() method to OutriggerImpl, so I can delay any threads
> from being started until after construction is complete.
>
> This is required for safe publication to comply with the JMM.
>
> Before doing so, I'd like to know how people are using Outrigger, so I can
> minimise unintended consequences / breakages.
>
> Comments, opinions and thoughts?
>
> Regards,
>
> Peter.
>