IgniteSpringBean & Ignite SpringTransactionManager broken with 2.4?

[mlekshma]

Hi,

I see that with a change introduced in 2.4 in IgniteSpringBean to delay
ignite instance start until all other spring beans are initialized may have
broken Ignite  SpringTransactionManager

  
resulting in inability to configure it for Spring transaction abstraction of
Ignite transactions. I really, badly need to find a way to work around this.
Any ideas/suggestions anyone?

Below is the line from  IgniteSpringBean

  
java doc
/*"Ignite instance is started after all other Spring beans have been
initialized and right before Spring context is refreshed. That implies that
it's not valid to reference IgniteSpringBean from any kind of Spring bean
init methods like PostConstruct. If it's required to reference
IgniteSpringBean for other bean initialization purposes, it should be done
from a ContextRefreshedEvent listener method declared in that bean. "
*/

The problem is since SpringTransactionManager implements
org.springframework.beans.factory.InitializingBean & in the
afterPropertiesSet() call that spring calls it tries to look for the
igniteInstanceName that's specified but since the instance is started only
AFTER all other Spring beans have been initialized, it fails with
IgniteIllegalStateException,

Please see below stack trace,

lass]: Invocation of init method failed; nested exception is class
org.apache.ignite.IgniteIllegalStateException: Ignite instance with provided
name doesn't exist. Did you call Ignition.start(..) to start an Ignite
instance? [name=ObjectManagerGrid]
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1628)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:555)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:483)
at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
at
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:761)
at
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:866)
at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:542)
at
org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.refresh(EmbeddedWebApplicationContext.java:122)
at
org.springframework.boot.SpringApplication.refresh(SpringApplication.java:737)
at
org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:370)
at
org.springframework.boot.SpringApplication.run(SpringApplication.java:314)
at com.brocade.dcm.Application.main(Application.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:48)
at org.springframework.boot.loader.Launcher.launch(Launcher.java:87)
at org.springframework.boot.loader.Launcher.launch(Launcher.java:50)
at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:51)
*Caused by: org.apache.ignite.IgniteIllegalStateException: Ignite instance
with provided name doesn't exist. Did you call Ignition.start(..) to start
an Ignite instance? [name=ObjectManagerGrid]
at org.apache.ignite.internal.IgnitionEx.grid(IgnitionEx.java:1376)
at org.apache.ignite.Ignition.ignite(Ignition.java:530)
at
org.apache.ignite.transactions.spring.SpringTransactionManager.afterPropertiesSet(SpringTransactionManager.java:357)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1687)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1624)*
... 22 common frames omitted

Thanks



--
Sent from: http://apache-ignite-users.705

Re: Ignite Spring Integration seems broken with 2.4 (upgrading from 2.3)

[Muthu]

UPDATE :

Moving to an @Bean method did not work aswell, getting below exception on
startup. Looks like there is no way to configure SpringTransactionManager
with IgniteSpringBean starting with 2.4...not sure how i can proceed with
the upgrade..any idea anyone?


lass]: Invocation of init method failed; nested exception is class
org.apache.ignite.IgniteIllegalStateException: Ignite instance with
provided name doesn't exist. Did you call Ignition.start(..) to start an
Ignite instance? [name=ObjectManagerGrid]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac
tory.initializeBean(AbstractAutowireCapableBeanFactory.java:1628)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac
tory.doCreateBean(AbstractAutowireCapableBeanFactory.java:555)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac
tory.createBean(AbstractAutowireCapableBeanFactory.java:483)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.
getObject(AbstractBeanFactory.java:306)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.
getSingleton(DefaultSingletonBeanRegistry.java:230)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(
AbstractBeanFactory.java:302)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(
AbstractBeanFactory.java:197)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.
preInstantiateSingletons(DefaultListableBeanFactory.java:761)
at org.springframework.context.support.AbstractApplicationContext.
finishBeanFactoryInitialization(AbstractApplicationContext.java:866)
at org.springframework.context.support.AbstractApplicationContext.refresh(
AbstractApplicationContext.java:542)
at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.
refresh(EmbeddedWebApplicationContext.java:122)
at org.springframework.boot.SpringApplication.refresh(
SpringApplication.java:737)
at org.springframework.boot.SpringApplication.refreshContext(
SpringApplication.java:370)
at org.springframework.boot.SpringApplication.run(
SpringApplication.java:314)
at com.brocade.dcm.Application.main(Application.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.springframework.boot.loader.MainMethodRunner.run(
MainMethodRunner.java:48)
at org.springframework.boot.loader.Launcher.launch(Launcher.java:87)
at org.springframework.boot.loader.Launcher.launch(Launcher.java:50)
at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:51)
Caused by: org.apache.ignite.IgniteIllegalStateException: Ignite instance
with provided name doesn't exist. Did you call Ignition.start(..) to start
an Ignite instance? [name=ObjectManagerGrid]
at org.apache.ignite.internal.IgnitionEx.grid(IgnitionEx.java:1376)
at org.apache.ignite.Ignition.ignite(Ignition.java:530)
at org.apache.ignite.transactions.spring.SpringTransactionManager.
afterPropertiesSet(SpringTransactionManager.java:357)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac
tory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1687)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac
tory.initializeBean(AbstractAutowireCapableBeanFactory.java:1624)
... 22 common frames omitted


