Re: What's the current behaviour when we use the eviction filter + expiry plicy?

[Denis Magda]

Aaron, Mihail,

Frankly, I didn’t get the initial question nor the suggestion.

Just in case, this is the eviction policies' doc (reworked prior 2.0 release) 
and the expiration policies [2]. Note that the expiration is supported for 
entries cached in Java heap only.

Please look over the docs. Probably you’ll find a correct answer there. 

[1] https://apacheignite.readme.io/v2.1/docs/evictions
[2] https://apacheignite.readme.io/v2.1/docs/expiry-policies 


—
Denis

> On Sep 8, 2017, at 11:04 AM, Mikhail  wrote:
> 
> Hi Aaron,
> 
> I don't see anything similar for expiration like for eviction.
> I think the easiest solution is to put that data to another cache with no
> expiration policy.
> 
> Thanks,
> Mikhail.
> 
> 
> 
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Logging documentation

[Dmitriy Setrakyan]

Great!

I think the next task should be to explain expiration vs eviction. I am
seeing too many questions on it as well. At this point, I am also confused
about how it really works.

D.

On Fri, Sep 8, 2017 at 10:18 AM, Denis Magda  wrote:

> Unbelievable! So many years went by and finally we got this documentation
> ready. Thanks a lot Prachi!
>
> —
> Denis
>
> On Sep 8, 2017, at 9:48 AM, Prachi Garg  wrote:
>
> Hello Igniters,
>
> I see a lot of questions about logging in Ignite . Here is the
> documentation-  https://apacheignite.readme.io/docs/logging
>
> This should help answer most of your questions :)
>
> -P
>
>
>
>

Re: Why is PageSize limited to just 16kB?

[John Wilson]

Thanks Dmitry!

On Fri, Sep 8, 2017 at 4:57 AM, Dmitry Pavlov  wrote:

> Hi John,
>
>
>
> Quite long page will require Ignite to use much time during loading page
> from disk or write it back during checkpointing. Ignite is able to change
> field value pointwise within page in case of update. In that case and if
> too long page is selected, one field update, for example 1 byte will
> require ignite to checkpoint 16K+ of data at next checkpoint.
>
>
>
> Going deeply to techical details: 16 K limitation came from internal
> 2-byte addressing of data within page. There is internal offset named
> 'item' which is 2 bytes in length and has 2 bits flags in it. 2^14=16384
>
>
>
> Sincerely,
>
> Dmitriy Pavlov
>
>
> пт, 8 сент. 2017 г. в 0:22, John Wilson :
>
>> Hi,
>>
>> Ignite sets the maximum possible size for a page to 16KB. Why? What are
>> the drawbacks of having bigger page sizes?
>>
>> https://github.com/apache/ignite/blob/bd7bd226d959fbc686f6104a048106
>> b7b944347b/modules/core/src/main/java/org/apache/ignite/configuration/
>> MemoryConfiguration.java#L179
>>
>> Thanks,
>>
>

Re: What's the current behaviour when we use the eviction filter + expiry plicy?

[Mikhail]

Hi Aaron,

I don't see anything similar for expiration like for eviction.
I think the easiest solution is to put that data to another cache with no
expiration policy.

Thanks,
Mikhail.



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

Re: AWS Apache Ignite AMI startup.sh reports spurrious errors if options have blanks

[Mikhail]

Hi Dave,

where can I find startup.sh? 
it doesn't look like a part of Ignite sources.

Thanks,
Mikhail.



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

Re: Starting atomic sequence in Spring XML configuration

[Mikhail]

Hi,

Try to use lifecycleBeans:

https://apacheignite.readme.io/docs/ignite-life-cycle

after ignite starting you create a new sequence.

Thanks,
Mikhail.



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

Re: Cache Size Monitor -- without making a remote call??

[Chris Berry]

Wow. Thank you.
That looks like exactly what I need!
Thank you!




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

Re: Ignite node not stopping after segmentation

[Biren Shah]

We are on 2.0.

Thanks,
Biren

On 9/8/17, 9:51 AM, "Mikhail"  wrote:

Hi all,

I created a  ticket for further investigations:


