Re: [Sblim-devel] Java VM bug?

[Marcin G. <go...@go...>]

On Mon 12. November 2001 14:26, you wrote:
> The effect is based on the implementation of the "getInstance"

Hmm, I can see the problem, but probably the JVM shouldn't crash anyway ;-)

> method . As you can see in the code the CIMObjectPath parameter
> is used to extract the mount point of the filesystem ( in the
> current implementation stored in key "Name" ) . this mount point
> is then used to get all the other information about this special
> filesystem instance ( via getmntent() and a comparision between
> "Name" and mnt_dir ) . If you swap the content of the properties
> this possibility is lost . Now you need the instance instead of

I'm not sure, but from what you're saying getInstance gets only "Name"
property? I couldn't find any NPI docs and I haven't got so much time to dig
all the way through NPI code to find out. If so then it would be rational to
create some sort of a "provider cache" because enumeration of all the
instances stored in the CIMOM for every getInstance operation can be pretty
expensive (in regard both to CPU and to network utilization).

I thought of a simple cache that would be able to hold the result of
enumInstances so that getInstance would only need to look up in the cache
whether object of given name exists or not. The cache should be as general as
possible - i.e. it should be useful for RPM, fsvol and also for future
providers. I thought of a simple hashing table implementation, though maybe
some kind of Trie tree would be better?
Another question that needs to be answered before trying to implement such a
cache is what kind of information exactly has to be stored in the cache. The
Name property serves as the key (together with the namespace) but what is the
value? Is it enough to store CIMInstance returned by makeInst?

With such a cache enumInstance would invalidate all the existing cache
entries of the same class in the same namespace and create a vector of all
instances currently available on the computer. The vector would be returned
to CIMOM and also the elements stored in the cache. Then getInstance would be
a mere check if the object exists in the cache or not.

> This change has impact to the association LVM_ResidesOnExtent.c
> too . I was thinking about implementing its functionality in only
> one provider ( this would be Linux_ResidesOnExtent.c ) . What do
> you think ? Would this make sense ?

Frankly I do not feel competent to say anything as I haven't got LVM on my
computer and haven't had (yet) contact with LVM. Hope to change it in the
nearest future ;-)

> http://w3.opensource.ibm.com/projects/ibmcimom/

What is the ibmcimom project? Is IBM involved in creating it's own CIMOM?

gozdal@master:~$ host -t ns ibm.com
ibm.com                 NS      NS.AUSTIN.ibm.com
ibm.com                 NS      NS.WATSON.ibm.com
ibm.com                 NS      NS.ALMADEN.ibm.com
ibm.com                 NS      INTERNET-SERVER.ZURICH.ibm.com
ibm.com                 NS      NS.ERS.ibm.com
gozdal@master:~$ host -a w3.opensource.ibm.com NS.ERS.ibm.com
w3.opensource.ibm.com does not exist at NS.ERS.ibm.com (Authoritative answer)

--
Marcin Gozdalik <go...@go...>