Regards,
Muthu

-- The real danger with modern technology isn't that machines will begin to
think like people, but that people will begin to think like machines.
-- Faith is to believe what you do not see; the reward of this faith is to
see what you believe.

On Thu, May 24, 2018 at 2:46 PM, mlekshma  wrote:

> UPDATE :
>
> Below is the exception,
>
> ignite-object-manager - [ERROR] 2018-05-24 18:36:45.133 [main]
> org.springframework.boot.SpringApplication - Application startup failed
> org.springframework.beans.factory.BeanCreationException: Error creating
> bean
> with name 'transactionManager' defined in class path resource
> [applicationContext.xml]: Invocation of init method failed; nested
> exception
> is class org.apache.ignite.IgniteIllegalStateException: Ignite instance
> with
> provided name doesn't exist. Did you call Ignition.start(..) to start an
> Ignite instance? [name=ObjectManagerGrid]
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac
> tory.initializeBean(AbstractAutowireCapableBeanFactory.java:1628)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac
> tory.doCreateBean(AbstractAutowireCapableBeanFactory.java:555)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac
> tory.createBean(AbstractAutowireCapableBeanFactory.java:483)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.
> getObject

Re: Ignite web console query

[Denis Magda]

Hi Muthu,

You can log the long-running queries by setting
CacheConfiguration.queryDetailMetricsSize property to a maximum number of
the queries to store.

As for the transactions, starting Ignite 2.5, it will be possible to track
running transactions started from an application.

--
Denis

On Thu, May 24, 2018 at 12:58 PM, Muthu  wrote:

> Hi Dennis,
>
> Is there a way to get & keep logging these long running queries &
> transactions?
>
> Thanks
> Muthu
>
> Regards,
> Muthu
>
> -- The real danger with modern technology isn't that machines will begin
> to think like people, but that people will begin to think like machines.
> -- Faith is to believe what you do not see; the reward of this faith is to
> see what you believe.
>
> On Wed, May 9, 2018 at 8:49 AM, Denis Magda  wrote:
>
>> There won't be an option to disable it (as there is no option to turn off
>> MogoDB right now). The persistence will keep user credentials as well as
>> statistics on long running queries.
>>
>> --
>> Denis
>>
>> On Tue, May 8, 2018 at 10:08 PM, vbm  wrote:
>>
>>> Hi Denis,
>>>
>>> Just curious to know, what will happen if native persistence is disabled.
>>> Will ignite web console work without it ?
>>>
>>>
>>>
>>> Regards,.
>>> Vishwas
>>>
>>>
>>>
>>> --
>>> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>>>
>>
>>
>

Re: Ignite Spring Integration seems broken with 2.4 (upgrading from 2.3)

[mlekshma]

UPDATE : 

Below is the exception,