https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_IGNITE-2D6323&d=DwICAg&c=Zok6nrOF6Fe0JtVEqKh3FEeUbToa1PtNBZf6G01cvEQ&r=rbkF1xy5tYmkV8VMdTRVaIVhaXCNGxmyTB5plfGtWuY&m=uzZiitEwF5QUYB1Cd5brGizW0MbK-uv3hZigSOD1CAg&s=Gk8LHYyTj0YslsKeA_gKC5D7Nc1McAMv1ypiEDCbJng&e=

 Biren, could you please confirm that you use the latest 2.1 version?

Thanks,
Michael.




--
Sent from: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__apache-2Dignite-2Dusers.70518.x6.nabble.com_&d=DwICAg&c=Zok6nrOF6Fe0JtVEqKh3FEeUbToa1PtNBZf6G01cvEQ&r=rbkF1xy5tYmkV8VMdTRVaIVhaXCNGxmyTB5plfGtWuY&m=uzZiitEwF5QUYB1Cd5brGizW0MbK-uv3hZigSOD1CAg&s=aVej7K3jUlvXvrdyJkLenRbQ0YRZu-qJkxxxwKaWYVM&e=

Re: ignite.destroyCache() method hangs the cluster

[Mikhail]

Hi, 

You use very obsolete version, please try the latest one: 2.1

Thanks,
Mikhail.



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

Re: Logging documentation

[Denis Magda]

Unbelievable! So many years went by and finally we got this documentation 
ready. Thanks a lot Prachi!

—
Denis

> On Sep 8, 2017, at 9:48 AM, Prachi Garg  wrote:
> 
> Hello Igniters,
> 
> I see a lot of questions about logging in Ignite . Here is the documentation- 
>  https://apacheignite.readme.io/docs/logging 
> 
> 
> This should help answer most of your questions :)
> 
> -P 
> 
> 

Re: Design question on the Ignite Web Session Clustering.

[Michael Cherkasov]

Hi,

I answered in SO, I copy it here:
"""
if you have a local cache for sessions and sticky sessions why do you need
to use ignite at all?

However, It's better to go with ignite, your app will have HA, if some node
is failed, the whole app still will work fine. I agree you should split app
cluster and ignite cluster, however, I think you shouldn't care about
connection problem about the server and client. This kind of problems
should lead to 500 error, would you emulate main storage if you DB go down
or you can't connect to it?
"""
Thanks,
Mikhail.

2017-09-07 20:12 GMT+03:00 Shrikant Patel :

> Hi All,
>
>
>
> I have design question about Ignite web session clustering.
>
>
>
> I have springboot app with UI. It clustered app ie multiple instance of 
> springboot app behind the load balancer. I am using 
> org.apache.ignite.cache.websession.WebSessionFilter()to intercept request and 
> create\manage session for any incoming request.
>
>
>
> I have 2 option
>
>
>
> 1.  Embed the ignite node inside springboot app. So have these embedded 
> ignite node (on each springboot JVM) be part of cluster. This way request 
> session is replicated across the entire springboot cluster. On load balancer 
> I don’t have to maintain the sticky connection. The request can go to any app 
> in round robin or least load algorithm.
>
>
>
> Few considerations
>
> a.  Architect is simple. I don’t have worry about the cache being down 
> etc.
>
> b.  Now the cache being embedded, its using CPU and memory from app jvm. 
> It has potential of starving my app of resources.
>
>
>
> 2.  Have ignite cluster running outside of app JVM. So now I run client 
> node in springboot app and connect to main ignite cluster.
>
>
>
> Few considerations
>
>
>
> a.  For any reason, if the client node cannot connect to main ignite 
> cluster. Do I have to manage the session manually and then push those session 
> manually at later point to the ignite cluster??
>
> b.  If I manage session locally I will need to have sticky connection on 
> the load balancer. Which I want to avoid if possible.
>
>
>1. I am leaning to approach 2, but want to make it simple. So if
>   client node cannot create session (override 
> org.apache.ignite.cache.websession.WebSessionFilter())
>   it redirects user to page indicating the app is down or to another app 
> node
>   in the cluster.
>
>
>
>
>
> Are there any other design approach I can take?
>
> Am I overlooking anything in either approach?
>
>
>
> If you have dealt with it, please share your thoughts.
>
>
>
> Thanks in advance.
>
> Shri
>
>
> This e-mail and its contents (to include attachments) are the property of
> National Health Systems, Inc., its subsidiaries and affiliates, including
> but not limited to Rx.com Community Healthcare Network, Inc. and its
> subsidiaries, and may contain confidential and proprietary or privileged
> information. If you are not the intended recipient of this e-mail, you are
> hereby notified that any unauthorized disclosure, copying, or distribution
> of this e-mail or of its attachments, or the taking of any unauthorized
> action based on information contained herein is strictly prohibited.
> Unauthorized use of information contained herein may subject you to civil
> and criminal prosecution and penalties. If you are not the intended
> recipient, please immediately notify the sender by telephone at
> 800-433-5719 or return e-mail and permanently delete the original e-mail.
>

