Hi Anil, Yes, you're right. Ignite vertx integration creates caches during work. The template needed for correct work.
On Thu, Jun 8, 2017 at 7:37 AM, Anil <[email protected]> wrote: > Hi Nikhonov, > > May I know the reason for adding template configuration. > > Its a generic cache configuration. I have added all cache configurations > required for my application explicitly in ignite.xml as we don't use java > based IgniteCache creation. I dont see any importance of adding template > configuration. please correct me if I am wrong. Thanks. > > Does vertex need any default caches/configurations for it to work? like > below semaphore in hazelcast cluster.xml > > <!-- Used internally in Vert.x to implement async locks --> > <semaphore name="__vertx.*"> > <initial-permits>1</initial-permits> > </semaphore> > > Thanks > > > On 5 June 2017 at 21:07, Nikolai Tikhonov <[email protected]> wrote: > >> Hi Anil, >> >> You missed a template for caches (lines 90-97). >> >> On Sat, May 13, 2017 at 12:05 PM, Anil <[email protected]> wrote: >> >>> Hi Andrey, >>> >>> Could you please help me here? Thanks. >>> >>> Thanks >>> >>> On 11 May 2017 at 14:16, Anil <[email protected]> wrote: >>> >>>> Hi Andrey, >>>> >>>> I am checking the default-ignite.xml at https://github.com/apacheig >>>> nite/vertx-ignite/blob/master/src/main/resources/default-ignite.xml >>>> >>>> Could you please point what is missing in my configuration ? >>>> >>>> I could not find anything in default-ignite.xml. >>>> >>>> Thanks >>>> >>>> On 11 May 2017 at 11:07, Anil <[email protected]> wrote: >>>> >>>>> HI Andrey, >>>>> >>>>> i am using vertx-ignite 3.4.1 and ignite 1.9 version. i will check the >>>>> default-ignite.xml. >>>>> >>>>> Thanks >>>>> >>>>> On 10 May 2017 at 21:31, Andrey Gura <[email protected]> wrote: >>>>> >>>>>> Anil, >>>>>> >>>>>> What version of vertx-ignite or Ignite itself do you use? >>>>>> >>>>>> In provided ignite.xml there is no minimal configuration that is >>>>>> mandatory for Ignite cluster manager for vert.x (see >>>>>> default-ignite.xml for example). >>>>>> >>>>>> >>>>>> On Tue, May 2, 2017 at 9:18 AM, Anil <[email protected]> wrote: >>>>>> > >>>>>> > Hi Andrey, >>>>>> > >>>>>> > Apologies for late reply. I don't have any exact reproduce. I can >>>>>> see this >>>>>> > log frequently in our logs. >>>>>> > >>>>>> > attached the ignite.xml. >>>>>> > >>>>>> > Thanks. >>>>>> > >>>>>> > >>>>>> > >>>>>> > On 26 April 2017 at 18:32, Andrey Gura <[email protected]> wrote: >>>>>> >> >>>>>> >> Anil, >>>>>> >> >>>>>> >> what kind of lock do you mean? What are steps for reproduce? What >>>>>> >> version if vert-ignite do use and what is your configuration? >>>>>> >> >>>>>> >> On Wed, Apr 26, 2017 at 2:16 PM, Anil <[email protected]> wrote: >>>>>> >> > HI, >>>>>> >> > >>>>>> >> > I am using vertx-ignite and when node is left the topology, lock >>>>>> is not >>>>>> >> > getting released and whole server is not responding. >>>>>> >> > >>>>>> >> > 2017-04-26 04:09:15 WARN vertx-blocked-thread-checker >>>>>> >> > BlockedThreadChecker:57 - Thread >>>>>> >> > Thread[vert.x-worker-thread-82,5,ignite] >>>>>> >> > has been blocked for 2329981 ms, time limit is 60000 >>>>>> >> > io.vertx.core.VertxException: Thread blocked >>>>>> >> > at sun.misc.Unsafe.park(Native Method) >>>>>> >> > at >>>>>> >> > java.util.concurrent.locks.LockSupport.park(LockSupport.java >>>>>> :175) >>>>>> >> > at >>>>>> >> > >>>>>> >> > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAn >>>>>> dCheckInterrupt(AbstractQueuedSynchronizer.java:836) >>>>>> >> > at >>>>>> >> > >>>>>> >> > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcqu >>>>>> ireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >>>>>> >> > at >>>>>> >> > >>>>>> >> > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquir >>>>>> eSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >>>>>> >> > at >>>>>> >> > >>>>>> >> > org.apache.ignite.internal.util.future.GridFutureAdapter.get >>>>>> 0(GridFutureAdapter.java:161) >>>>>> >> > at >>>>>> >> > >>>>>> >> > org.apache.ignite.internal.util.future.GridFutureAdapter.get >>>>>> (GridFutureAdapter.java:119) >>>>>> >> > at >>>>>> >> > >>>>>> >> > org.apache.ignite.internal.processors.cache.distributed.dht. >>>>>> atomic.GridDhtAtomicCache.get0(GridDhtAtomicCache.java:488) >>>>>> >> > at >>>>>> >> > >>>>>> >> > org.apache.ignite.internal.processors.cache.GridCacheAdapter >>>>>> .get(GridCacheAdapter.java:4663) >>>>>> >> > at >>>>>> >> > >>>>>> >> > org.apache.ignite.internal.processors.cache.GridCacheAdapter >>>>>> .get(GridCacheAdapter.java:1388) >>>>>> >> > at >>>>>> >> > >>>>>> >> > org.apache.ignite.internal.processors.cache.IgniteCacheProxy >>>>>> .get(IgniteCacheProxy.java:1117) >>>>>> >> > at io.vertx.spi.cluster.ignite.im >>>>>> pl.MapImpl.get(MapImpl.java:81) >>>>>> >> > at >>>>>> >> > io.vertx.core.impl.HAManager.chooseHashedNode(HAManager.java >>>>>> :590) >>>>>> >> > at io.vertx.core.impl.HAManager.c >>>>>> heckSubs(HAManager.java:519) >>>>>> >> > at io.vertx.core.impl.HAManager.n >>>>>> odeLeft(HAManager.java:305) >>>>>> >> > at io.vertx.core.impl.HAManager.a >>>>>> ccess$100(HAManager.java:107) >>>>>> >> > at io.vertx.core.impl.HAManager$1 >>>>>> .nodeLeft(HAManager.java:157) >>>>>> >> > at >>>>>> >> > >>>>>> >> > io.vertx.spi.cluster.ignite.IgniteClusterManager.lambda$null >>>>>> $4(IgniteClusterManager.java:254) >>>>>> >> > at >>>>>> >> > >>>>>> >> > io.vertx.spi.cluster.ignite.IgniteClusterManager$$Lambda$36/ >>>>>> 837728834.handle(Unknown >>>>>> >> > Source) >>>>>> >> > at >>>>>> >> > >>>>>> >> > io.vertx.core.impl.ContextImpl.lambda$executeBlocking$1(Cont >>>>>> extImpl.java:271) >>>>>> >> > at >>>>>> >> > io.vertx.core.impl.ContextImpl$$Lambda$13/116289363.run(Unknown >>>>>> >> > Source) >>>>>> >> > at io.vertx.core.impl.TaskQueue.l >>>>>> ambda$new$0(TaskQueue.java:60) >>>>>> >> > at io.vertx.core.impl.TaskQueue$$ >>>>>> Lambda$12/443290224.run(Unknown >>>>>> >> > Source) >>>>>> >> > at >>>>>> >> > >>>>>> >> > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool >>>>>> Executor.java:1142) >>>>>> >> > at >>>>>> >> > >>>>>> >> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo >>>>>> lExecutor.java:617) >>>>>> >> > at java.lang.Thread.run(Thread.java:745) >>>>>> >> > >>>>>> >> > was it a known issue ? >>>>>> >> > >>>>>> >> > Thanks >>>>>> > >>>>>> > >>>>>> >>>>> >>>>> >>>> >>> >> >
