from:"Shishkov Ilya"

Re: Unable to join using thick client when authentication is enabled

2021-12-11 Thread Shishkov Ilya

Hi,
The bug has been fixed. The fix will be in version 2.12.

пн, 22 нояб. 2021 г. в 15:26, Shishkov Ilya :

> Hi,
> I created a ticket about this problem:
> https://issues.apache.org/jira/browse/IGNITE-15969
>
> пт, 19 нояб. 2021 г. в 22:46, Shishkov Ilya :
>
>> Hi,
>> I've reproduced it for 2.11. In case of turned on authentication, thick
>> clients won't connect until you enable persistence for them. Because thick
>> clients have no persistence, you can use it like a workaround. Certainly,
>> it looks like a bug.
>>
>> пт, 19 нояб. 2021 г. в 16:42, Ganguly Gundeboina <
>> gangaiah.ya...@gmail.com>:
>>
>>> Hi Stephen,
>>>
>>> Same already tried, but it's giving below error even though we have
>>> enabled persistence.
>>>
>>> #
>>>
>>> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
>>> SYSTEM_CRITICAL_OPERATION_TIMEOUT
>>>
>>> [18:03:39] Message queue limit is set to 0 which may lead to potential
>>> OOMEs when running cache operations in FULL_ASYNC or PRIMARY_SYNC modes due
>>> to message queues growth on sender and receiver sides.
>>>
>>> [18:03:49] Security status [authentication=on, sandbox=off, tls/ssl=off]
>>>
>>> Nov 19, 2021 6:03:50 PM org.apache.ignite.logger.java.JavaLogger error
>>>
>>> SEVERE: Exception during start processors, node will be stopped and
>>> close connections
>>>
>>> class org.apache.ignite.IgniteCheckedException: Authentication can be
>>> enabled only for cluster with enabled persistence. Check the
>>> DataRegionConfiguration
>>>
>>>   at
>>> org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:166)
>>>
>>>   at
>>> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1259)
>>>
>>>   at
>>> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
>>>
>>>   at
>>> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
>>>
>>>   at
>>> org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
>>>
>>>   at
>>> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:668)
>>>
>>>   at
>>> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:590)
>>>
>>>   at org.apache.ignite.Ignition.start(Ignition.java:328)
>>>
>>>   at
>>> com.jio.digitalapi.edif.util.operations.CacheSizes.main(CacheSizes.java:52)
>>>
>>>
>>>
>>> Nov 19, 2021 6:03:50 PM org.apache.ignite.logger.java.JavaLogger error
>>>
>>> SEVERE: Got exception while starting (will rollback startup routine).
>>>
>>> class org.apache.ignite.IgniteCheckedException: Authentication can be
>>> enabled only for cluster with enabled persistence. Check the
>>> DataRegionConfiguration
>>>
>>>   at
>>> org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:166)
>>>
>>>
>>>
>>> 
>>> String[] ipAddrArray = igniteNodeIpAddress.split(",", -1);
>>> System.*setProperty*("java.net.preferIPv4Stack", "true");
>>> IgniteConfiguration cfg = new IgniteConfiguration();
>>> cfg.setPeerClassLoadingEnabled(true);
>>> cfg.setClientMode(true);
>>> cfg.setAuthenticationEnabled(true);
>>> String random = (UUID.*randomUUID*().getMostSignificantBits() + ""
>>> ).toString().replace("-", "");
>>> String igniteFullInstaneName = igniteInstanceName + random;
>>> cfg.setIgniteInstanceName(igniteFullInstaneName);
>>> cfg.setDiscoverySpi((new TcpDiscoverySpi().setJoinTimeout(240)
>>> .setIpFinder((new TcpDiscoveryVmIpFinder()).setAddresses(Arrays.
>>> *asList*(ipAddrArray);
>>> Ignition.*start*(cfg);
>>> ###
>>>
>>>
>>> Regards,
>>> Gangaiah
>>>
>>> On Fri, Nov 19, 2021 at 5:14 PM Stephen Darlington <
>>> stephen.darling...@gridgain.com> wrote:
>>&g

Re: Unable to join using thick client when authentication is enabled

2021-11-22 Thread Shishkov Ilya

Hi,
I created a ticket about this problem:
https://issues.apache.org/jira/browse/IGNITE-15969

пт, 19 нояб. 2021 г. в 22:46, Shishkov Ilya :

> Hi,
> I've reproduced it for 2.11. In case of turned on authentication, thick
> clients won't connect until you enable persistence for them. Because thick
> clients have no persistence, you can use it like a workaround. Certainly,
> it looks like a bug.
>
> пт, 19 нояб. 2021 г. в 16:42, Ganguly Gundeboina  >:
>
>> Hi Stephen,
>>
>> Same already tried, but it's giving below error even though we have
>> enabled persistence.
>>
>> #
>>
>> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
>> SYSTEM_CRITICAL_OPERATION_TIMEOUT
>>
>> [18:03:39] Message queue limit is set to 0 which may lead to potential
>> OOMEs when running cache operations in FULL_ASYNC or PRIMARY_SYNC modes due
>> to message queues growth on sender and receiver sides.
>>
>> [18:03:49] Security status [authentication=on, sandbox=off, tls/ssl=off]
>>
>> Nov 19, 2021 6:03:50 PM org.apache.ignite.logger.java.JavaLogger error
>>
>> SEVERE: Exception during start processors, node will be stopped and close
>> connections
>>
>> class org.apache.ignite.IgniteCheckedException: Authentication can be
>> enabled only for cluster with enabled persistence. Check the
>> DataRegionConfiguration
>>
>>   at
>> org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:166)
>>
>>   at
>> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1259)
>>
>>   at
>> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
>>
>>   at
>> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
>>
>>   at
>> org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
>>
>>   at
>> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:668)
>>
>>   at
>> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:590)
>>
>>   at org.apache.ignite.Ignition.start(Ignition.java:328)
>>
>>   at
>> com.jio.digitalapi.edif.util.operations.CacheSizes.main(CacheSizes.java:52)
>>
>>
>>
>> Nov 19, 2021 6:03:50 PM org.apache.ignite.logger.java.JavaLogger error
>>
>> SEVERE: Got exception while starting (will rollback startup routine).
>>
>> class org.apache.ignite.IgniteCheckedException: Authentication can be
>> enabled only for cluster with enabled persistence. Check the
>> DataRegionConfiguration
>>
>>   at
>> org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:166)
>>
>>
>>
>> 
>> String[] ipAddrArray = igniteNodeIpAddress.split(",", -1);
>> System.*setProperty*("java.net.preferIPv4Stack", "true");
>> IgniteConfiguration cfg = new IgniteConfiguration();
>> cfg.setPeerClassLoadingEnabled(true);
>> cfg.setClientMode(true);
>> cfg.setAuthenticationEnabled(true);
>> String random = (UUID.*randomUUID*().getMostSignificantBits() + ""
>> ).toString().replace("-", "");
>> String igniteFullInstaneName = igniteInstanceName + random;
>> cfg.setIgniteInstanceName(igniteFullInstaneName);
>> cfg.setDiscoverySpi((new TcpDiscoverySpi().setJoinTimeout(240)
>> .setIpFinder((new TcpDiscoveryVmIpFinder()).setAddresses(Arrays.
>> *asList*(ipAddrArray);
>> Ignition.*start*(cfg);
>> ###
>>
>>
>> Regards,
>> Gangaiah
>>
>> On Fri, Nov 19, 2021 at 5:14 PM Stephen Darlington <
>> stephen.darling...@gridgain.com> wrote:
>>
>>> Thick clients don’t need to authenticate, but they do need to have the
>>> same authentication settings as the server nodes, i.e., set
>>> IgniteConfiguration#setAuthenticationEnabled(true).
>>>
>>> On 19 Nov 2021, at 11:28, Ganguly Gundeboina 
>>> wrote:
>>>
>>> Hi Pavel,
>>>
>>> Yes, we have enabled authentication on server nodes only.
>>>
>>> We could provide user credentials for thin clients, so thin clients are
>>> able to connect

Re: Unable to join using thick client when authentication is enabled

2021-11-19 Thread Shishkov Ilya

Hi,
I've reproduced it for 2.11. In case of turned on authentication, thick
clients won't connect until you enable persistence for them. Because thick
clients have no persistence, you can use it like a workaround. Certainly,
it looks like a bug.

пт, 19 нояб. 2021 г. в 16:42, Ganguly Gundeboina :

> Hi Stephen,
>
> Same already tried, but it's giving below error even though we have
> enabled persistence.
>
> #
>
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT
>
> [18:03:39] Message queue limit is set to 0 which may lead to potential
> OOMEs when running cache operations in FULL_ASYNC or PRIMARY_SYNC modes due
> to message queues growth on sender and receiver sides.
>
> [18:03:49] Security status [authentication=on, sandbox=off, tls/ssl=off]
>
> Nov 19, 2021 6:03:50 PM org.apache.ignite.logger.java.JavaLogger error
>
> SEVERE: Exception during start processors, node will be stopped and close
> connections
>
> class org.apache.ignite.IgniteCheckedException: Authentication can be
> enabled only for cluster with enabled persistence. Check the
> DataRegionConfiguration
>
>   at
> org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:166)
>
>   at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1259)
>
>   at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
>
>   at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
>
>   at
> org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
>
>   at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:668)
>
>   at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:590)
>
>   at org.apache.ignite.Ignition.start(Ignition.java:328)
>
>   at
> com.jio.digitalapi.edif.util.operations.CacheSizes.main(CacheSizes.java:52)
>
>
>
> Nov 19, 2021 6:03:50 PM org.apache.ignite.logger.java.JavaLogger error
>
> SEVERE: Got exception while starting (will rollback startup routine).
>
> class org.apache.ignite.IgniteCheckedException: Authentication can be
> enabled only for cluster with enabled persistence. Check the
> DataRegionConfiguration
>
>   at
> org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:166)
>
>
>
> 
> String[] ipAddrArray = igniteNodeIpAddress.split(",", -1);
> System.*setProperty*("java.net.preferIPv4Stack", "true");
> IgniteConfiguration cfg = new IgniteConfiguration();
> cfg.setPeerClassLoadingEnabled(true);
> cfg.setClientMode(true);
> cfg.setAuthenticationEnabled(true);
> String random = (UUID.*randomUUID*().getMostSignificantBits() + ""
> ).toString().replace("-", "");
> String igniteFullInstaneName = igniteInstanceName + random;
> cfg.setIgniteInstanceName(igniteFullInstaneName);
> cfg.setDiscoverySpi((new TcpDiscoverySpi().setJoinTimeout(240)
> .setIpFinder((new TcpDiscoveryVmIpFinder()).setAddresses(Arrays.
> *asList*(ipAddrArray);
> Ignition.*start*(cfg);
> ###
>
>
> Regards,
> Gangaiah
>
> On Fri, Nov 19, 2021 at 5:14 PM Stephen Darlington <
> stephen.darling...@gridgain.com> wrote:
>
>> Thick clients don’t need to authenticate, but they do need to have the
>> same authentication settings as the server nodes, i.e., set
>> IgniteConfiguration#setAuthenticationEnabled(true).
>>
>> On 19 Nov 2021, at 11:28, Ganguly Gundeboina 
>> wrote:
>>
>> Hi Pavel,
>>
>> Yes, we have enabled authentication on server nodes only.
>>
>> We could provide user credentials for thin clients, so thin clients are
>> able to connect to the cluster after setting username and password at
>> client side.
>>
>> But not able to set user credentials for thik clients, So we have to
>> disable authentication on server nodes, otherwise thick clients are not
>> able to connect.
>>
>> Regards,
>> Gangaiah
>>
>> On Fri, Nov 19, 2021 at 1:06 PM Pavel Tupitsyn 
>> wrote:
>>
>>> Hi Gangaiah,
>>>
>>> Before 2.11, there was no requirement to have an equal security
>>> processor on all nodes.
>>> It was added as part of [1].
>>>
>>> Overall, I think it is a good idea to have security on all nodes
>>> configured in the same way.
>>> Do you have it enabled only on server nodes?
>>>
>>> [1] https://issues.apache.org/jira/browse/IGNITE-14335
>>>
>>> On Fri, Nov 19, 2021 at 9:42 AM Ganguly Gundeboina <
>>> gangaiah.ya...@gmail.com> wrote:
>>>

 Hi Andrei,

 Thanks for your reply, here is the full log.

 "C:\Program Files\Java\jdk1.8.0_241\bin\java.exe" 
 -Dvisualvm.id=14727407530300
 -DMIGRATION_CONFIG_PATH=C:\Users\scott\AzureRepos\Ig

Re: 'Security context isn't certain' exception during service deploy at node startup in 2.11.0

2021-11-18 Thread Shishkov Ilya

Hi Sergey,
As I see, with turned on authentication, Services require cluster to be
activated before deployment. With excluding servicesConfiguration from
IgniteConfiguration and below lines your example would start:

Ignite ignite = Ignition.start(config);
ignite.cluster().state(ClusterState.ACTIVE);

ignite.services().deploy(serviceConfiguration);

чт, 18 нояб. 2021 г. в 07:39, Sergey Korotkov :

> Hello,
>
> We run into the problem migrating from Ignite version 2.8.1 to 2.11.0
>
> If the authentication is enabled the ignite service which is deployed at
> node startup prevents it from starting with the 'Security context isn't
> certain' exception.
>
> We have prepared a simple test reproducing the problem.  It works fine
> with 2.8.1 and 2.10.0 but fails with 2.11.0.
>
> To run the test unzip the package and run as
>
> mvn clean package exec:java -Dignite.version=2.8.1  // works
> fine - node starts
>
> mvn clean package exec:java -Dignite.version=2.10.0// works fine
> - node starts
>
> mvn clean package exec:java -Dignite.version=2.11.0// error -
> node doesn't start
>
> Would you please help?
>
> The following stack trace is logged:
>
> class org.apache.ignite.plugin.security.SecurityException: Security
> context isn't certain.
> at
>
> org.apache.ignite.internal.processors.security.SecurityUtils.nodeSecurityContext(SecurityUtils.java:157)
> at
>
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.localSecurityContext(IgniteSecurityProcessor.java:376)
> at
>
> java.lang.ThreadLocal$SuppliedThreadLocal.initialValue(ThreadLocal.java:284)
> at java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:180)
> at java.lang.ThreadLocal.get(ThreadLocal.java:170)
> at
>
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.authorize(IgniteSecurityProcessor.java:203)
> at
>
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.checkPermissions(IgniteServiceProcessor.java:630)
> at
>
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.prepareServiceConfigurations(IgniteServiceProcessor.java:590)
> at
>
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.staticallyConfiguredServices(IgniteServiceProcessor.java:1547)
> at
>
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.collectJoiningNodeData(IgniteServiceProcessor.java:358)
> at
>
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$5.collect(GridDiscoveryManager.java:898)
> at
>
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.collectExchangeData(TcpDiscoverySpi.java:2140)
> at
>
> org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:1106)
> at
>
> org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:473)
> at
>
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2207)
> at
>
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:278)
> at
>
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:980)
> at
>
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1985)
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1331)
> at
>
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
> at
>
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
> at
> org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:668)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:590)
> at org.apache.ignite.Ignition.start(Ignition.java:328)
> at ServerNode.main(ServerNode.java:28)
> 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.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:293)
> at java.lang.Thread.run(Thread.java:748)
>
>
> Thanks,
>
> --
>
>   Sergey
>
>
>