Unsubscribe

[Jessie Lin]

Please unsubscribe

Re: Ignite node not stopping after segmentation

[Mikhail]

Hi all,

I created a  ticket for further investigations:

https://issues.apache.org/jira/browse/IGNITE-6323

 Biren, could you please confirm that you use the latest 2.1 version?

Thanks,
Michael.




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

Logging documentation

[Prachi Garg]

Hello Igniters,

I see a lot of questions about logging in Ignite . Here is the
documentation-  https://apacheignite.readme.io/docs/logging

This should help answer most of your questions :)

-P

Re: Cache Size Monitor -- without making a remote call??

[Alexey Kukushkin]

Chris,

I feel maybe there is a misunderstanding of how partitions assignment works
in Ignite. In brief, Ignite has public AffinityFunction

interface, which is responsible for assigning partitions to nodes. Default
implementation uses Rendezvous hashing
, which minimises number
or re-assignments as nodes join/leave the cluster to reduce traffic. You
can develop your own AffinityFunction

implementation where AffinityFunction#assignPartitions()
would assign nodes to each partition.

Thus, unless you provide your own AffinityFunction
,
every node in your cluster will be "primary". Still if you want "isPrimary"
method I think you could use CacheMetrics.getOffHeapPrimaryEntriesCount()
!= 0 or IgniteCache.localSize(CachePeekMode.PRIMARY) != 0.

Re: Cache Size Monitor -- without making a remote call??

[Alexey Kukushkin]

Chris,

Do you need other metrics besides the cache size? If not, then your code
above could be replaced with one line:

return ignite.cache(cacheName).localSize(CachePeekMode.PRIMARY);


-- 
Best regards,
Alexey

Re: Message Queue Size

[dkarachentsev]

Hi Rishi,

Yes, but you need set heap size at least 512M and proper off-heap size [1].
But you won't be able to store large amount of data, you will need to enable
persistence, it will allow to extend available memory with dis k[2].

[1] https://apacheignite.readme.io/v2.1/docs/memory-configuration
[2] https://apacheignite.readme.io/v2.1/docs/distributed-persistent-store

Thanks!
-Dmitry.



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

Re: Cache Size Monitor -- without making a remote call??

[Chris Berry]

Thank you very much for responding.

Yes, I am concerned whenever a call must be made to remote machines,
particularly when used by my monitoring framework -- because without that
data I am relatively blind.
And that call (for all metrics) must be very fast and not affect
performance.

Yesterday, I did an experiment using  

gauges.put("ignite.current.cache." + cacheName + ".size",
(Gauge) () -> (ignite.cache(cacheName).localMetrics().getSize()));

And this works (but is not great)
In the metrics framework, I must; 1) sum the size across all of the Nodes,
2) then divide by the number of copies (primary + backups)
And I have found that this is not always exactly the same number as what I
see from `cache.size(CachePeekMode.PRIMARY)` 

Is there any way that I can ask if a given Node contains a piece of the
Primary or the Backups for a given Cache?

I will consider using your async strategy above.

But what I really want is a local Node to know if it is a part of the
Primary or Backup, and simply report its size.

So I could do this:

 CacheMetric cm = ignite.cache(cacheName).localMetrics();
 return ((cm.isPrimary()) ? cm.size() : 0); 

Or perhaps, have every Node know the size of the Primary at any given time?
Maybe this could simply be a part of the heartbeats that are already sent
around today?

Thanks, 
-- Chris 



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

Re: Ignite Xmx configuration

[Nikolai Tikhonov]

Hi Anil,

Yes, you are right.

On Fri, Jul 28, 2017 at 3:29 PM, Anil  wrote:

