RE: Re:

2020-06-30 Thread BEELA GAYATRI 

Hi Kasnacheev,

   The below behavior is occurring randomly after stopping the node. Do we have 
any resolution apart from deleting metastorage folder?


Sent from Mail for Windows 10

From: Ilya Kasnacheev
Sent: Thursday, June 25, 2020 8:16 PM
To: user@ignite.apache.org
Subject: Re:

"External email. Open with Caution"
Hello!

This looks like a known issue: 
https://issues.apache.org/jira/browse/IGNITE-12850

Do you have a reproducer for this behavior?

Regards,
--
Ilya Kasnacheev


пн, 15 июн. 2020 г. в 10:49, BEELA GAYATRI 
mailto:beela.gaya...@tcs.com>>:

Hi Team,

I am running 3 server nodes  by setting baseline topology for all the 3 servers 
 with persistence enabled

I have stopped one of the nodes and again started the node. I am getting below 
error  so I have remove metastorage folder in the persistence storage path for 
that node. Now the node is up and running perfectly.

Please clarify ,what could be the reason behind the error and why the node is 
up and rrunning after removing the metastorage folder in persistence path of 
the node?

Exception during start processors, node will be stopped and close connections
class org.apache.ignite.IgniteCheckedException: Restoring of BaselineTopology 
history has failed, expected history item not found for id=3
at 
org.apache.ignite.internal.processors.cluster.BaselineTopologyHistory.restoreHistory(BaselineTopologyHistory.java:54)
at 
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onReadyForRead(GridClusterStateProcessor.java:223)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:396)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:662)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:4610)
at 
org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1048)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
at 
org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
at 
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1076)
at 
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:962)
at 
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:861)
at 
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:731)
at 
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:700)
at org.apache.ignite.Ignition.start(Ignition.java:348


Sent from Mail for Windows 10


=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

Re: Setting Cache Size using Max Records

2020-06-30 Thread Victor 
Yes, user upfront defines a config and the idea indeed is to convert the
number of records to total bytes. 

Followup around this. Given i want to calculate the exact row entry size
upfront, even before the data is added. Couple of queries,

1. Is there a way(api) just based on the Cache (table), be able to inspect
the capacity a row can hold based on the column datatypes?
2. Can the Dataregion be set post the cache is created?

Thanks,
Victor



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

Re: Question on Key choice for an Ignite cache

2020-06-30 Thread Denis Magda 
He Eugene,

To elaborate on Ilya's answer, you can define a POJO for your key like as
follows:

public class AccountKey {
String email;
String phoneNumber;

//don't forget to implement equals() and hashCode() so
// that Ignite partitions and locates your records properly
}

and then use the objects of that type in your cache.get/put requests.

-
Denis


On Tue, Jun 30, 2020 at 1:04 PM Eugene McGowan 
wrote:

>
> On Tue 30 Jun 2020, 13:51 Ilya Kasnacheev, 
> wrote:
>
>> Hello!
>>
>> You can also use Binary Object (POJO) as a key, i.e., you can use an
>> Object with String email and String phone fields.
>>
>> I don't recommend mangling strings further than concatenation. String key
>> is no worse than numeric key.
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> вт, 30 июн. 2020 г. в 15:17, Eugene McGowan :
>>
>>>
>>> We would like to create an Ignite key by concatenating data. This is a
>>> standard distributed system pattern for key-value, and would allow the
>>> reader and writer consistently access the cache.  The data is a combination
>>> of strings and integers. To simplify our use case, lets say its an email
>>> address (f...@bar.com) and phone number (123444) we want to use to build
>>> our key.Our key could therefore be:foo@bar.com_123444
>>> The advantage of this approach is the key can
>>> easily be read/debugged. Is there a more optimum format for Ignite though?
>>> For regular RDBMS, it seems integers were the default choice. We could
>>> convert f...@bar.com to an int, e.g. f converts to 6, o to 15, etc.
>>> This naïve first attempt of conversion would of-course lead to clashes,
>>> as 111 could map to either aaa or ak. This could be worked around
>>> potentially, so looking for an initial steer on what Ignite would prefer as
>>> a key (i.e. strings or ints). Is hashing something that would be
>>> recommended either? In terms of any partitioning type logic, we are
>>> guessing not, but just more around creating deterministic, unique keys
>>>
>>

Re: Question on Key choice for an Ignite cache

2020-06-30 Thread Eugene McGowan 
On Tue 30 Jun 2020, 13:51 Ilya Kasnacheev, 
wrote:

> Hello!
>
> You can also use Binary Object (POJO) as a key, i.e., you can use an
> Object with String email and String phone fields.
>
> I don't recommend mangling strings further than concatenation. String key
> is no worse than numeric key.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> вт, 30 июн. 2020 г. в 15:17, Eugene McGowan :
>
>>
>> We would like to create an Ignite key by concatenating data. This is a
>> standard distributed system pattern for key-value, and would allow the
>> reader and writer consistently access the cache.  The data is a combination
>> of strings and integers. To simplify our use case, lets say its an email
>> address (f...@bar.com) and phone number (123444) we want to use to build
>> our key.Our key could therefore be:foo@bar.com_123444
>> The advantage of this approach is the key can easily
>> be read/debugged. Is there a more optimum format for Ignite though? For
>> regular RDBMS, it seems integers were the default choice. We could convert
>> f...@bar.com to an int, e.g. f converts to 6, o to 15, etc.
>> This naïve first attempt of conversion would of-course lead to clashes,
>> as 111 could map to either aaa or ak. This could be worked around
>> potentially, so looking for an initial steer on what Ignite would prefer as
>> a key (i.e. strings or ints). Is hashing something that would be
>> recommended either? In terms of any partitioning type logic, we are
>> guessing not, but just more around creating deterministic, unique keys
>>
>

Re: Blocked system-critical thread has been detected - After upgrade to 2.8.1

2020-06-30 Thread akorensh 
Hi,
   Looks like the system is being slowed down for some reason.
   Many Ignite operations are taking a long time(>30 sec) where they should
complete much quicker.

   Are you able to go back to 2.7.6 on the exact same config/setup, run the
system for
   a period of time then go to 2.8.1 and reproduce these issues? 

   Are you using persistent store? If so, can you clean it and retry?
   Try disabling persistence to see if that helps, and if it does then we
need to diagnose
   why it is causing these issues.

   Describe your topology? How many clients/servers/thin clients etc.

   Can you simplify your topology to one server (and possibly one client)
and retry to see where 
   the bottleneck is?  Also try lessening the load on the system to the
minimum possible to see whether
   these problems are throughput/load dependent.

   If you are unable to resolve this, but it is reproducible then describe
steps/include a small 
  reproducer and logs(including GC logs) from all nodes.
https://apacheignite.readme.io/docs/jvm-and-system-tuning#detailed-garbage-collection-stats
Thanks, Alex





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

Blocked system-critical thread has been detected - After upgrade to 2.8.1

2020-06-30 Thread Manu 
Hi!

We have been working with Ignite 2.7.6 without incidents, since we upgrade
to 2.8.1 (same machine, same resources) we are getting "Blocked
system-critical thread", Ignite server nodes stops responding. 

We have been notice that after several hours (about 8 or 9), it recovers
itself, but after some queries, countdown latches, queues and topics
creation stops working again.

We are tried to modify number of threads, timeouts without success.

Any idea?

Thanks!!

logs-from-ignite-server-data-in-ignite-server-data-0-7.txt

  



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

Re: How to do address resolution?

2020-06-30 Thread John Smith 
Ok so. Is this expected behaviour? From user perspective this seems like a
bug.

Visor is supposed to be used as a way to monitor...

So if as a user we enter a command and it just freezes indefinently it just
seems unfriendly.

In another thread the the team mentioned that they are working on something
that does not require the protocol to communicate back to a thick client.
So wondering if this is in a way related as well...

On Tue., Jun. 30, 2020, 6:58 a.m. Ilya Kasnacheev, <
ilya.kasnach...@gmail.com> wrote:

> Hello!
>
> I can see the following in the thread dump:
> "main" #1 prio=5 os_prio=0 tid=0x7f02c400d800 nid=0x1e43 runnable
> [0x7f02cad1e000]
>java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.Net.poll(Native Method)
> at sun.nio.ch.SocketChannelImpl.poll(SocketChannelImpl.java:951)
> - locked <0xec066048> (a java.lang.Object)
> at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:121)
> - locked <0xec066038> (a java.lang.Object)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3299)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2987)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2870)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2713)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2672)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1656)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1731)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1436)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:666)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:538)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:764)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:392)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync0(IgniteComputeImpl.java:528)
> at
> org.apache.ignite.internal.IgniteComputeImpl.execute(IgniteComputeImpl.java:498)
> at org.apache.ignite.visor.visor$.execute(visor.scala:1800)
>
> It seems that Visor is trying to connect to client node via Communication,
> and it fails because the network connection is filtered out.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пн, 29 июн. 2020 г. в 23:47, John Smith :
>
>> Ok.
>>
>> I am able to reproduce the "issue" unless we have a misunderstanding and
>> we are talking about the same thing...
>>
>> My thick client runs inside a container in a closed network NOT bridged
>> and NOT host. I added a flag to my application that allows it to add the
>> address resolver to the config.
>>
>> 1- If I disable address resolution and I connect with visor to the
>> cluster and try to print detailed statistics for that particular client,
>> visor freezes indefinitely at the Data Region Snapshot.
>> Control C doesn't kill the visor either. It just stuck. This also happens
>> when running the cache command. Just freezes indefinitely.
>>
>> I attached the jstack output to the email but it is also here:
>> https://www.dropbox.com/s/wujcee1gd87gk6o/jstack.out?dl=0
>>
>> 2- If I enable address resolution for the thick client then all the
>> commands work ok. I also see an "Accepted incoming communication
>> connection" log in the client.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Mon, 29 Jun 2020 at 15:30, Ilya Kasnacheev 
>> wrote:
>>
>>> Hello!
>>>
>>> The easiest way is jstack 
>>>
>>> Regards,
>>> --
>>> Ilya Kasnacheev
>>>
>>>
>>> пн, 29 июн. 2020 г. в 20:20, John Smith :
>>>
 How?

 On Mon, 29 Jun 2020 at 12:03, Ilya Kasnacheev <
 ilya.kasnach...@gmail.com> wrote:

> Hello!
>
> Try collecting thread dump from Visor as it freezes.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пн, 29 июн. 2020 г. в 18:11, John Smith :
>
>> How though?
>>
>> 1- Entered node command
>> 2- Got list of nodes, including thick clients
>> 3- Selected thick client
>> 4- Entered Y for detailed statistics
>> 5- Snapshot details displayed
>> 6- Data region stats frozen
>>
>> I think the address resolution is working for this as well. I need to
>> confirm. Because I fixed the resolver as per your solution and visor no
>> longer freezes on #6 above.
>>
>> On Mon, 29 Jun 2020 at 10:54, Ilya Kasnacheev <
>> ilya.kasnach...@gmail.com> wrote:
>>
>>> Hello!
>>>
>>> This usually means there's no connectivity between node

Re: Question on Key choice for an Ignite cache

2020-06-30 Thread Ilya Kasnacheev 
Hello!

You can also use Binary Object (POJO) as a key, i.e., you can use an Object
with String email and String phone fields.

I don't recommend mangling strings further than concatenation. String key
is no worse than numeric key.

Regards,
-- 
Ilya Kasnacheev


вт, 30 июн. 2020 г. в 15:17, Eugene McGowan :

>
> We would like to create an Ignite key by concatenating data. This is a
> standard distributed system pattern for key-value, and would allow the
> reader and writer consistently access the cache.  The data is a combination
> of strings and integers. To simplify our use case, lets say its an email
> address (f...@bar.com) and phone number (123444) we want to use to build
> our key.Our key could therefore be:foo@bar.com_123444 The
> advantage of this approach is the key can easily be read/debugged. Is there
> a more optimum format for Ignite though? For regular RDBMS, it seems
> integers were the default choice. We could convert f...@bar.com to an int,
> e.g. f converts to 6, o to 15, etc.
> This naïve first attempt of conversion would of-course lead to clashes, as
> 111 could map to either aaa or ak. This could be worked around potentially,
> so looking for an initial steer on what Ignite would prefer as a key (i.e.
> strings or ints). Is hashing something that would be recommended either? In
> terms of any partitioning type logic, we are guessing not, but just more
> around creating deterministic, unique keys
>