ignite-object-manager - [ERROR] 2018-05-24 18:36:45.133 [main]
org.springframework.boot.SpringApplication - Application startup failed
org.springframework.beans.factory.BeanCreationException: Error creating bean
with name 'transactionManager' defined in class path resource
[applicationContext.xml]: Invocation of init method failed; nested exception
is class org.apache.ignite.IgniteIllegalStateException: Ignite instance with
provided name doesn't exist. Did you call Ignition.start(..) to start an
Ignite instance? [name=ObjectManagerGrid]
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1628)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:555)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:483)
at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
at
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:761)
at
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:866)
at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:542)
at
org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.refresh(EmbeddedWebApplicationContext.java:122)
at
org.springframework.boot.SpringApplication.refresh(SpringApplication.java:737)
at
org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:370)
at
org.springframework.boot.SpringApplication.run(SpringApplication.java:314)
at com.brocade.dcm.Application.main(Application.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:48)
at org.springframework.boot.loader.Launcher.launch(Launcher.java:87)
at org.springframework.boot.loader.Launcher.launch(Launcher.java:50)
at
org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:51)
Caused by: org.apache.ignite.IgniteIllegalStateException: Ignite instance
with provided name doesn't exist. Did you call Ignition.start(..) to start
an Ignite instance? [name=ObjectManagerGrid]
at org.apache.ignite.internal.IgnitionEx.grid(IgnitionEx.java:1376)
at org.apache.ignite.Ignition.ignite(Ignition.java:530)
at
org.apache.ignite.transactions.spring.SpringTransactionManager.afterPropertiesSet(SpringTransactionManager.java:357)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1687)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1624)
... 22 common frames omitted

Thanks



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

Re: QueryEntity not reflecting ALTER TABLE changes made via DDL

[Ilya Kasnacheev]

Hello!

Unfortunately there's no support in Native SQL API for table introspection.
You could use thin client since it's fairly lighweight.

Regards,

-- 
Ilya Kasnacheev

2018-05-24 23:50 GMT+03:00 Nick Pordash :

> Hi Illya,
>
> Is this possible to get without having to resort to JDBC? For example, the
> Ignite SQL Java Apis?
>
> -Nick
>
>
> On Mon, May 21, 2018, 5:56 AM Ilya Kasnacheev 
> wrote:
>
>> Hello!
>>
>> Cache Configuration would only request its configuration at the time when
>> it was started. It will not be modified when DDL is issued.
>>
>> Yes, you can detect column changes, e.g. by using JDBC Metadata:
>> https://docs.oracle.com/javase/7/docs/api/java/sql/DatabaseMetaData.html
>>
>> Regards,
>>
>> --
>> Ilya Kasnacheev
>>
>> 2018-05-18 20:38 GMT+03:00 Shai N :
>>
>>> I'm trying to detect in Java which fields in a cache are exposed to SQL
>>> by
>>> looking at
>>> "((QueryEntity)ignite.cache("cacheName").getConfiguration(
>>> CacheConfiguration.class).getQueryEntities().iterator().
>>> next()).getFields()".
>>> This accurately reflects a table's initial schema. However, changes made
>>> with "ALTER TABLE ADD COLUMN" and "DROP COLUMN" are not reflected in the
>>> QueryEntity. For example, if I create then alter a table via a SQL client
>>> with:
>>> ---
>>> CREATE TABLE test1 (
>>>   "key"  VARCHAR(30) NOT NULL,
>>>   "id"   BIGINT(20)  NOT NULL,
>>>   "testColumn1" VARCHAR(24) NOT NULL,
>>>   PRIMARY KEY("key"))
>>> WITH "affinitykey=key, backups=1, write_synchronization_mode=FULL_SYNC,
>>> atomicity=transactional, cache_name=test1, value_type=test1,
>>> key_type=arrivals_key";
>>>
>>> ALTER TABLE test1 ADD COLUMN  "testColumn2" VARCHAR(24) NOT NULL;
>>> ---
>>> ... then try to print out the result of
>>> "((QueryEntity)ignite.cache("test1").getConfiguration(
>>> CacheConfiguration.class).getQueryEntities().iterator().
>>> next()).getFields()"
>>> I get "{key=java.lang.String, id=java.lang.Long,
>>> testColumn1=java.lang.String}" which doesn't include the new column.
>>> Dropping columns is likewise not reflected.
>>>
>>> When I do try to query the cache via SQL, the added and dropped columns
>>> are
>>> reflected in the result, so it's clear the change didn't fail to go
>>> through
>>> entirely.
>>>
>>> Is there something I'm missing? Is it possible to alter a table and then
>>> detect the column changes in Java without entirely recreating the cache?
>>>
>>>
>>>
>>> --
>>> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>>>
>>
>>

