Object Store Explained | Lightboard Series

[@4by4rusjo44]

Mate its very nice to listen to you and so is it possible to record some more longer videos please. good stuff.

[@rajeshs287]

Nice Explanation.Have one question ..Suppose we have an on prem application and another application running on cloudhub.They want to share the same object store instance.Can application running ONPREM access the object store using object store connector or REST API?

[@--Nath--]

Object store connector will only go to whatever the runtime plane you are running in has available. So on-prem will go to either disk/memory (if non clustered) or into hazelcast (if clustered). If you want to make values available for an on-prem app to retrieve/modify - I'd suggest exposing some HTTPS endpoints on that CloudHub app and calling it - that way you can limit what values end up in there and shield the details of whatever you're doing. There is a REST API for the Object Store v2 Service (which is what CloudHub apps end up using if they're using persistent object stores) but I wouldn't recommend trying to get to it that way - treat your on prem app like any other client wanting access to data and give them an endpoint(s) to call.

[@rangraopatil3229]

How OS works in cluster. When one API is deployed to more than one worker.

[@ksreedevi1]

it depends on deployment type and OS configuration . In case of cloud hub OS v2 is persistent so data distributed across workers . In On prem if is cluster and using persistent data is distributed. Like wise it mostly depends on deployment type and persistent vs transient OS

[@--Nath--]

Clustering is customer-hosted and Object store is shared via an in memory grid called hazelcast. Workers are cloudhub, which does not run in cluster mode (so no hazelcast) but it externalises the persistent object stores to a hosted service. That way multiple workers for a given app can see the key/value pairs.