.getDistributedObjects call results in exception (under hzStarter) [API-1596]

[utkukaratas]

.getDistributedObjects call throws the following exception when my cluster is hzStarter (this is our internal utility in MC team; it fires up a 3 member cluster and utilizes the data structures.)

note that the same code works fine if my cluster is an IMDG instance started via bin/start.sh.

(tested in IMDG 4.2 and latest hazelcast-nodejs-client.)

ps. ping me at will; i can show this live.

[DefaultLogger] INFO at LifecycleService: HazelcastClient is STARTING
Lifecycle Event >>> STARTING
[DefaultLogger] INFO at LifecycleService: HazelcastClient is STARTED
Lifecycle Event >>> STARTED
[DefaultLogger] INFO at ConnectionManager: Trying to connect to 127.0.0.1:5701
[DefaultLogger] INFO at LifecycleService: HazelcastClient is CONNECTED
Lifecycle Event >>> CONNECTED
[DefaultLogger] INFO at ConnectionManager: Authenticated with server 127.0.0.1:5701:c642044f-a973-442f-8a2f-7755bb55374b, server version: 4.2, local address: 127.0.0.1:62314
[DefaultLogger] INFO at ClusterService:

Members [3] {
	Member [127.0.0.1]:5701 - c642044f-a973-442f-8a2f-7755bb55374b
	Member [127.0.0.1]:5703 - dd79a716-4a18-4c22-b630-7b6a3ccd0572 lite
	Member [127.0.0.1]:5702 - 055dcf8d-2a63-4558-9d14-57b81aea63ed
}

[DefaultLogger] INFO at ConnectionManager: Authenticated with server 127.0.0.1:5703:dd79a716-4a18-4c22-b630-7b6a3ccd0572, server version: 4.2, local address: 127.0.0.1:62315
[DefaultLogger] INFO at ConnectionManager: Authenticated with server 127.0.0.1:5702:055dcf8d-2a63-4558-9d14-57b81aea63ed, server version: 4.2, local address: 127.0.0.1:62316
hz.client_0
/Users/utku/dev/hz/hazelcast-explorer/node_modules/hazelcast-client/lib/proxy/ProxyManager.js:191
            localProxy = new this.service[serviceName](serviceName, name, this, this.partitionService, this.invocationService, this.serializationService, this.listenerService, this.clusterService, this.connectionRegistry);
                         ^

TypeError: this.service[serviceName] is not a constructor
    at ProxyManager.initializeLocalProxy (/Users/utku/dev/hz/hazelcast-explorer/node_modules/hazelcast-client/lib/proxy/ProxyManager.js:191:26)
    at /Users/utku/dev/hz/hazelcast-explorer/node_modules/hazelcast-client/lib/proxy/ProxyManager.js:87:25

[srknzl]

Thanks for reporting. Probably related to hzStarter that you are using.

In a getDistributedObjects call, the server returns DistributedObjectInfo list that has serviceName and name fields, and client uses that serviceName to choose a service in this.service object. I wonder which serviceName triggered this error. serviceName should not be one of these since we register them:

        this.service[ProxyManager.MAP_SERVICE] = MapProxy;
        this.service[ProxyManager.SET_SERVICE] = SetProxy;
        this.service[ProxyManager.QUEUE_SERVICE] = QueueProxy;
        this.service[ProxyManager.LIST_SERVICE] = ListProxy;
        this.service[ProxyManager.MULTIMAP_SERVICE] = MultiMapProxy;
        this.service[ProxyManager.RINGBUFFER_SERVICE] = RingbufferProxy;
        this.service[ProxyManager.REPLICATEDMAP_SERVICE] = ReplicatedMapProxy;
        this.service[ProxyManager.FLAKEID_SERVICE] = FlakeIdGeneratorProxy;
        this.service[ProxyManager.PNCOUNTER_SERVICE] = PNCounterProxy;
        this.service[ProxyManager.RELIABLETOPIC_SERVICE] = ReliableTopicProxy;

How can I run a hzStarter you mentioned?

[utkukaratas]

hmm i'd still expect the client code not crashing and give me my data structures as intact as possible (maybe via generating random service names and warning the user).

[srknzl]

I have a fix in #991 , now unknown proxies will be ignored from result instead of throwing.

[utkukaratas]

will test it on weekend @srknzl. i found this bug while coding some personal project.

[srknzl]

I opened the pr but as APIs team will discuss what to do, for all clients to be in sync. As a result, my proposed solution may change. WDYT? How should we deal with unknown proxy objects?(The problem was ICache service which does not exist in all non-java clients) Should we throw or ignore the objects that is unknown?

[utkukaratas]

@srknzl my vote is definitely on ignoring (and a very explicit warning message on stderr; instructing me what to do).

it's way above my pay grade to comment on the inner workings of it but as an ordinary user of this api i don't even want to hear about a "proxy object" and its non-existance :))

[srknzl]

thanks I am trying to apply the best UX

instructing me what to do

I dont think user has something to do. Also, if you check the pr, you will see that I went with documentation approach. i.e I said that unknown objects will be ignored from the result. Which one would you prefer: documentation, or warning to stderr, or both?

[srknzl]

btw you said you want a warning message and you dont want to hear about a proxy object. isnt this a conflict?

[utkukaratas]

Which one would you prefer: documentation, or warning to stderr, or both?

voting on both.

you dont want to hear about a proxy object. isnt this a conflict?

not if you ignore the stderr until you really have a look :D

[srknzl]

We discussed the issue, getDistributedObjects is currently broken from initial design, it may not work well. There are some open documents:

https://hazelcast.atlassian.net/wiki/spaces/IMDG/pages/1898218671/Fixing+the+Proxy+Management+Problems

https://hazelcast.atlassian.net/wiki/spaces/HZC/pages/1483081587/Client+Side+Proxy+Problems

We will either investigate the issue and solve the behaviour, or we will fix it in the API level. We tend to add UnknownProxy object instead of ignoring a proxy object. This way we don't have to log anything to stderr but the documentation will still mention UnknownProxy.

[github-actions[bot]]

Internal Jira issue: API-1596