Re: QueryEntity not reflecting ALTER TABLE changes made via DDL

[Nick Pordash]

Hi Illya,

Is this possible to get without having to resort to JDBC? For example, the
Ignite SQL Java Apis?

-Nick

On Mon, May 21, 2018, 5:56 AM Ilya Kasnacheev 
wrote:

> Hello!
>
> Cache Configuration would only request its configuration at the time when
> it was started. It will not be modified when DDL is issued.
>
> Yes, you can detect column changes, e.g. by using JDBC Metadata:
> https://docs.oracle.com/javase/7/docs/api/java/sql/DatabaseMetaData.html
>
> Regards,
>
> --
> Ilya Kasnacheev
>
> 2018-05-18 20:38 GMT+03:00 Shai N :
>
>> I'm trying to detect in Java which fields in a cache are exposed to SQL by
>> looking at
>>
>> "((QueryEntity)ignite.cache("cacheName").getConfiguration(CacheConfiguration.class).getQueryEntities().iterator().next()).getFields()".
>> This accurately reflects a table's initial schema. However, changes made
>> with "ALTER TABLE ADD COLUMN" and "DROP COLUMN" are not reflected in the
>> QueryEntity. For example, if I create then alter a table via a SQL client
>> with:
>> ---
>> CREATE TABLE test1 (
>>   "key"  VARCHAR(30) NOT NULL,
>>   "id"   BIGINT(20)  NOT NULL,
>>   "testColumn1" VARCHAR(24) NOT NULL,
>>   PRIMARY KEY("key"))
>> WITH "affinitykey=key, backups=1, write_synchronization_mode=FULL_SYNC,
>> atomicity=transactional, cache_name=test1, value_type=test1,
>> key_type=arrivals_key";
>>
>> ALTER TABLE test1 ADD COLUMN  "testColumn2" VARCHAR(24) NOT NULL;
>> ---
>> ... then try to print out the result of
>>
>> "((QueryEntity)ignite.cache("test1").getConfiguration(CacheConfiguration.class).getQueryEntities().iterator().next()).getFields()"
>> I get "{key=java.lang.String, id=java.lang.Long,
>> testColumn1=java.lang.String}" which doesn't include the new column.
>> Dropping columns is likewise not reflected.
>>
>> When I do try to query the cache via SQL, the added and dropped columns
>> are
>> reflected in the result, so it's clear the change didn't fail to go
>> through
>> entirely.
>>
>> Is there something I'm missing? Is it possible to alter a table and then
>> detect the column changes in Java without entirely recreating the cache?
>>
>>
>>
>> --
>> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>>
>
>

Re: Client IgniteStreamer broken after cluster restart

[Nick Pordash]

Thanks, Ilya!

On Tue, May 22, 2018, 10:15 AM Ilya Kasnacheev 
wrote:

> Hello!
>
> What an awesome perdu monocle have you found! I have created a ticket
> against Apache Ignite JIRA:
> https://issues.apache.org/jira/browse/IGNITE-8564
>
> Regards,
>
> --
> Ilya Kasnacheev
>
> 2018-05-18 22:30 GMT+03:00 npordash :
>
>> Sorry about that! Trying again.
>>
>> final BiFunction cfg = (name, client) 
>> -> {
>> final IgniteConfiguration c = new IgniteConfiguration();
>> final TcpDiscoverySpi d = new TcpDiscoverySpi();
>> d.setIpFinder(new TcpDiscoverySharedFsIpFinder());
>> c.setDiscoverySpi(d);
>> c.setIgniteInstanceName(name);
>> c.setClientMode(client);
>> c.setCacheConfiguration(new CacheConfiguration("test"));
>> return c;
>> };
>>
>> Ignite server = null;
>> Ignite client = null;
>> try {
>>
>> server = Ignition.start(cfg.apply("server", false));
>> client = Ignition.start(cfg.apply("client", true));
>>
>> try (IgniteDataStreamer streamer = 
>> client.dataStreamer("test")) {
>> streamer.allowOverwrite(true);
>> streamer.addData("k1", "v1");
>> }
>>
>> TimeUnit.SECONDS.sleep(1);
>> server.close();
>> TimeUnit.SECONDS.sleep(1);
>> server = Ignition.start(cfg.apply("server", false));
>> TimeUnit.SECONDS.sleep(1);
>>
>> try (IgniteDataStreamer streamer = 
>> client.dataStreamer("test")) {
>> streamer.allowOverwrite(true);
>> streamer.addData("k2", "v2");
>> }
>>
>> } finally {
>> if (client != null) {
>> client.close();
>> }
>> if (server != null) {
>> server.close();
>> }
>> }
>>
>>
>> --
>> Sent from the Apache Ignite Users mailing list archive
>>  at Nabble.com.
>>
>
>