Question on Key choice for an Ignite cache

2020-06-30 Thread Eugene McGowan 
We would like to create an Ignite key by concatenating data. This is a
standard distributed system pattern for key-value, and would allow the
reader and writer consistently access the cache.  The data is a combination
of strings and integers. To simplify our use case, lets say its an email
address (f...@bar.com) and phone number (123444) we want to use to build our
key.Our key could therefore be:foo@bar.com_123444 The
advantage of this approach is the key can easily be read/debugged. Is there
a more optimum format for Ignite though? For regular RDBMS, it seems
integers were the default choice. We could convert f...@bar.com to an int,
e.g. f converts to 6, o to 15, etc.
This naïve first attempt of conversion would of-course lead to clashes, as
111 could map to either aaa or ak. This could be worked around potentially,
so looking for an initial steer on what Ignite would prefer as a key (i.e.
strings or ints). Is hashing something that would be recommended either? In
terms of any partitioning type logic, we are guessing not, but just more
around creating deterministic, unique keys

Re: How to do address resolution?

2020-06-30 Thread Ilya Kasnacheev 
Hello!

I can see the following in the thread dump:
"main" #1 prio=5 os_prio=0 tid=0x7f02c400d800 nid=0x1e43 runnable
[0x7f02cad1e000]
   java.lang.Thread.State: RUNNABLE
