Race condition in IgniteScheduler.nextExecutionTime()

It seems there is a race condition between the IgniteScheduler scheduleLocal() and nextExecutionTime() methods, so that nextExecutionTime() sometimes reports the current execution time when called from with the closure being executed by scheduleLocal() - my hypothesis is that the data structures

Re: Exception on Ignite cluster shutdown

It’s all quite standard as far as I can tell. An external control process sends SIGTERM to the JVM, which initiates the Spring application context shutdown hook, which eventually results in the destroy() method on IgniteSpringBean being invoked, from which I presume normal cluster shutdown is tr

Exception on Ignite cluster shutdown

I observe this exception when my application hosting an Ignite cluster is shutdown (normal JVM termination, via SIGTERM): 2016-02-20T21:55:49.266+ [Thread-5] ERROR IgniteKernal%SOMOS_EN_FUEGO [] - Failed to pre-stop processor: GridProcessorAdapter [] javax.cache.CacheException: class org.apa

IgniteScheduler cron format extension {n1, n2}

Hello, As per the docs, IgniteScheduler allows you to include the special prefix {n1, n2} in the cron string where n1 is “delay of scheduling in seconds”. Could someone on the development team elaborate on what that means, exactly? Is n1 essentially trying to add a “seconds” field to the cron s

Re: Exception on cluster start after upgrading to GridGain Community Edition

That was it - the cache(s) names contain “:” characters. I hadn’t realized Ignite was constructing MBeans for all the caches. Perhaps there’s some quoting missing in the MBean name construction code? The set of valid MBean name strings is a subset of general strings. Thanks. On 2/16/16, 11:

Re: Exception on cluster start after upgrading to GridGain Community Edition

I see the same result with ignite-1.5.0.final. From: Stephen Scheck Reply-To: "user@ignite.apache.org" Date: Tuesday, February 16, 2016 at 10:05 AM To: "user@ignite.apache.org" Subject: Exception on cluster start after upgrading to Grid

Exception on cluster start after upgrading to GridGain Community Edition

Hi, I upgraded my application from Ignite 1.3.0-incubating to GridGain Community Edition (“1.5.6”). After doing that, I’m getting this exception on cluster start: 2016-02-16T17:53:56.570+ [exchange-worker-#83%SensorIQ%] ERROR GridDhtPartitionsExchangeFuture [] - Failed to reinitialize loca

Re: Exception when deploying cluster service

Val, I added this method and call it before submitting jobs to my CollisionSpi implementation’s processing logic: private boolean supportsAttributes(CollisionJobContext collisionJobContext) { return collisionJobContext.getJob().getClass().isAnnotationPresent(ComputeTaskSessionFullSupport.cl

Re: Exception when deploying cluster service

Yes. In fact I’ve defined my own CollisionSpi implementation which calls CollisionJobContext.getTaskSession().getAttribute() on the CollisionContext jobs. For my own jobs, I’ve used the @ComputeTaskSessionFullSupport annotation to make it work. I do see my CollisionSpi in the longer stack trace

Exception when deploying cluster service

I’m seeing this exception when my Service implementation calls loadCache() from within its init() method: Caused by: org.apache.ignite.IgniteCheckedException: class org.apache.ignite.IgniteCheckedException: Sessions attributes and checkpoints are disabled by default for better performance (to e

Re: IgniteAtomicSequence persistence

What about creating a cache with parameter with keys being the name of the sequences, that is itself persisted with a CacheStore implementation? On 2/3/16, 4:23 PM, "Steve Scheck" wrote: >I’m trying to migrate some tables that reside in a relational DB into Ignite >c

Re: IgniteAtomicSequence persistence

I’m trying to migrate some tables that reside in a relational DB into Ignite caches with write-behind persistence. The cache keys will correspond to sequence columns from the former relational schema. So I need a way to generate unique sequence numbers. Thanks. On 2/3/16, 4:08 PM, "vkulich

IgniteAtomicSequence persistence

Hello, Is there any automatic way or recommended pattern to persist an IgniteAtomicSequence? Thanks.

SchedulerFuture.nextExecutionTime() throws ArrayIndexOutOfBoundsException

Hello, When I schedule a schedule a task with IgniteScheduler.scheduleLocal(), then immediately call SchedulerFuture.nextExecutionTime(), Ignite throws an exception: SchedulerFuture schedulerFuture = scheduler.scheduleLocal(() -> dispatchNow(job), cronString); l