> Hi Nikolai,
>
>
> So i need to add 4gb + indexes size as cache size for off-heap cache ?
>
> Thanks,
> Anil
>
> On 28 July 2017 at 17:23, Nikolai Tikhonov  wrote:
>
>> Indexes does not include in it. Indexes will occupy extra size.
>>
>> On Fri, Jul 28, 2017 at 12:21 PM, Anil  wrote:
>>
>>> 1.9 version
>>>
>>> On 28 July 2017 at 14:08, Nikolai Tikhonov  wrote:
>>>
 Which versioin ignite do you use?

 On Fri, Jul 28, 2017 at 11:12 AM, Anil  wrote:

> Hi Nikolai,
>
> One more question- documentation says the indexes are stored in off
> heap as well for off-heap cache?
>
> where does it store ? in the same 4 g (in my case) ? thanks.
>
> Regards,
> Anil
>
> On 28 July 2017 at 12:56, Anil  wrote:
>
>> Thanks Nikolai.
>>
>> On 28 July 2017 at 12:47, Nikolai Tikhonov 
>> wrote:
>>
>>> Hi!
>>>
>>> If you used off-heap cache then entry is not stored in heap memory.
>>> Hence Xmx is not related with cache size. You need to choose Xmx/Xms 
>>> based
>>> on your application requirements (how many object will be created by 
>>> your
>>> code). I guess that 2-4 Gb will be enough in your case.
>>>
>>> On Fri, Jul 28, 2017 at 9:59 AM, Anil  wrote:
>>>
 Hi Team,

 I have two off-heap caches with 4 gb size (per cache)  in my ignite
 node.

 What would be the Xmx setting for ignite node ?

 is it  2 * 4 + heap required ? or Xmx is not related to any of the
 cache size ? please clarify. thanks.


 Regards
 Anil



>>>
>>
>

>>>
>>
>

Re: Continuous Query event buffering OOME

[Nikolai Tikhonov]

Hi Michal,

I've looked at code and your points look reasonable. In now moment, how you
correct noted, you can decrease size of the buffer via
IGNITE_CONTINUOUS_QUERY_SERVER_BUFFER_SIZE property to 50 or 100.

On Tue, Sep 5, 2017 at 9:14 PM, mcherkasov  wrote:

> Hi Michal,
>
> Those buffers are required to make sure that all messages are delivered to
> all subscribers and delivered in right order.
> However I agree, 1M is a relatively large number for this.
>
> I will check this question with Continuous Query experts and will update
> you
> tomorrow.
>
> Thanks,
> Mikhail.
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Starting atomic sequence in Spring XML configuration

[kveskimae]

Hey,

Looking for a a way to start atomic sequences in Spring XML. My
configuration XML contains 


...

and 


...

I tried replacing both the cache and grid with a version that initializes
sequences like following