at sun.nio.ch.Net.poll(Native Method)
at sun.nio.ch.SocketChannelImpl.poll(SocketChannelImpl.java:951)
- locked <0xec066048> (a java.lang.Object)
at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:121)
- locked <0xec066038> (a java.lang.Object)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3299)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2987)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2870)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2713)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2672)
at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1656)
at
org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1731)
at
org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1436)
at
org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:666)
at
org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:538)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:764)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:392)
at
org.apache.ignite.internal.IgniteComputeImpl.executeAsync0(IgniteComputeImpl.java:528)
at
org.apache.ignite.internal.IgniteComputeImpl.execute(IgniteComputeImpl.java:498)
at org.apache.ignite.visor.visor$.execute(visor.scala:1800)

It seems that Visor is trying to connect to client node via Communication,
and it fails because the network connection is filtered out.

Regards,
-- 
Ilya Kasnacheev


пн, 29 июн. 2020 г. в 23:47, John Smith :

> Ok.
>
> I am able to reproduce the "issue" unless we have a misunderstanding and
> we are talking about the same thing...
>
> My thick client runs inside a container in a closed network NOT bridged
> and NOT host. I added a flag to my application that allows it to add the
> address resolver to the config.
>
> 1- If I disable address resolution and I connect with visor to the cluster
> and try to print detailed statistics for that particular client, visor
> freezes indefinitely at the Data Region Snapshot.
> Control C doesn't kill the visor either. It just stuck. This also happens
> when running the cache command. Just freezes indefinitely.
>
> I attached the jstack output to the email but it is also here:
> https://www.dropbox.com/s/wujcee1gd87gk6o/jstack.out?dl=0
>
> 2- If I enable address resolution for the thick client then all the
> commands work ok. I also see an "Accepted incoming communication
> connection" log in the client.
>
>
>
>
>
>
>
>
>
> On Mon, 29 Jun 2020 at 15:30, Ilya Kasnacheev 
> wrote:
>
>> Hello!
>>
>> The easiest way is jstack 
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> пн, 29 июн. 2020 г. в 20:20, John Smith :
>>
>>> How?
>>>
>>> On Mon, 29 Jun 2020 at 12:03, Ilya Kasnacheev 
>>> wrote:
>>>
 Hello!

 Try collecting thread dump from Visor as it freezes.

 Regards,
 --
 Ilya Kasnacheev


 пн, 29 июн. 2020 г. в 18:11, John Smith :