Re: Ignite Spring Integration seems broken with 2.4 (upgrading from 2.3)

[Muthu]

 One thing i can do is to move the SpringTransactionManager bean instance
creation into a @Bean method, i am going to test doing this once i get my
machine back...but i wish i didn't have to change anything..


On Thu, May 24, 2018 at 12:54 PM, mlekshma 
wrote:

> We are upgrading from 2.3 to 2.4 & realized that a change made in
> IgniteSpringBean which is referenced in this added line in its javadoc
> resulted in us moving lots of references in PostConstruct to
> handleContextRefresh.
>
> "A note should be taken that Ignite instance is started after all other
> Spring beans have been initialized and right before Spring context is
> refreshed. That implies that it's not valid to reference IgniteSpringBean
> from any kind of Spring bean init methods like PostConstruct. If it's
> required to reference IgniteSpringBean for other bean initialization
> purposes, it should be done from a ContextRefreshedEvent listener method
> declared in that bean."
>
> However this breaks ignite spring transaction configuration configured as
> per the suggestion there which i am not sure how to resolve. Basically we
> have the below in the spring application xml where both IgniteSpringBean &
> SpringTransactionManager are configured which was working in 2.3 but fails
> to start up referencing the above change with 2.4 (i will add the exception
> in a bit as my machine went down suddenly),
>
> 
> 
>  class="org.apache.ignite.configuration.IgniteConfiguration">
> 
> 
> ...
> ...
> 
> 
> 
>
>
>  class="org.apache.ignite.transactions.spring.SpringTransactionManager">
> 
> 
> 
>
>
> 
>
>
> Any clue on how to work around this problem?
>
> Thanks!
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Ignite Spring Integration seems broken with 2.4 (upgrading from 2.3)

[mlekshma]

We are upgrading from 2.3 to 2.4 & realized that a change made in
IgniteSpringBean which is referenced in this added line in its javadoc
resulted in us moving lots of references in PostConstruct to
handleContextRefresh.

"A note should be taken that Ignite instance is started after all other
Spring beans have been initialized and right before Spring context is
refreshed. That implies that it's not valid to reference IgniteSpringBean
from any kind of Spring bean init methods like PostConstruct. If it's
required to reference IgniteSpringBean for other bean initialization
purposes, it should be done from a ContextRefreshedEvent listener method
declared in that bean."

However this breaks ignite spring transaction configuration configured as
per the suggestion there which i am not sure how to resolve. Basically we
have the below in the spring application xml where both IgniteSpringBean &
SpringTransactionManager are configured which was working in 2.3 but fails
to start up referencing the above change with 2.4 (i will add the exception
in a bit as my machine went down suddenly),






...
...














Any clue on how to work around this problem?

Thanks!



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

Re: Ignite web console query

[Muthu]

Hi Dennis,

Is there a way to get & keep logging these long running queries &
transactions?

Thanks
Muthu

Regards,
Muthu

-- The real danger with modern technology isn't that machines will begin to
think like people, but that people will begin to think like machines.
-- Faith is to believe what you do not see; the reward of this faith is to
see what you believe.

On Wed, May 9, 2018 at 8:49 AM, Denis Magda  wrote:

> There won't be an option to disable it (as there is no option to turn off
> MogoDB right now). The persistence will keep user credentials as well as
> statistics on long running queries.
>
> --
> Denis
>
> On Tue, May 8, 2018 at 10:08 PM, vbm  wrote:
>
>> Hi Denis,
>>
>> Just curious to know, what will happen if native persistence is disabled.
>> Will ignite web console work without it ?
>>
>>
>>
>> Regards,.
>> Vishwas
>>
>>
>>
>> --
>> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>>
>
>

