The idea are that we will have 2 nodes per call in a telephony setup.. A primary node for external service calls and a secondary node to follow the call around the system (agent/humans)..
This however can amount a lot.. On Mon, Jan 18, 2016 at 2:40 PM, Alexey Kuznetsov <akuznet...@gridgain.com> wrote: > Hi, Nino! > > I think it is quite crazy idea to setup 1000 concurrent clusters (if I > understand you correctly). > Starting 1000 nodes will be quite expensive. > > Could you please describe what business logic you are going to implement? > > It is not clear for me what are you expecting from Ignite and what Ignite > components do you need. > > From first glance you need Ignite Compute (to do some computations with > calls), but not need caching? > > If you need a compute only, I would recommend start 2-5 nodes and they will > easily process such small number (1000) of tasks. > > > On Mon, Jan 18, 2016 at 5:45 PM, nino martinez wael > <nino.martinez.w...@gmail.com> wrote: >> >> Hi >> >> We are considering using Ignite as a backend for our client / server >> environment (for Ignites key/value store). IT's a telephony based >> system, and the idea are that as a telephony CALL passes through the >> system Ignite nodes will follow the call adding and manipulating data. >> Each call would have it's own node cluster (as we don't need to share >> data between calls). There could be a lot of concurrent calls, max >> would probably be around 1000. >> >> So the question are how does Ignite handle >> * Cluster size of up to 1000 concurrent clusters (all based on a >> predicate) >> * A cluster where nodes will come and go and probably are error-prone >> * Realtime, it would be a problem if one node dies and the others have >> to wait for confirmation of death etc >> * OSGI, any issues? >> >> >> Please ask if I need to rephrase some of my questions >> >> -- >> Best regards / Med venlig hilsen >> Nino Martinez > > > > > -- > Alexey Kuznetsov > GridGain Systems > www.gridgain.com -- Best regards / Med venlig hilsen Nino Martinez