> How though?
>
> 1- Entered node command
> 2- Got list of nodes, including thick clients
> 3- Selected thick client
> 4- Entered Y for detailed statistics
> 5- Snapshot details displayed
> 6- Data region stats frozen
>
> I think the address resolution is working for this as well. I need to
> confirm. Because I fixed the resolver as per your solution and visor no
> longer freezes on #6 above.
>
> On Mon, 29 Jun 2020 at 10:54, Ilya Kasnacheev <
> ilya.kasnach...@gmail.com> wrote:
>
>> Hello!
>>
>> This usually means there's no connectivity between node and Visor.
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> пн, 29 июн. 2020 г. в 17:01, John Smith :
>>
>>> Also I think for Visor as well?
>>>
>>> When I do top or node commands, I can see the thick client. But when
>>> I look at detailed statistics for that particular thick client it 
>>> freezes
>>> "indefinitely". Regular statistics it seems ok.
>>>
>>> On Mon, 29 Jun 2020 at 08:08, Ilya Kasnacheev <
>>> ilya.kasnach...@gmail.com> wrote:
>>>
 Hello!

 For thick clients, you need both 47100 and 47500, both directions
 (perhaps for 47500 only client -> server is sufficient, but for 47100, 
 both

Re: Ignite Configuration file modify

2020-06-30 Thread Ilya Kasnacheev 
Hello!

You can implement this yourself if you really need it.

Such as, you can watch an XML file, when it changes, do
Ignition.loadSpringBin(file, bean name), and then call
ignite.getOrCreateCache() on all cache configurations found in that bean.

Regards.
-- 
Ilya Kasnacheev


вт, 30 июн. 2020 г. в 12:15, kay :

> Hello :)
>
> Because If I add cache by code, the cache disappears when the node is
> restarted
> so I want to modify the configuration file directly.
>
> Thank you!
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: Ignite Configuration file modify

2020-06-30 Thread Mikael 
Ok, well modifying the configuration might not be a good solution, what 
if you have multiple nodes and the configurations files no longer match, 
I guess you could create a service that runs on all nodes and have that 
updating the XML configuration files when you add caches, there is no 
need to "reload" the configuration while Ignite is running as you create 
the caches manually from code AND update the XML configuration, and on a 
restart the caches will be in the modified configuration.


Any chance you could enable persistence on the system cache ? that would 
keep your created caches on restart.


The reason you cannot reload configuration while running is that many 
settings cannot be changed on a running instance, page size, off heap 
memory region sizes and so on.


Den 2020-06-30 kl. 11:15, skrev kay:

Hello :)

Because If I add cache by code, the cache disappears when the node is
restarted
so I want to modify the configuration file directly.

Thank you!



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

Re: Ignite Configuration file modify

2020-06-30 Thread kay 
Hello :)

Because If I add cache by code, the cache disappears when the node is
restarted 
so I want to modify the configuration file directly.

Thank you!



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

Re: Ignite Configuration file modify

2020-06-30 Thread Mikael 

Hi!

No, you need to restart Ignite if you change xml configuration as far as 
I know.


But you can add caches after Ignite is started without any problems, 
both from code and from SQL, is there any reason you cannot use one of 
these methods ?



Den 2020-06-30 kl. 10:47, skrev kay:

Hello,
Is there a way to modify the configuration file after Ignite Node starts?
Should I use FTP directly to create a page to modify configuration file?

I know I can add cache in ignite run time but after restart, There is not
exist cache add in runtime.
So I need to find a way modify configuration file..

Thank you so much





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

Ignite Configuration file modify

2020-06-30 Thread kay 
Hello, 
Is there a way to modify the configuration file after Ignite Node starts?
Should I use FTP directly to create a page to modify configuration file?

I know I can add cache in ignite run time but after restart, There is not
exist cache add in runtime.
So I need to find a way modify configuration file..

Thank you so much





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