public class SequencesInitializingIgniteConfiguration implements
InitializingBean
{

@Override
public void afterPropertiesSet() throws Exception
{
final Ignite grid = Ignition.ignite("mygrid");

final IgniteAtomicSequence seq = grid.atomicSequence(...
}
}

but while building the properties the grid wasn't started yet... So I was
searching for sth in cache & ignite configuration or the schema XSD for a
way how can I add some atomic sequences to configuration, to no avail.

Any ideas how I might add some sequences to my Spring XML?

Kind regards,
Kristjan



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

ignite.destroyCache() method hangs the cluster

[Ender Ekici]

Hi,
We have a test machine which has 8 cores with 32Gb ram.
We are using ignite 1.8.3.
On ignite there is only one cache which has 10M records (db size 7Gb~
ignite cache size 14Gb~)
We reload this cache with a cron scheduler.(Every night)

For example:
cacheName: products (alias)
realCacheName: products+oldTimestamp

-cron triggered.
-create cache with name “products+newTimestamp”
-load data from db to cache
-when loading finishes, we map the products cache to
“products+newTimestamp” and later(after 1 min) destroy the old cache;

While we measuring the cache.get() times with only one client we
encountered 4.5sec delay while ignite.destroyCache(realOldCacheName)
operation.

On our production machine (200+ core with 500Gb ram)(a couple of 100M
records of caches), this delay dramatically increases to minutes and all
ignite clients hang while destroying the cache.

what can we do to destroy cache without hanging the cluster?

Re: Why is PageSize limited to just 16kB?

[Dmitry Pavlov]

Hi John,



Quite long page will require Ignite to use much time during loading page
from disk or write it back during checkpointing. Ignite is able to change
field value pointwise within page in case of update. In that case and if
too long page is selected, one field update, for example 1 byte will
require ignite to checkpoint 16K+ of data at next checkpoint.



Going deeply to techical details: 16 K limitation came from internal 2-byte
addressing of data within page. There is internal offset named 'item' which
is 2 bytes in length and has 2 bits flags in it. 2^14=16384



Sincerely,

Dmitriy Pavlov


пт, 8 сент. 2017 г. в 0:22, John Wilson :

> Hi,
>
> Ignite sets the maximum possible size for a page to 16KB. Why? What are
> the drawbacks of having bigger page sizes?
>
>
> https://github.com/apache/ignite/blob/bd7bd226d959fbc686f6104a048106b7b944347b/modules/core/src/main/java/org/apache/ignite/configuration/MemoryConfiguration.java#L179
>
>
> Thanks,
>

unsubscribe

[????]

-- Original --
From: waterg 
Date: Fri,Sep 8,2017 0:03 PM
To: user 
Subject: Re: unsubscribe







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

Re: Cache Size Monitor -- without making a remote call??

[Alexey Kukushkin]

Hi Chris,

As I understand your concern is "Many times I have seen this particular
call take quite a while to return". Are you concerned with asynchronous
nature of IgniteCache#size() or you think the existing implementation is
too slow and your own implementation would be faster?

If this is the former then you can just use the async version that would
not delay your monitoring engine something like:

IgniteFuture sizeFut = cache.sizeAync(CahcePeekMode.PRIMARY);
sizeFut.chain(result -> {
 Integer totalSize = result.get(); /* in this callback you have the
total cache size */
});

If this is the latter - then why do you think your framework will be
faster? The existing implementation simply starts a SizeTask on all nodes,
which calls IgniteCache#localSize() on each node and the result is reduced
in your application. Not sure how you can further optimize it.


On Thu, Sep 7, 2017 at 9:39 PM, Chris Berry  wrote:

> Hi,
>
> I need to monitor cache size – in a PARTITIONED cache (a 10 Node Cluster –
> 2
> backups).
> And I need to monitor this in the PRIMARY – (I assume – to get the true
> size
> at any time)
> Thus my monitor will call `cache.size(CachePeekMode.PRIMARY)` every few
> seconds – and evaluate the size vs the expected minimum size
> (I have found that one sure way to know I’m in trouble is when the cache
> size drops – which means I lost data)
>
> This, in most cases, is a remote call
>
> This frightens me. And I want to somehow add some protection around this
> call.
> Many times I have seen this particular call take quite a while to return –
> and I cannot slow down my overall metrics gathering much.
> (FYI: it is a Dropwizard app w/ embedded Ignite, with Codahale metrics,
> polled every N seconds)
>
> It seems I have a few options.
>
> 1) Of course, I can do the call on separate Thread and assassinate it if it
> takes too long.
> But that doesn’t really solve
>
> 2) I hoped that `localMetrics` could have helped. But it seems to know only
> about its bit of things – as far as I can tell.
> At least when I go to the MBean and hit `size`
> But, perhaps this may still work??
> If I pass that local `size` as a metric. And then sum them in my metrics
> framework. Will that add up to the overall size (or is it size + backups)??
>
> 3) Is there any way to know which Nodes are keeping bits of the PRIMARY?
> Or do I have that wrong – and every Node will have a bit of the PRIMARY (my
> understanding is that some have PRIMARY and some have Backups)?
> Because, if so, I could report the size metric doing a localPeek and sum
> them in my metrics framework.
> I.e. something like::
> if (cache.isPrimary()) {
>  return cache.localSize()
> }
>
>
> THANKS,
> -- Chris
>
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>



-- 
Best regards,
Alexey

Re: Design question on the Ignite Web Session Clustering.

[Alison Mullan]

Hi Shri,

The very best way to get answers and advice on these kinds of questions is
to use the Apache Ignite Forum.
It is a very lively community and very supportive - register here
https://ignite.apache.org/

Let me know how you get on and if/when you would like to discuss
deployment/pricing/support issues for your end-users.
Best regards
Ali

On Thu, Sep 7, 2017 at 6:12 PM, Shrikant Patel  wrote:

> Hi All,
>
>
>
> I have design question about Ignite web session clustering.
>
>
>
> I have springboot app with UI. It clustered app ie multiple instance of 
> springboot app behind the load balancer. I am using 
> org.apache.ignite.cache.websession.WebSessionFilter()to intercept request and 
> create\manage session for any incoming request.
>
>
>
> I have 2 option
>
>
>
> 1.  Embed the ignite node inside springboot app. So have these embedded 
> ignite node (on each springboot JVM) be part of cluster. This way request 
> session is replicated across the entire springboot cluster. On load balancer 
> I don’t have to maintain the sticky connection. The request can go to any app 
> in round robin or least load algorithm.
>
>
>
> Few considerations
>
> a.  Architect is simple. I don’t have worry about the cache being down 
> etc.
>
> b.  Now the cache being embedded, its using CPU and memory from app jvm. 
> It has potential of starving my app of resources.
>
>
>
> 2.  Have ignite cluster running outside of app JVM. So now I run client 
> node in springboot app and connect to main ignite cluster.
>
>
>
> Few considerations
>
>
>
> a.  For any reason, if the client node cannot connect to main ignite 
> cluster. Do I have to manage the session manually and then push those session 
> manually at later point to the ignite cluster??
>
> b.  If I manage session locally I will need to have sticky connection on 
> the load balancer. Which I want to avoid if possible.
>
>
>1. I am leaning to approach 2, but want to make it simple. So if
>   client node cannot create session (override 
> org.apache.ignite.cache.websession.WebSessionFilter())
>   it redirects user to page indicating the app is down or to another app 
> node
>   in the cluster.
>
>
>
>
>
> Are there any other design approach I can take?
>
> Am I overlooking anything in either approach?
>
>
>
> If you have dealt with it, please share your thoughts.
>
>
>
> Thanks in advance.
>
> Shri
>
>
> This e-mail and its contents (to include attachments) are the property of
> National Health Systems, Inc., its subsidiaries and affiliates, including
> but not limited to Rx.com Community Healthcare Network, Inc. and its
> subsidiaries, and may contain confidential and proprietary or privileged
> information. If you are not the intended recipient of this e-mail, you are
> hereby notified that any unauthorized disclosure, copying, or distribution
> of this e-mail or of its attachments, or the taking of any unauthorized
> action based on information contained herein is strictly prohibited.
> Unauthorized use of information contained herein may subject you to civil
> and criminal prosecution and penalties. If you are not the intended
> recipient, please immediately notify the sender by telephone at
> 800-433-5719 <(800)%20433-5719> or return e-mail and permanently delete
> the original e-mail.
>



-- 
*Alison Mullan*
Business Development EMEA
GridGain systems
alison.mul...@gridgain.com
Phone: +44 7903 365482
www.gridgain.com

Re: Remote Listen in Apache Ignite .Net

[Pavel Tupitsyn]

Hi,

RemoteListen API is not supported in .NET [1] [2].
If you need cache change notifications, consider Continuous Queries [3].

[1] https://issues.apache.org/jira/browse/IGNITE-1683
[2] https://issues.apache.org/jira/browse/IGNITE-1683
[3] https://apacheignite-net.readme.io/docs/continuous-queries

On Fri, Sep 8, 2017 at 7:31 AM, Shuvendu Das <
shuvendu@travelcentrictechnology.com> wrote:

> Hi,
>
> Is there code sample for RemoteListen Of events in .net version of apche
> ignite.The code sample is available for Java version not for java version
>
> ignite.events(ignite.cluster().forCacheNodes("cacheName")).remoteListen(null, 
> rmtLsnr, 
> EventType.EVT_CACHE_OBJECT_PUT,
>   EventType.EVT_CACHE_OBJECT_READ,
>   EventType.EVT_CACHE_OBJECT_REMOVED);
>
>
> What the equivalent piece of code in .net version.
>
> Regards
>
> Shuvendu
>

Re: GROUP_CONCAT function is unsupported

[Vladimir Ozerov]

Hi,

This function is not supported yet. No immediate plans to fix it as there
are lots of tasks with higher priority and impact. But will definitely
support it at some point.

On Wed, Sep 6, 2017 at 11:38 AM, mhetea  wrote:

> Hello,
> I saw that the ticket was not fixed.
> Is there a workaround for this issue?
> I wouldn't like to iterate over the results and then concatenate them
> because the result list can be large.
> Thank you!
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>