Re: security issues question

2021-11-18 Thread Shishkov Ilya

Hi  Timothy,
> Does this have security issues since everyone can access the port and do
cache reading/writing?

In addition to iptables rules, you can disable Thin/JDBC/ODBC protocols.
More information you can get from [1] and corresponding references
(setThinClientEnabled/setOdbcEnabled/setJdbcEnabled) in Javadoc [2].
In the other hand, you can disable the above port at all by setting
ClientConnectorConfiguration to null in IgniteConfiguration.
Also, as I see, IPv6 is used and I recommend you to read this section [3].

Links:
1.
https://ignite.apache.org/docs/latest/thin-clients/getting-started-with-thin-clients#configuring-thin-client-connector
2.
https://ignite.apache.org/releases/2.11.0/javadoc/org/apache/ignite/configuration/ClientConnectorConfiguration.html
3.
https://ignite.apache.org/docs/latest/clustering/network-configuration#ipv4-vs-ipv6

чт, 18 нояб. 2021 г. в 12:32, Gianluca Bonetti :

> Hello Timothy
>
> I usually add iptables rules on top of every deployment, to block access
> from unknown locations to Apache Ignite and other services (Tomcat to name
> one, and others)
>
> My typical iptables rules, embedded into /etc/rc.local looks like this:
>
> iptables -A INPUT -p tcp --match multiport --dport
> 10800,10801,11211,47100:47109,47400:47409,47500:47509 -s 127.0.0.1 -j ACCEPT
> iptables -A INPUT -p tcp --match multiport --dport
> 10800,10801,11211,47100:47109,47400:47409,47500:47509 -s 10.192.192.192/26
> -j ACCEPT
> iptables -A INPUT -p tcp --match multiport --dport
> 10800,10801,11211,47100:47109,47400:47409,47500:47509 -j REJECT
>
> So connection to all Ignite ports (known to me) is permitted from
> localhost, from private network space in the cloud, then forbidden from
> anywhere else.
> You may also want to limit other ports exposed to the wild you may notice
> by netstat -nat
> This is a simple solution, other experts may have better solutions, and
> I'm also interested in them :)
>
> On the other hand, I noticed your running Ignite on IPv6, but I think
> running on IPv4 is still preferred.
>
> Cheers
> Gianluca
>
> Il giorno gio 18 nov 2021 alle ore 02:08 Timothy Peng 
> ha scritto:
>
>> Hello,
>>
>> I saw Ignite is listening on all interfaces by default:
>>
>> tcp6   0  0 :::10800:::*
>> LISTEN  3211/java
>>
>>
>> Does this have security issues since everyone can access the port and do
>> cache reading/writing?
>>
>>
>> Thanks
>>
>