Ignite Spring Integration seems broken with 2.4 (upgrading from 2.3)

[mlekshma]

We are upgrading from 2.3 to 2.4 & realized that a change made in
IgniteSpringBean which is referenced in this added line in its javadoc
resulted in us moving lots of references in PostConstruct to
handleContextRefresh.

"A note should be taken that Ignite instance is started after all other
Spring beans have been initialized and right before Spring context is
refreshed. That implies that it's not valid to reference IgniteSpringBean
from any kind of Spring bean init methods like PostConstruct. If it's
required to reference IgniteSpringBean for other bean initialization
purposes, it should be done from a ContextRefreshedEvent listener method
declared in that bean."

However this breaks ignite spring transaction configuration configured as
per the suggestion there which i am not sure how to resolve. Basically we
have the below in the spring application xml where both IgniteSpringBean &
SpringTransactionManager are configured which was working in 2.3 but fails
to start up referencing the above change with 2.4 (i will add the exception
in a bit as my machine went down suddenly),






...
...














Any clue on how to work around this problem?

Thanks!



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

Re: C# client too slow to connect.

[F.D.]

Hi Yakov,

It works perfectly!

Thanks!!!

F.D.


On Thu, May 24, 2018 at 11:17 AM Yakov Zhdanov  wrote:

> Hi, slow node join is possible on windows machines which is related to
> tcp/ip stack differences from linux - windows implementation waits for the
> entire timeout which is 3000ms by defaull and linux returns immediately
> with "connection refuse".
>
> Just narrow the range - 10.200.20.90:47500..47509, try
> configuring the only 47500 port. This should help, since tcp discovery spi
> tries every address when searching for already started nodes.
>
> --Yakov
>
> 2018-05-23 10:11 GMT+03:00 F.D. :
>
>> Hi Pavel,
>>
>> Yes, but thin client cannot perform continuous query. Maybe is there an
>> alternative way to be notified when a cache change?
>>
>> On Tue, May 22, 2018 at 10:04 PM Pavel Tupitsyn 
>> wrote:
>>
>>> Hi,
>>>
>>> Have you tried Thin Client mode?
>>> https://apacheignite-net.readme.io/docs/thin-client
>>>
>>> Pavel
>>>
>>> On Tue, May 22, 2018 at 2:13 PM, F. D.  wrote:
>>>
 Hi Igor,

 it's almost the same. I'm considering startup + connection. I'm using
 Ignite 2.4.  The node excel is only client, and I have only a server node
 on an other machine in my organization, and I cannot see particular
 activity of cpu or network.

 Thanks,
F.D.

 On Tue, May 22, 2018 at 11:00 AM Igor Sapego 
 wrote:

> Hi,
>
> Try using "TcpDiscoveryStaticIpFinder" instead of
> "TcpDiscoveryMulticastIpFinder".
>
> Does it take 1 min for connection only or for start up + connection?
>
> Best Regards,
> Igor
>
> On Tue, May 22, 2018 at 11:45 AM, F. D. 
> wrote:
>
>> Hi,
>>
>> I'm trying to use Ignite to develop an internal system of data
>> contribution. To do this, I'm launching Ignite inside Excel, and I'm 
>> using
>> the C# binding.
>>
>> When try to connect it consumes a lot of time (~1 min.),  this is my
>> simple app.config:
>>
>> 
>> 
>>
>>   > type="Apache.Ignite.Core.IgniteConfigurationSection, 
>> Apache.Ignite.Core"/>
>>
>>
>>
>>
>>
>>
>>http://ignite.apache.org/schema/dotnet/IgniteConfigurationSection";
>> localhost="10.200.30.100" peerAssemblyLoadingMode="CurrentAppDomain"
>> gridName="IMIStreamer">
>>   
>>  
>>   
>>
>>   
>>
>>   
>>  
>> 
>>10.200.20.90:47500..47509
>> 
>>  
>>   
>>
>>
>>
>>   > sku=".NETFramework,Version=v4.5.2"/>
>>
>>
>> 
>>
>> Is it possibile to reduce this time of connection?
>> I've tried to use the thin client, but in this client there's no
>> continuous query (and need it, because I want to be reactive when a cache
>> change).
>>
>> Thanks in advance for your help,
>>F.D.
>>
>>
>
>>>
>

Re: Re: Nodes can not join the cluster after reboot

