Short lived Objects, exposure through Profile Service

[rareddy]

In Teiid, we create and track every request coming in from user in stateful manner until the request is fullfilled. While request in process, the user can go to an admin tool and has ability to 'cancel' that request. I am trying to provide is similar functionality through JOPR based tool.

To do this, I would like to expose 'request' objects through Profile Service, making a 'request' object as a 'ManagementObject' with property 'isRuntime=true' is the only way to expose them? Are there any alternatives?

Thank you.

Ramesh..

[emuckenhuber]

rareddy wrote:

In Teiid, we create and track every request coming in from user in stateful manner until the request is fullfilled. While request in process, the user can go to an admin tool and has ability to 'cancel' that request. I am trying to provide is similar functionality through JOPR based tool.

To do this, I would like to expose 'request' objects through Profile Service, making a 'request' object as a 'ManagementObject' with property 'isRuntime=true' is the only way to expose them? Are there any alternatives?

The creation of ManagedObjects and ManagedComponents is quite limited. We have some bigger changes planned to make this more flexible. However those changes are in planning for AS7, since we are focusing more on other aspects of ProfileService at the moment. So i think that trying to this at the moment would be not that easy, especially since reloading the ManagementView takes a while.

[rareddy]

Thanks. I will look forward for those enhancements.

In meanwhile, is this kind of patten discouraged in your opinion? Where marking the component as "runtime" and returning collection of objects.

@ManagementObject(name="RequestService", componentType=@ManagementComponent(type="teiid",subtype="requests"))
public class RequestService implements Serializable{
  List<Request> requests = ...;

  @ManagementProperty(description="Get the Requests in collection", use= {ViewUse.STATISTIC}, readOnly=true)
  public List<Request> getRequests(){
      return requests;
  }
}
@ManagementObject(componentType=@ManagementComponent(type="teiid",subtype="request"))
@MetaMapping(RequestMapper.class)
public class Request{
     long id;
     String query;
}

Where every call to "getRequests" will fetch new list 'Request' objects, and since a mapper class is defined for 'Request' it will not use 'GenericMetaType'. The monitoring application will be written to match to the Mapper class based properties.

[emuckenhuber]

Hmm ok in this case i would suggest using a CompositeValue instead of a ManagedComponent. The main problem is that there is some additional processing of ManagedObjects needed wich is done when we load/reload the ManagementView. This cannot be done on a property level, especially not the runtime behavior for components.

In general the values will get updated everytime you call getValue() on the ManagedProperty when your RequestService is a runtime component. Also the handling on the JON side should be easier for composite values.

There are also some annotations @CompositeKey, @CompositeValue so that you can e.g. ignore a property. So you might not even need a MetaMapper.

[rareddy]

Yes, I see the issue with @ManagementProperty being loaded each time management view is loaded. I switched it to @ManagementOperation instead on the "getRequests" call. Now "requests" collection is only loaded on demand.

Are you suggesting "Request" annotation to be changed to "@CompositeValue" instead of "@ManagedObject"?

Thanks.

Ramesh..

[emuckenhuber]

Hmm, yeah lazy loading of management properties is also on the todo list....

In this case i would recommend using a CompositeValue. There is no clear distinction when to use @ManagementObject or not, but in general this is intended to be used on deployment metadata. It might not really matter since managed operations are not processed until they are invoked, but the ManagedObject interface implies a lot of things which cannot be provided in this case.

Actually by removing the @ManagementObject annotation it should generate a CompositeValue by default - the annotations for CompositeValues are method annotations, so you can ignore some properties.

[emuckenhuber]

One thing i forgot to mentioned @CompositeKey and @CompositeValue are the only available annotations for a CompositeValue (the actual value type). All other management annotations won't be processed.