Re: ignite-persistence distribution is not even

2021-11-08 Thread Shishkov Ilya

Hi!
As I know, if you remove some cache entries (keys), their corresponding
segments in the data pages remain empty in the persistent store until you
insert these keys back into Ignite. So, it looks like voids in data pages.
But the rebalanced data is put into persistent storage without any kind of
"voids", i.e. it is already compressed during the rebalance routine.

пн, 8 нояб. 2021 г. в 17:36, Ibrahim Altun :

> Hi,
>
> We had a 2 node cluster with persistence enabled with backup(1) enabled,
> this morning we've added a new node to the cluster.
> Although rebalancing is finished Ignite Persistence values are not evenly
> distributed;
>
> server-1:
>
> [2021-11-08T14:31:29,371][INFO ][grid-timeout-worker-#13][IgniteKernal]
>
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
>
> ^-- Node [id=d9a3fb2f, uptime=01:35:00.491]
>
> ^-- Cluster [hosts=8, CPUs=32, servers=3, clients=7, topVer=36,
> minorTopVer=3]
>
> ^-- Network [addrs=[10.156.0.112, 127.0.0.1], discoPort=47500,
> commPort=47100]
>
> ^-- CPU [CPUs=4, curLoad=0.33%, avgLoad=3.48%, GC=0%]
>
> ^-- Heap [used=5418MB, free=33.85%, comm=8192MB]
>
> ^-- Off-heap memory [used=6025MB, free=7.92%, allocated=6344MB]
>
> ^-- Page memory [pages=1524682]
>
> ^--   sysMemPlc region [type=internal, persistence=true,
> lazyAlloc=false,
>
>   ...  initCfg=40MB, maxCfg=100MB, usedRam=0MB, freeRam=99.99%,
> allocRam=100MB, allocTotal=0MB]
>
> ^--   default region [type=default, persistence=true, lazyAlloc=true,
>
>   ...  initCfg=256MB, maxCfg=6144MB, usedRam=6025MB, freeRam=1.93%,
> allocRam=6144MB, allocTotal=80891MB]
>
> ^--   metastoreMemPlc region [type=internal, persistence=true,
> lazyAlloc=false,
>
>   ...  initCfg=40MB, maxCfg=100MB, usedRam=0MB, freeRam=99.81%,
> allocRam=0MB, allocTotal=0MB]
>
> ^--   TxLog region [type=internal, persistence=true, lazyAlloc=false,
>
>   ...  initCfg=40MB, maxCfg=100MB, usedRam=0MB, freeRam=100%,
> allocRam=100MB, allocTotal=0MB]
>
> ^--   volatileDsMemPlc region [type=user, persistence=false,
> lazyAlloc=true,
>
>   ...  initCfg=40MB, maxCfg=100MB, usedRam=0MB, freeRam=100%,
> allocRam=0MB]
>
> ^-- Ignite persistence [used=80891MB]
>
> ^-- Outbound messages queue [size=0]
>
> ^-- Public thread pool [active=0, idle=0, qSize=0]
>
> ^-- System thread pool [active=0, idle=4, qSize=0]
>
> server-2:
>
> [2021-11-08T14:31:20,475][INFO ][grid-timeout-worker-#13][IgniteKernal]
>
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
>
> ^-- Node [id=d001436d, uptime=00:46:00.231]
>
> ^-- Cluster [hosts=8, CPUs=32, servers=3, clients=7, topVer=36,
> minorTopVer=3]
>
> ^-- Network [addrs=[10.156.0.113, 127.0.0.1], discoPort=47500,
> commPort=47100]
>
> ^-- CPU [CPUs=4, curLoad=4.43%, avgLoad=5.11%, GC=0%]
>
> ^-- Heap [used=6468MB, free=21.04%, comm=8192MB]
>
> ^-- Off-heap memory [used=6025MB, free=7.92%, allocated=6344MB]
>
> ^-- Page memory [pages=1524684]
>
> ^--   sysMemPlc region [type=internal, persistence=true,
> lazyAlloc=false,
>
>   ...  initCfg=40MB, maxCfg=100MB, usedRam=0MB, freeRam=99.99%,
> allocRam=100MB, allocTotal=0MB]
>
> ^--   default region [type=default, persistence=true, lazyAlloc=true,
>
>   ...  initCfg=256MB, maxCfg=6144MB, usedRam=6025MB, freeRam=1.93%,
> allocRam=6144MB, allocTotal=82852MB]
>
> ^--   metastoreMemPlc region [type=internal, persistence=true,
> lazyAlloc=false,
>
>   ...  initCfg=40MB, maxCfg=100MB, usedRam=0MB, freeRam=99.8%,
> allocRam=0MB, allocTotal=0MB]
>
> ^--   TxLog region [type=internal, persistence=true, lazyAlloc=false,
>
>   ...  initCfg=40MB, maxCfg=100MB, usedRam=0MB, freeRam=100%,
> allocRam=100MB, allocTotal=0MB]
>
> ^--   volatileDsMemPlc region [type=user, persistence=false,
> lazyAlloc=true,
>
>   ...  initCfg=40MB, maxCfg=100MB, usedRam=0MB, freeRam=100%,
> allocRam=0MB]
>
> ^-- Ignite persistence [used=82852MB]
>
> ^-- Outbound messages queue [size=0]
>
> ^-- Public thread pool [active=0, idle=0, qSize=0]
>
> ^-- System thread pool [active=0, idle=4, qSize=0]
>
> server-3:
>
> [2021-11-08T14:31:21,364][INFO ][grid-timeout-worker-#13][IgniteKernal]
>
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
>
> ^-- Node [id=186395d1, uptime=03:36:01.279]
>
> ^-- Cluster [hosts=8, CPUs=32, servers=3, clients=7, topVer=36,
> minorTopVer=3]
>
> ^-- Network [addrs=[10.156.0.10, 127.0.0.1], discoPort=47500,
> commPort=47100]
>
> ^-- CPU [CPUs=4, curLoad=0.4%, avgLoad=8.55%, GC=0%]
>
> ^-- Heap [used=6153MB, free=24.89%, comm=8192MB]
>
> ^-- Off-heap memory [used=6025MB, free=7.92%, allocated=6344MB]
>
> ^-- Page memory [pages=1524749]
>
> ^--   sysMemPlc region [type=internal, persistence=true,
> lazyAlloc=false,
>
>   ...  initCfg=40MB, maxCfg=100MB, usedRam=0MB, freeRam=99.98%,
> allocRam=100MB, allocTotal=0MB]
>
> ^--   defaul

Re: Debugging long persistence recovery on restart

2021-09-24 Thread Shishkov Ilya

Hi  Courtney,
Have you looked at thread dumps in the moment of server nodes being stuck?

ср, 15 сент. 2021 г. в 13:44, Courtney Robinson :

> Hey all,
> We're trying to debug an issue in production where Ignite 2.8.1 is taking
> 1 hour *per node* to start.
> This cluster has 3 nodes and caches/tables have 2 backups i.e. each node
> has a replica so it takes 3 hours to restart all nodes.
> The nodes get stuck after outputting:
>
>> 2021-09-15 10:21:16.889  INFO [ArcOS,,,] 8 --- [   main]
>> o.a.i.i.p.cache.GridCacheProcessor  [285] :  Started cache in recovery
>> mode [name=*cache1*, id=-1556141001, group=hypi, dataRegionName=hypi,
>> mode=PARTITIONED, atomicity=ATOMIC, backups=2, mvcc=false]
>>
> then after it logs a similar message about *cache2* and carries on as if
> nothing happened.
> The log is always in this order and it is always these two caches.
> I believe this log happens after the cache is recovered so the problem is
> with cache2.
>
> There is only about 1GB in this cache2 that appears to have the problem.
>
> How can we find out what's causing Ignite to take an hour each on this
> cache?
>
> Regards,
> Courtney Robinson
> Founder and CEO, Hypi
> Tel: ++44 208 123 2413 (GMT+0) 
>
> 
> https://hypi.io
>

Re: Ignite 2.11.0 with ignite-spring-cache-ext

2021-09-24 Thread Shishkov Ilya

Hi Mateusz,
ignite-spring-cache-ext is in preparation for release. Below is a link to
the corresponding dev list discussion.

https://lists.apache.org/thread.html/rc165ef3659567ec1ee93502c211bec39feeb6fe9719be15ae97809a2%40%3Cdev.ignite.apache.org%3E

ср, 22 сент. 2021 г. в 07:49, Mateusz K :

> Hi Igniters,
>
> have ignite-spring-cache-ext artifacts been published? No version seems
> to be available at https://repo1.maven.org/maven2/org/apache/ignite/ as
> of today.
>
> Relevant repo link:
>
> https://github.com/apache/ignite-extensions/tree/master/modules/spring-cache-ext
>
> I need it because SpringCacheManager was removed from ignite-spring-2.11
> and I can't upgrade my project.
>
> Kind regards,
> Mateusz
>

Re: apache ignite 2.10.0 heap starvation

2021-09-12 Thread Shishkov Ilya

Hi, Ibrahim!
Have you analyzed the heap dump of the server node JVMs?
In case your application executes queries are their cursors closed?

пт, 10 сент. 2021 г. в 11:54, Ibrahim Altun :

> Igniters any comment on this issue, we are facing huge GC problems on
> production environment, please advise.
>
> On 2021/09/07 14:11:09, Ibrahim Altun 
> wrote:
> > Hi,
> >
> > totally 400 - 600K reads/writes/updates
> > 12core
> > 64GB RAM
> > no iowait
> > 10 nodes
> >
> > On 2021/09/07 12:51:28, Piotr Jagielski  wrote:
> > > Hi,
> > > Can you provide some information on how you use the cluster? How many
> reads/writes/updates per second? Also CPU / RAM spec of cluster nodes?
> > >
> > > We observed full GC / CPU load / OOM killer when loading big amount of
> data (15 mln records, data streamer + allowOverwrite=true). We've seen
> 200-400k updates per sec on JMX metrics, but load up to 10 on nodes, iowait
> to 30%. Our cluster is 3 x 4CPU, 16GB RAM (already upgradingto 8CPU, 32GB
> RAM). Ignite 2.10
> > >
> > > Regards,
> > > Piotr
> > >
> > > On 2021/09/02 08:36:07, Ibrahim Altun 
> wrote:
> > > > After upgrading from 2.7.1 version to 2.10.0 version ignite nodes
> facing
> > > > huge full GC operations after 24-36 hours after node start.
> > > >
> > > > We try to increase heap size but no luck, here is the start
> configuration
> > > > for nodes;
> > > >
> > > > JVM_OPTS="$JVM_OPTS -Xms12g -Xmx12g -server
> > > >
> -javaagent:/etc/prometheus/jmx_prometheus_javaagent-0.14.0.jar=8090:/etc/prometheus/jmx.yml
> > > > -Dcom.sun.management.jmxremote
> > > > -Dcom.sun.management.jmxremote.authenticate=false
> > > > -Dcom.sun.management.jmxremote.port=49165
> > > > -Dcom.sun.management.jmxremote.host=localhost
> > > > -XX:MaxMetaspaceSize=256m -XX:MaxDirectMemorySize=1g
> > > > -DIGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK=true
> > > > -DIGNITE_WAL_MMAP=true -DIGNITE_BPLUS_TREE_LOCK_RETRIES=10
> > > > -Djava.net.preferIPv4Stack=true"
> > > >
> > > > JVM_OPTS="$JVM_OPTS -XX:+AlwaysPreTouch -XX:+UseG1GC
> > > > -XX:+ScavengeBeforeFullGC -XX:+DisableExplicitGC
> > > > -XX:+UseStringDeduplication -Xloggc:/var/log/apache-ignite/gc.log
> > > > -XX:+PrintGCDetails -XX:+PrintGCDateStamps
> > > > -XX:+PrintTenuringDistribution -XX:+PrintGCCause
> > > > -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10
> > > > -XX:GCLogFileSize=100M"
> > > >
> > > > here is the 80 hours of GC analyize report:
> > > >
> https://gceasy.io/my-gc-report.jsp?p=c2hhcmVkLzIwMjEvMDgvMzEvLS1nYy5sb2cuMC5jdXJyZW50LnppcC0tNS01MS0yOQ==&channel=WEB
> > > >
> > > > do we need more heap size or is there a BUG that we need to be aware?
> > > >
> > > > here is the node configuration:
> > > >
> > > > 
> > > > http://www.springframework.org/schema/beans";
> > > >xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> > > >xsi:schemaLocation="
> > > > http://www.springframework.org/schema/beans
> > > > http://www.springframework.org/schema/beans/spring-beans.xsd";>
> > > >  > > > class="org.apache.ignite.configuration.IgniteConfiguration">
> > > > 
> > > > 
> > > >  > > > value="/etc/apache-ignite/ignite-log4j2.xml"/>
> > > > 
> > > > 
> > > > 
> > > >  class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > >
> > > > 
> > > > 
> > > >
> > > > 
> > > > 
> > > >  class="org.apache.ignite.spi.deployment.uri.UriDeploymentSpi">
> > > >  > > > value="/tmp/temp_ignite_libs"/>
> > > > 
> > > > 
> > > >
> > > > file://freq=5000@localhost
> /usr/share/apache-ignite/libs/segmentify/
> > > > 
> > > > 
> > > > 
> > > > 
> > > >
> > > > 
> > > > 
> > > > 
> > > >  class="org.apache.ignite.configuration.CacheConfiguration">
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > >
> > > > 
> > > > 
> > > >  class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
> > > > 
> > > > 
> > > >  > > >
> class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > >
> > > > 
> > > > 
> > > >  class="org.apache.ignite.configuration.DataStorageConfiguration">
> > > > 
> > > >  > > > class="org.apache.ignite.configuration.DataRegionConfiguration">
> > > >  value="true"/>
> > > >  > > > value="#{ 2L * 1024 * 1024 * 1024}"/>
> > > > 
>

Re: Ignite Cluster Snapshots

2021-09-12 Thread Shishkov Ilya

Hi, Siva!

As I see, it is not expected behaviour.
Is cluster baseline topology correct and all nodes are in the cluster? To
check this, you can run the 'control.sh --baseline' command.
Have you checked logs for errors on all nodes of the cluster?
Is the above behaviour the same when creating snapshot via the control
script (control.sh|bat)?

пт, 10 сент. 2021 г. в 21:43, :

> We are using  Ignite  version 2.10  and trying to create cache snapshots
> using java
> https://ignite.apache.org/docs/latest/persistence/snapshots#restoring-from-snapshot
>
>
>
> We have a 3 nodes cluster running on three different servers.
>
>
>
> ignite.snapshot().createSnapshot("snapshot_02092020")
>
>
>
> But it doesn’t create snapshot for the 3 nodes but just the node where it
> is executed. Is this expected? Is there a way to create snapshot for the
> whole cluster as mentioned in the documentation -
> https://ignite.apache.org/docs/latest/persistence/snapshots#overview
>
>
>
>
>
> Thanks,
> Siva.
>
>
> _
> “This message is for information purposes only, it is not a
> recommendation, advice, offer or solicitation to buy or sell a product or
> service nor an official confirmation of any transaction. It is directed at
> persons who are professionals and is not intended for retail customer use.
> Intended for recipient only. This message is subject to the terms at:
> www.barclays.com/emaildisclaimer.
>
> For important disclosures, please see:
> www.barclays.com/salesandtradingdisclaimer regarding market commentary
> from Barclays Sales and/or Trading, who are active market participants;
> https://www.investmentbank.barclays.com/disclosures/barclays-global-markets-disclosures.html
> regarding our standard terms for the Investment Bank of Barclays where we
> trade with you in principal-to-principal wholesale markets transactions;
> and in respect of Barclays Research, including disclosures relating to
> specific issuers, please see http://publicresearch.barclays.com.”
>
> _
> If you are incorporated or operating in Australia, please see
> https://www.home.barclays/disclosures/importantapacdisclosures.html for
> important disclosure.
>
> _
> How we use personal information  see our privacy notice
> https://www.investmentbank.barclays.com/disclosures/personalinformationuse.html
>
> _
>

Re: ignite with spring data jpa use grammar IN

2019-12-19 Thread Shishkov Ilya

Hi, I modified PersonRepository example, and it works for me:    @Query(value = "SELECT * FROM Person WHERE salary IN (?)")    public List findPersonBySalaryIn(List salaries); Here you can see changes, that I have made:https://github.com/shishkovilja/ignite/commit/b05fd27e41ea1179ba1e83ce369fc8b3c7482251  19.12.2019, 13:20, "张耀文" : as follow https://apacheignite-mix.readme.io/docs/spring-datathe first method work fine   At 2019-12-19 18:15:52, "Ivan Pavlukhin"  wrote:
>Hi,
>
>Clause "IN ?" seems broken to me. Do write your query manually?
>Unfortunately I am not familiar with Spring JPA. But with spring
>JdbcTemplate "?" can be only replaced with singular argument.
>NamedParameterJdbcTemplate is able to expand plural (e.g. List) named
>parameters.
>
>чт, 19 дек. 2019 г. в 13:05, Ilya Kasnacheev :
>>
>> Hello!
>>
>> I don't think that we support Spring JPA.
>>
>> Is it possible to tune SQL dialect with JPA? In this case, your best bet is to use H2 dialect.
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> чт, 19 дек. 2019 г. в 10:43, 张耀文 :
>>>
>>> hello, first sorry for poor english
>>> when i use jpa with 'IN',it cause some problem, how can i resolve it? i confused about the _expression_  IN ?[*] . thanks
>>>
>>> ignite:2.7.6
>>> spring jpa:ignite-spring-data_2.0
>>> spring boot:2.0.9.RELEASE
>>> h2:1.4.197
>>>
>>> jpa method: List findByShipVisitIdIsIn(List shipVisitIdList); or findByShipVisitIdIn
>>>
>>> issue track:
>>> Caused by: org.h2.jdbc.JdbcSQLException: Syntax error in SQL statement "SELECT ""BerthplanShipVisitCache"".""BerthplanShipVisit""._KEY, ""BerthplanShipVisitCache"".""BerthplanShipVisit""._VAL FROM ""BerthplanShipVisit"" WHERE ((""BerthplanShipVisit"".""shipVisitId"" IN ?[*]))"; expected "("; SQL statement:
>>> SELECT "BerthplanShipVisitCache"."BerthplanShipVisit"._KEY, "BerthplanShipVisitCache"."BerthplanShipVisit"._VAL FROM "BerthplanShipVisit" WHERE (("BerthplanShipVisit"."shipVisitId" IN ?)) [42001-197]
>>> at org.h2.message.DbException.getJdbcSQLException(DbException.java:357)
>>> at org.h2.message.DbException.getSyntaxError(DbException.java:217)
>>> at org.h2.command.Parser.getSyntaxError(Parser.java:555)
>>> at org.h2.command.Parser.read(Parser.java:3518)
>>> at org.h2.command.Parser.readCondition(Parser.java:2433)
>>> at org.h2.command.Parser.readAnd(Parser.java:2342)
>>> at org.h2.command.Parser.readExpression(Parser.java:2334)
>>> at org.h2.command.Parser.readTerm(Parser.java:3252)
>>> at org.h2.command.Parser.readFactor(Parser.java:2587)
>>> at org.h2.command.Parser.readSum(Parser.java:2574)
>>> at org.h2.command.Parser.readConcat(Parser.java:2544)
>>> at org.h2.command.Parser.readCondition(Parser.java:2370)
>>> at org.h2.command.Parser.readAnd(Parser.java:2342)
>>> at org.h2.command.Parser.readExpression(Parser.java:2334)
>>> at org.h2.command.Parser.readTerm(Parser.java:3252)
>>> at org.h2.command.Parser.readFactor(Parser.java:2587)
>>> at org.h2.command.Parser.readSum(Parser.java:2574)
>>> at org.h2.command.Parser.readConcat(Parser.java:2544)
>>> at org.h2.command.Parser.readCondition(Parser.java:2370)
>>> at org.h2.command.Parser.readAnd(Parser.java:2342)
>>> at org.h2.command.Parser.readExpression(Parser.java:2334)
>>> at org.h2.command.Parser.parseSelectSimple(Parser.java:2291)
>>> at org.h2.command.Parser.parseSelectSub(Parser.java:2133)
>>> at org.h2.command.Parser.parseSelectUnion(Parser.java:1946)
>>> at org.h2.command.Parser.parseSelect(Parser.java:1919)
>>> at org.h2.command.Parser.parsePrepared(Parser.java:463)
>>> at org.h2.command.Parser.parse(Parser.java:335)
>>> at org.h2.command.Parser.parse(Parser.java:311)
>>> at org.h2.command.Parser.prepareCommand(Parser.java:278)
>>> at org.h2.engine.Session.prepareLocal(Session.java:611)
>>> at org.h2.engine.Session.prepareCommand(Session.java:549)
>>> at org.h2.jdbc.JdbcConnection.prepareCommand(JdbcConnection.java:1247)
>>> at org.h2.jdbc.JdbcPreparedStatement.(JdbcPreparedStatement.java:76)
>>> at org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:694)
>>> at org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepare0(IgniteH2Indexing.java:539)
>>> at org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepareStatement(IgniteH2Indexing.java:509)
>>> at org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepareStatement(IgniteH2Indexing.java:476)
>>> at org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepareStatementAndCaches(IgniteH2Indexing.java:2635)
>>> ... 89 common frames omitted
>>>
>>>
>>>
>
>
>
>-- 
>Best regards,
>Ivan Pavlukhin

Re: Unable to join using thick client when authentication is enabled

Re: Unable to join using thick client when authentication is enabled

Re: Unable to join using thick client when authentication is enabled

Re: 'Security context isn't certain' exception during service deploy at node startup in 2.11.0

Re: security issues question

Re: ignite-persistence distribution is not even

Re: Debugging long persistence recovery on restart

Re: Ignite 2.11.0 with ignite-spring-cache-ext

Re: apache ignite 2.10.0 heap starvation

Re: Ignite Cluster Snapshots

Re: ignite with spring data jpa use grammar IN

11 matches

Site Navigation

Mail list logo

Footer information