[arunkjn]

Hi Evgenii,

I am experiencing the same issue with grid affinity topology.

We have a topology where we have 3 data nodes, 2 service nodes and several
client nodes in the cluster. The issue occurs randomly sometimes when
deploying the nodes. 

I wanted to know that the suggested solution of setting
-DIGNITE_EXCHANGE_COMPATIBILITY_VER_1=true, does it have to be done on all
the nodes? or just service nodes?

Regards,
Arun




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

Re: C# client too slow to connect.

[Yakov Zhdanov]

Hi, slow node join is possible on windows machines which is related to
tcp/ip stack differences from linux - windows implementation waits for the
entire timeout which is 3000ms by defaull and linux returns immediately
with "connection refuse".

Just narrow the range - 10.200.20.90:47500..47509, try
configuring the only 47500 port. This should help, since tcp discovery spi
tries every address when searching for already started nodes.

--Yakov

2018-05-23 10:11 GMT+03:00 F.D. :

> Hi Pavel,
>
> Yes, but thin client cannot perform continuous query. Maybe is there an
> alternative way to be notified when a cache change?
>
> On Tue, May 22, 2018 at 10:04 PM Pavel Tupitsyn 
> wrote:
>
>> Hi,
>>
>> Have you tried Thin Client mode?
>> https://apacheignite-net.readme.io/docs/thin-client
>>
>> Pavel
>>
>> On Tue, May 22, 2018 at 2:13 PM, F. D.  wrote:
>>
>>> Hi Igor,
>>>
>>> it's almost the same. I'm considering startup + connection. I'm using
>>> Ignite 2.4.  The node excel is only client, and I have only a server node
>>> on an other machine in my organization, and I cannot see particular
>>> activity of cpu or network.
>>>
>>> Thanks,
>>>F.D.
>>>
>>> On Tue, May 22, 2018 at 11:00 AM Igor Sapego  wrote:
>>>
 Hi,

 Try using "TcpDiscoveryStaticIpFinder" instead of
 "TcpDiscoveryMulticastIpFinder".

 Does it take 1 min for connection only or for start up + connection?

 Best Regards,
 Igor

 On Tue, May 22, 2018 at 11:45 AM, F. D. 
 wrote:

> Hi,
>
> I'm trying to use Ignite to develop an internal system of data
> contribution. To do this, I'm launching Ignite inside Excel, and I'm using
> the C# binding.
>
> When try to connect it consumes a lot of time (~1 min.),  this is my
> simple app.config:
>
> 
> 
>
>    type="Apache.Ignite.Core.IgniteConfigurationSection,
> Apache.Ignite.Core"/>
>
>
>
>
>
>
>http://ignite.apache.org/schema/dotnet/
> IgniteConfigurationSection" localhost="10.200.30.100"
> peerAssemblyLoadingMode="CurrentAppDomain" gridName="IMIStreamer">
>   
>  
>   
>
>   
>
>   
>  
> 
>10.200.20.90:47500..47509
> 
>  
>   
>
>
>
>   
>
>
> 
>
> Is it possibile to reduce this time of connection?
> I've tried to use the thin client, but in this client there's no
> continuous query (and need it, because I want to be reactive when a cache
> change).
>
> Thanks in advance for your help,
>F.D.
>
>

>>

Re: Setting DefaultDataRegion to zero size

[Evgenii Zhuravlev]

There is a validation for region size, so, you can't even create region
with the less than 10 mb size. Off-heap can't be disabled at all, it's a
core part of data grid architecture.

Evgenii

2018-05-23 22:13 GMT+03:00 breischl :

> Hi,
>   Thanks for the reply. We have enabled onHeap cache, and I know there's no
> way to explicitly disable off heap storage. But if I set the default
> DataRegion to zero size will that /effectively/ disable off-heap storage
> for
> all of our data? And would doing that cause anything else to fail?
>
> Thanks!
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Ignite benchmarking on K8s cluster

[vbm]

Hi,

We are trying to use yardstick benchmark from gridgain
(https://www.gridgain.com/resources/benchmarks/running-gridgain-benchmarks).
These tests are mainly for a non K8s cluster. (based on the logic used in
script).

Is there any test suite which does benchmark test on K8s cluster.


Regards,
Vishwas



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