topic Re: PerfObjGetInstancesRequest - Counters and Instances Type Restriction in Software Development Kit (SDK) and API Discussions

PerfObjGetInstancesRequest - Counters and Instances Type Restriction

VIEMEARD — Thu, 05 Jun 2025 06:05:10 GMT

Hi,

This probably is a question for the NetApp API developers directly.

The setCounters() and setInstances() methods in PerfObjGetInstancesRequest type require the arguments to be of type List<String>.

Is there a specific reason why this is the case ? Do they require to be internally represented as a List rather than a less restrictive Collection ?

If there is no specific need for the them to be arranged as a List then will it be possible to introduce methods in the next release which accept Collection type arguments as well ?

I came across this situation where it is possible that come client code is internally keeping a Set (or Map) type collection of the for e.g. Vservers and then want to query the counters for the Vservers. Where the Vserver names are the Keys in the maps i.e. a Set collection.

In the current form, there will have to be code written somewhere in the client application which provides a Set to List mapping of the Vservers before being able to run this request against an ApiRunner.

In case there is no real need internally in the implementation for a List type collection then will it be possible to provide API methods which accept Collection type arguments instead of a List type ?

Regards,

Gagan Grewal

Re: PerfObjGetInstancesRequest - Counters and Instances Type Restriction

sens — Tue, 16 Apr 2013 08:38:23 GMT

Hi Gagan,

Thanks for your feedback.

Most of the "array" type parameters are defined as "List<String>".

We will surely consider your suggestion to define these parameters as a "Collection" and we will check if we can provide the new definitions in the upcoming releases of NMSDK.

Regards,

Sen.

Re: PerfObjGetInstancesRequest - Counters and Instances Type Restriction

VIEMEARD — Tue, 16 Apr 2013 15:07:13 GMT

Hi Sens,

It does make sense in general to select List types as parameters where arrays are expected. But I am curious as to what specific functionality is being used from the List interface ? I am taking a somewhat wild guess that the API ultimately ends up calling a "toArray()" method to get an actual array representation of the Collection and then uses indexed access directly on that array rather then relying on Java SDK's List features. (I might be wrong... like I said I am guessing)

The "toArray()" method is actually very conveniently located in the Collection interface rather than in List interface

Anyways, some more background on this. This is what I tried...

I tried by creating a class which simply wraps a Set in a List, something like this...

class SetAsList<E> implements List<E> {

private static final UnsupportedOperationException UNSUPPORTED = new UnsupportedOperationException();

private Set<E> mySet;

public void wrap(Set<E> theSet) {

mySet = theSet;

}

// Implement all the methods enforced by List

// Throw UNSUPPORTED from the methods which exposed indexed functionality of a List for e.g. public E get(int index)

}

Then use the above class to actually wrap a key set from a HashMap which contains names of the Vservers. The use that SetAsList object to set the "List of instances" as per the API method signature.

And it worked !

If it were relying on any List specific functionality it would have thrown the runtime exception UNSUPPORTED.

Now, I am not saying this might be true for all possible statistics Objects, but it might be worthwhile taking a look into the code and possibly introducing additional methods which accept Collection type parameters. This will make the API a lot more consumer friendly. I am sure API consumers will heavily rely on HashMap based data structures (i.e. Maps and Sets) to interact with the appliances using the API and will possibly run up against cases such as the one I have come across.

Gagan Grewal