Hi Val,

It's a very simple, and I would say a very common use case. We want to send a 
filter to the grid, receive a snapshot, and then receive a continuous stream of 
updates that match that filter.

Consider a trading window, showing a grid of stocks. I want to subscribe to the 
continuously changing market prices  for a specific list of stocks, and maybe I 
want to subscribe to trade events for another specific set. The universe of 
stocks is huge and not all users will want to see the same stocks, so server 
side filtering is key.

We are under time pressure, so for now we will probably end up building our own 
lightweight framework based on sockets and json for serialization between the 
java server side and the .net user app side. On the server side we will have to 
build a proxy service that will be responsible for managing subscriptions from 
the user apps, and then making those corresponding subscriptions onto the grid, 
using CQ. When it receives the results of the CQ it will need to serialize and 
push events back to the user apps.

The high level use case is that we have a java ignite cluster which implements 
our trading platform deployed into a data centre. And we have a C# .NET desktop 
app which currently hosts an ignite thick client. This user app needs to 
connect to clusters which might be in the metro area, or even in other 
countries. We have found for metro, it's okay, but not great (despite a huge 
amount of time tuning comms parameters), and for remote cities, its unusable. 
If we were .net to .net we could (for example) do this easily with WCF. The 
user app just needs to
- send RPC style commands (which we currently do using ignite service grid)
(eg. start / stop trading strategy)
- get cache snapshots based on some filter
(eg. show me all the orders on Microsoft for yesterday)
- subscribe to cache updates based on some filter
( eg. show me all the orders on Microsoft for today so far, placed by trading 
strategy X, and stream new orders or changes to existing orders as they occur)

Thanks,
Gordon.

-----Original Message-----
From: vkulichenko <[email protected]>
Sent: Tuesday, September 11, 2018 10:47 AM
To: [email protected]
Subject: RE: Ignite Thin Client Continuous Query

Gordon,

Yes, generally we do recommend using thin client for such applications.
However, it doesn't mean that you can't us client node in case it's really 
needed, although it might require some additional tuning.

Would you mind telling if you have any other technology in mind? I highly doubt 
that you will find anything that can provide functionality similar to CQ in 
Ignite, especially with the same delivery guarantees, while being based on a 
lightweight client. I believe you either will not succeed in finding such an 
alternative, or your use case does not require continuous queries in the first 
place. Can you give some more details on what you're trying to achieve? I might 
be able to suggest some other approach then.

-Val



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/


This email and any attachments are proprietary & confidential and are intended 
solely for the use of the individuals to whom it is addressed. Any views or 
opinions expressed are solely for those of the author and do not necessarily 
reflect those of Nine Mile Financial Pty. Limited. If you have received this 
email in error, please let us know immediately by reply email and delete from 
your system. Nine Mile Financial Pty. Limited. ABN: 346 1349 0252

Reply via email to