Hi @RAJ,

I don't know the intricate details of threading and update/image integrity if you try to request for the same item that you already have open, but I would imagine there likely isn't any guarantees given the complexities and settings that can be set within the ADS. For example, you can configure the ADS without caching thus when you make a request for a snapshot, if has to navigate back into the infrastructure within the server to fulfill the request, while trying to coordinate potential update blasts with your open stream.

What are you trying to achieve? If you have concerns about the fine details of the message integrity, you need to rely on the open stream to manage your state - not trying to reach within the infrastructure to perform snapshots on open streams. This kind of defeats the purpose of the streaming, real-time nature of the system. The instrument you are managing within memory should be the golden copy representing the up-to-date state of the item. You only should be requesting for snapshots if you are not managing the state of the item within memory.

I'm planning to use a latest image from application memory based on the open stream. Just wanted to find out if doing snapshot on the open stream is an option in this scenario.

Hello @RAJ,

I think what you are trying to do is reissue:

"A consumer application can issue a subsequent RequestMsg using the existing streamId, referred to as a reissue. "

When you reissue, the stream is fully reestablished. The consequent updates will be fully conformant with the latest image. You may miss an update that you would have had otherwise on that stream, in this case it will be applied to the image. The image will have the complete and latest state at the time it is published.

Hope this helps?

Hi @zoya.farberov,

When I make a reissue request, I would like the cache in my application that is kept up to date with the previous stream to be accurate till I get the new latest image. Are you saying that I might miss updates that would make the data I have in application cache suspect between the time I make the reissue till I get the new latest image ?

Hi @RAJ

Absolutely. That is because reissue is designed to fully reestablish the stream, often, with changes to it.

This functionality in ETA is not designed to fully implement cache refresh in the application, the work will have to be done in the application.

It's an interesting question to discuss. I would consider a couple of approaches.

1. Reissue with a single stream is the simplest to implement, but it allows for updates missed. The state becomes complete as soon as the image is received on the reissued stream.

2. You could create a new, second stream. Once that stream is established, the cache is supplied from it, and the original stream is closed.

3. Lastly, you could just request a snapshot on the new stream. That creates a very interesting synchronization pbm.

Let me step back and mention Value Add for UPA, have you considered VA payload cache, would it satisfy your use case?

Hi @zoya.farberov,

Option #1 would not work for us as we would miss updates.

Option #2: I thought ETA API doesn't allow a new stream to be opened if there is an existing stream available. Is it not correct ?

Option #3 has an issue similar to #1 as there is no guarantee of data integrity if stream updates are applied after snapshot image is used.

So, it looks like the client application need to solve the problem internally with the cached image it has in memory.

My understanding of Value Add ETA package is that we can't pick and choose specific functionality to use, but rather take it as a whole to use any of its feature. Is that not so ?

Hi @RAJ,

#2, :) in theory, yes. In practice, however, the default behavior is the most straightforward, to maintain a single stream per item and to reopen it on the second request.

Taking this thought further, once we are looking in this direction, I would recommend going with EMA or VA where this work has already been done, and gone through multiple iterations of thorough testing.

EMA also allows two streams for the same item, but in addition, they are easy to manage- pass different closures into registerClient, and every update will be clearly identifiable by it's closure as belonging to a specific stream. For example, see two closures 77 and 22 passed into EMA Java on register:

consumer.registerClient(reqMsg.serviceName("ELEKTRON_EDGE").name("JPY="), appClient, new Integer(77));
consumer.registerClient(reqMsg.serviceName("ELEKTRON_EDGE").name("JPY="), appClient, new Integer(22));

ValueAdd can not be dissected into parts, you have an option of building your app on top of VA if it works for your use case- it also saves you time (EMA uses VA).

It seems, it really appears, as if you may be looking at a lot of effort, to rebuild and fully test in ETA the functionality, that can potentially be available in using EMA or ETA VA.

If you decide to proceed, consider first reviewing open source EMA from Elektron-SDK available on github.

Hi @RAJ,

Correction to 1) as we got a confirmation from out Enterprise team that doing a streaming re-request on an existing normal stream, you will not miss updates from the ADS. Even though the stream is pending for a new image, ADS must still forward updates while waiting to satisfy the request as the stream is already active.

They suggested to just issue a re-request on the existing stream, versus requesting a new snapshot stream.

Regards,
Art.