[jira] [Commented] (IGNITE-12021) Inserting date from Node.JS to a cache which has Java.SQL.Timestamp
[
https://issues.apache.org/jira/browse/IGNITE-12021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16894280#comment-16894280
]
Gaurav commented on IGNITE-12021:
-
Here the sample class which I put as value in the cache.
Class order{
Constructor (id, name, qty, lastUpdateTime)
{
this.id=id;
this.name=name;
this.qty=qty;
this.lastUpdateTime= new Date();
}
}
Last Update Time is java.sql.Timestamp in Cache config .
Please suggest the change to send Timestamp.
Thanks ,
Gaurav
> Inserting date from Node.JS to a cache which has Java.SQL.Timestamp
> ---
>
> Key: IGNITE-12021
> URL: https://issues.apache.org/jira/browse/IGNITE-12021
> Project: Ignite
> Issue Type: Bug
> Components: cache, thin client
>Affects Versions: 2.7
> Environment: We are in DEV right now. can't proceed to higher
> environment with this show stopper
>Reporter: Gaurav
>Priority: Blocker
> Labels: Node.JS, ignite,
>
> I have cache which has one field with type java.sql.Timestamp
>
> From, Node.JS i am inserting it as new Date().
> If the cache is empty the inserts are successful. Issue come when java
> inserted few records in this cache (Java inserts java.sql.Timestamp) . Now ,
> if I run Node.JS program which tries to insert it gives me this error.
>
> Binary type has different field types [typeName=XYZCacheName,
> fieldName=updateTime, fieldTypeName1=Timestamp, fieldTypeName2=Date]
>
> Please help, its stopped my work totally!
>
> P.S : JavaScript new Date() is itself a Timestamp, so cache should ideally
> accept it as Timestamp and not Date.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (IGNITE-12021) Inserting date from Node.JS to a cache which has Java.SQL.Timestamp
[ https://issues.apache.org/jira/browse/IGNITE-12021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16894141#comment-16894141 ] Alexey Kosenchuk edited comment on IGNITE-12021 at 7/26/19 9:32 PM: [~g21wadhwa] could please provide a snippet of your nodejs code where you work with Date/Timestamp. The current nodejs client does not allow to write Date directly as Timestamp. You need first to make an object of Timestamp class (provided by the client). was (Author: alexey.kosenchuk): [~g21wadhwa] could please provide a snippet of your nodejs code where you work with Date/Timestamp. The current nodejs client does not allow to write Date as Timestamp. > Inserting date from Node.JS to a cache which has Java.SQL.Timestamp > --- > > Key: IGNITE-12021 > URL: https://issues.apache.org/jira/browse/IGNITE-12021 > Project: Ignite > Issue Type: Bug > Components: cache, thin client >Affects Versions: 2.7 > Environment: We are in DEV right now. can't proceed to higher > environment with this show stopper >Reporter: Gaurav >Priority: Blocker > Labels: Node.JS, ignite, > > I have cache which has one field with type java.sql.Timestamp > > From, Node.JS i am inserting it as new Date(). > If the cache is empty the inserts are successful. Issue come when java > inserted few records in this cache (Java inserts java.sql.Timestamp) . Now , > if I run Node.JS program which tries to insert it gives me this error. > > Binary type has different field types [typeName=XYZCacheName, > fieldName=updateTime, fieldTypeName1=Timestamp, fieldTypeName2=Date] > > Please help, its stopped my work totally! > > P.S : JavaScript new Date() is itself a Timestamp, so cache should ideally > accept it as Timestamp and not Date. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-12021) Inserting date from Node.JS to a cache which has Java.SQL.Timestamp
[ https://issues.apache.org/jira/browse/IGNITE-12021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16894141#comment-16894141 ] Alexey Kosenchuk commented on IGNITE-12021: --- [~g21wadhwa] could please provide a snippet of your nodejs code where you work with Date/Timestamp. The current nodejs client does not allow to write Date as Timestamp. > Inserting date from Node.JS to a cache which has Java.SQL.Timestamp > --- > > Key: IGNITE-12021 > URL: https://issues.apache.org/jira/browse/IGNITE-12021 > Project: Ignite > Issue Type: Bug > Components: cache, thin client >Affects Versions: 2.7 > Environment: We are in DEV right now. can't proceed to higher > environment with this show stopper >Reporter: Gaurav >Priority: Blocker > Labels: Node.JS, ignite, > > I have cache which has one field with type java.sql.Timestamp > > From, Node.JS i am inserting it as new Date(). > If the cache is empty the inserts are successful. Issue come when java > inserted few records in this cache (Java inserts java.sql.Timestamp) . Now , > if I run Node.JS program which tries to insert it gives me this error. > > Binary type has different field types [typeName=XYZCacheName, > fieldName=updateTime, fieldTypeName1=Timestamp, fieldTypeName2=Date] > > Please help, its stopped my work totally! > > P.S : JavaScript new Date() is itself a Timestamp, so cache should ideally > accept it as Timestamp and not Date. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-7883) Cluster can have inconsistent affinity configuration
[
https://issues.apache.org/jira/browse/IGNITE-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16893878#comment-16893878
]
Alexand Polyakov commented on IGNITE-7883:
--
[~agura] The code was tweaked, the tests passed.
> Cluster can have inconsistent affinity configuration
> -
>
> Key: IGNITE-7883
> URL: https://issues.apache.org/jira/browse/IGNITE-7883
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Alexand Polyakov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> A cluster can have inconsistent affinity configuration if you created two
> nodes, one with affinity key configuration and other without it(in IgniteCfg
> or CacheCfg), both nodes will work fine with no exceptions, but in the same
> time they will apply different affinity rules to keys:
>
> {code:java}
> package affinity;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheKeyConfiguration;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.affinity.Affinity;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import java.util.Arrays;
> public class Test {
> private static int id = 0;
> public static void main(String[] args) {
> Ignite ignite = Ignition.start(getConfiguration(true, false));
> Ignite ignite2 = Ignition.start(getConfiguration(false, false));
> Affinity affinity = ignite.affinity("TEST");
> Affinity affinity2 = ignite2.affinity("TEST");
> for (int i = 0; i < 1_000_000; i++) {
> AKey key = new AKey(i);
> if(affinity.partition(key) != affinity2.partition(key))
> System.out.println("FAILED for: " + key);
> }
> System.out.println("DONE");
> }
> private static IgniteConfiguration getConfiguration(boolean
> withAffinityCfg, boolean client) {
> IgniteConfiguration cfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
> finder.setAddresses(Arrays.asList("localhost:47500..47600"));
> cfg.setClientMode(client);
> cfg.setIgniteInstanceName("test" + id++);
> CacheConfiguration cacheCfg = new CacheConfiguration("TEST");
> cacheCfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> cacheCfg.setCacheMode(CacheMode.PARTITIONED);
> if(withAffinityCfg) {
> cacheCfg.setKeyConfiguration(new
> CacheKeyConfiguration("affinity.AKey", "a"));
> }
> cfg.setCacheConfiguration(cacheCfg);
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(finder));
> return cfg;
> }
> }
> class AKey {
> int a;
> public AKey(int a) {
> this.a = a;
> }
> @Override public String toString() {
> return "AKey{" +
> "a=" + a +
> '}';
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (IGNITE-12021) Inserting date from Node.JS to a cache which has Java.SQL.Timestamp
[ https://issues.apache.org/jira/browse/IGNITE-12021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav updated IGNITE-12021: Description: I have cache which has one field with type java.sql.Timestamp From, Node.JS i am inserting it as new Date(). If the cache is empty the inserts are successful. Issue come when java inserted few records in this cache (Java inserts java.sql.Timestamp) . Now , if I run Node.JS program which tries to insert it gives me this error. Binary type has different field types [typeName=XYZCacheName, fieldName=updateTime, fieldTypeName1=Timestamp, fieldTypeName2=Date] Please help, its stopped my work totally! P.S : JavaScript new Date() is itself a Timestamp, so cache should ideally accept it as Timestamp and not Date. was: I have cache which has one field with type java.sql.Timestamp From, Node.JS i am inserting it as new Date(). If the cache is empty the inserts are successful. Issue come when java inserted few records in this cache (Java inserts java.sql.Timestamp) . Now , if I run Node.JS program which tries to insert it gives me this error. Binary type has different field types [typeName=XYZCacheName, fieldName=updateTime, fieldTypeName1=Timestamp, fieldTypeName2=Date] Please help, its stopped my work totally! > Inserting date from Node.JS to a cache which has Java.SQL.Timestamp > --- > > Key: IGNITE-12021 > URL: https://issues.apache.org/jira/browse/IGNITE-12021 > Project: Ignite > Issue Type: Bug > Components: cache, thin client >Affects Versions: 2.7 > Environment: We are in DEV right now. can't proceed to higher > environment with this show stopper >Reporter: Gaurav >Priority: Blocker > Labels: Node.JS, ignite, > > I have cache which has one field with type java.sql.Timestamp > > From, Node.JS i am inserting it as new Date(). > If the cache is empty the inserts are successful. Issue come when java > inserted few records in this cache (Java inserts java.sql.Timestamp) . Now , > if I run Node.JS program which tries to insert it gives me this error. > > Binary type has different field types [typeName=XYZCacheName, > fieldName=updateTime, fieldTypeName1=Timestamp, fieldTypeName2=Date] > > Please help, its stopped my work totally! > > P.S : JavaScript new Date() is itself a Timestamp, so cache should ideally > accept it as Timestamp and not Date. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (IGNITE-12021) Inserting date from Node.JS to a cache which has Java.SQL.Timestamp
[ https://issues.apache.org/jira/browse/IGNITE-12021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav updated IGNITE-12021: Labels: Node.JS ignite, (was: ) > Inserting date from Node.JS to a cache which has Java.SQL.Timestamp > --- > > Key: IGNITE-12021 > URL: https://issues.apache.org/jira/browse/IGNITE-12021 > Project: Ignite > Issue Type: Bug > Components: cache, thin client >Affects Versions: 2.7 > Environment: We are in DEV right now. can't proceed to higher > environment with this show stopper >Reporter: Gaurav >Priority: Blocker > Labels: Node.JS, ignite, > > I have cache which has one field with type java.sql.Timestamp > > From, Node.JS i am inserting it as new Date(). > If the cache is empty the inserts are successful. Issue come when java > inserted few records in this cache (Java inserts java.sql.Timestamp) . Now , > if I run Node.JS program which tries to insert it gives me this error. > > Binary type has different field types [typeName=XYZCacheName, > fieldName=updateTime, fieldTypeName1=Timestamp, fieldTypeName2=Date] > > Please help, its stopped my work totally! -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-12021) Inserting date from Node.JS to a cache which has Java.SQL.Timestamp
Gaurav created IGNITE-12021: --- Summary: Inserting date from Node.JS to a cache which has Java.SQL.Timestamp Key: IGNITE-12021 URL: https://issues.apache.org/jira/browse/IGNITE-12021 Project: Ignite Issue Type: Bug Components: cache, thin client Affects Versions: 2.7 Environment: We are in DEV right now. can't proceed to higher environment with this show stopper Reporter: Gaurav I have cache which has one field with type java.sql.Timestamp From, Node.JS i am inserting it as new Date(). If the cache is empty the inserts are successful. Issue come when java inserted few records in this cache (Java inserts java.sql.Timestamp) . Now , if I run Node.JS program which tries to insert it gives me this error. Binary type has different field types [typeName=XYZCacheName, fieldName=updateTime, fieldTypeName1=Timestamp, fieldTypeName2=Date] Please help, its stopped my work totally! -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (IGNITE-11961) Provide JMX metrics for PME timings
[ https://issues.apache.org/jira/browse/IGNITE-11961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-11961: - Description: Currently, partition map exchange timings printed to log(IGNITE-10493). It will be useful if we allow external tools to collect and aggregate partition map exchange metrics. UPD: Need to implement next metrics: - `CurrentPMEDuration` - existing metric, shows current PME duration. - `CurrentPMECacheOperationsBlockedDuration` - new long metric. show blocking duration of PME. - `PMEDuration` - histogram of full PME durations. - `PMECacheOperationsBlockedDuration` - histogram of blocking PME durations. was: Currently, partition map exchange timings printed to log(IGNITE-10493). It will be useful if we allow external tools to collect and aggregate partition map exchange metrics. UPD: Need to implement next metrics: - сacheOperationsBlockedDuration (long) - totalCacheOperationsBlockedDuration (long) > Provide JMX metrics for PME timings > --- > > Key: IGNITE-11961 > URL: https://issues.apache.org/jira/browse/IGNITE-11961 > Project: Ignite > Issue Type: Improvement >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Major > Fix For: 2.8 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Currently, partition map exchange timings printed to log(IGNITE-10493). It > will be useful if we allow external tools to collect and aggregate partition > map exchange metrics. > UPD: Need to implement next metrics: > - `CurrentPMEDuration` - existing metric, shows current PME duration. > - `CurrentPMECacheOperationsBlockedDuration` - new long metric. show > blocking duration of PME. > - `PMEDuration` - histogram of full PME durations. > - `PMECacheOperationsBlockedDuration` - histogram of blocking PME durations. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (IGNITE-12014) Getting affinity for topology version earlier than affinity is calculated for system cache
[
https://issues.apache.org/jira/browse/IGNITE-12014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Kuznetsov updated IGNITE-12014:
--
Fix Version/s: 2.8
> Getting affinity for topology version earlier than affinity is calculated
> for system cache
> ---
>
> Key: IGNITE-12014
> URL: https://issues.apache.org/jira/browse/IGNITE-12014
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7.5
>Reporter: PetrovMikhail
>Priority: Major
> Fix For: 2.8
>
> Attachments: JcacheExchangeAwaitTest.java
>
>
> The following exception was being caught occasionally on a big cluster (128
> nodes) after it's activation and concurrent Ignite#reentrantLock() method
> call from different nodes. (On 16 nodes cluster this exception was never
> detected with no code change).
> It's attached a presumptive reproducer of that problem which stable fails
> with the specified exception.
> {code:java}
> java.lang.IllegalStateException: Getting affinity for topology version
> earlier than affinity is calculated [locNode=TcpDiscoveryNode
> [id=cf397493-7528-46dc-bc5a-444f9d51, consistentId=127.0.0.1:47501,
> addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47501],
> discPort=47501, order=2, intOrder=2, lastExchangeTime=1564050248387,
> loc=true, ver=2.8.0#20190725-sha1:, isClient=false],
> grp=default-volatile-ds-group, topVer=AffinityTopologyVersion [topVer=2,
> minorTopVer=1], lastAffChangeTopVer=AffinityTopologyVersion [topVer=2,
> minorTopVer=1], head=AffinityTopologyVersion [topVer=2, minorTopVer=2],
> history=[AffinityTopologyVersion [topVer=2, minorTopVer=2]]]
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:802)
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:749)
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.nodes(GridAffinityAssignmentCache.java:657)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.nodesByPartition(GridCacheAffinityManager.java:227)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByPartition(GridCacheAffinityManager.java:273)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:264)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:288)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.entryExx(GridDhtColocatedCache.java:161)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.entryEx(GridNearTxLocal.java:4470)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.enlistRead(GridNearTxLocal.java:2709)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.getAllAsync(GridNearTxLocal.java:2188)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache$4.op(GridDhtColocatedCache.java:204)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$AsyncOp.op(GridCacheAdapter.java:5644)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOp(GridCacheAdapter.java:4561)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.getAsync(GridDhtColocatedCache.java:202)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4842)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.repairableGet(GridCacheAdapter.java:4808)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1480)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.get(GridCacheProxyImpl.java:396)
> at
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor$4.applyx(DataStructuresProcessor.java:561)
> at
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor$4.applyx(DataStructuresProcessor.java:556)
> at
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.retryTopologySafe(DataStructuresProcessor.java:1664)
> at
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.getAtomic(DataStructuresProcessor.java:556)
> at
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.reentrantLock(DataStructuresProcessor.java:1361)
>
[jira] [Updated] (IGNITE-12004) CacheQueryEntityWithDateTimeApiFieldsTest.testUpdateAllFields is flaky
[ https://issues.apache.org/jira/browse/IGNITE-12004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin updated IGNITE-12004: Reviewer: Yury Gerzhedovich > CacheQueryEntityWithDateTimeApiFieldsTest.testUpdateAllFields is flaky > -- > > Key: IGNITE-12004 > URL: https://issues.apache.org/jira/browse/IGNITE-12004 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.7.5 >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > CacheQueryEntityWithDateTimeApiFieldsTest.testUpdateAllFields fails often > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-4227647830422954979=testDetails -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-12020) SQL: Metrics of using memory quotas.
Pavel Kuznetsov created IGNITE-12020: Summary: SQL: Metrics of using memory quotas. Key: IGNITE-12020 URL: https://issues.apache.org/jira/browse/IGNITE-12020 Project: Ignite Issue Type: New Feature Components: sql Reporter: Pavel Kuznetsov Assignee: Pavel Kuznetsov Only local (per node) metrics are in scope. Metrics to implement: 1) How many times memory quota have been requested on the node by all the queries in total. (org.apache.ignite.internal.processors.query.h2.QueryMemoryManager) 2) How much memory all the queries are allowed to reserve on this node in total. (Possibly constant value until node reboot) 3) How much memory currently available for the queries on this node. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-12006) Threads may be parked for indefinite time during throttling after spurious wakeups
[
https://issues.apache.org/jira/browse/IGNITE-12006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16893692#comment-16893692
]
Dmitriy Govorukhin commented on IGNITE-12006:
-
Other changes look good.
> Threads may be parked for indefinite time during throttling after spurious
> wakeups
> --
>
> Key: IGNITE-12006
> URL: https://issues.apache.org/jira/browse/IGNITE-12006
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the log we see the following behavior:
> {noformat}
> 2019-07-04 06:29:03.649[WARN
> ][sys-#328%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#328%NODE%xyzGridNodeName% for timeout(ms)=16335
> 2019-07-04 06:29:03.649[WARN
> ][sys-#326%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#326%NODE%xyzGridNodeName% for timeout(ms)=13438
> 2019-07-04 06:29:03.649[WARN
> ][sys-#277%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#277%NODE%xyzGridNodeName% for timeout(ms)=11609
> 2019-07-04 06:29:03.649[WARN
> ][sys-#331%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#331%NODE%xyzGridNodeName% for timeout(ms)=18009
> 2019-07-04 06:29:03.649[WARN
> ][sys-#321%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#321%NODE%xyzGridNodeName% for timeout(ms)=15557
> 2019-07-04 06:29:03.650[WARN
> ][sys-#307%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#307%NODE%xyzGridNodeName% for timeout(ms)=27938
> 2019-07-04 06:29:03.649[WARN
> ][sys-#316%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#316%NODE%xyzGridNodeName% for timeout(ms)=12189
> 2019-07-04 06:29:03.649[WARN
> ][sys-#311%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#311%NODE%xyzGridNodeName% for timeout(ms)=11056
> 2019-07-04 06:29:03.650[WARN
> ][sys-#295%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#295%NODE%xyzGridNodeName% for timeout(ms)=20848
> 2019-07-04 06:29:03.649[WARN
> ][sys-#290%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#290%NODE%xyzGridNodeName% for timeout(ms)=14816
> 2019-07-04 06:29:03.649[WARN
> ][sys-#332%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#332%NODE%xyzGridNodeName% for timeout(ms)=14110
> 2019-07-04 06:29:03.649[WARN
> ][sys-#298%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#298%NODE%xyzGridNodeName% for timeout(ms)=10028
> 2019-07-04 06:29:03.650[WARN
> ][sys-#304%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#304%NODE%xyzGridNodeName% for timeout(ms)=19855
> 2019-07-04 06:29:03.650[WARN
> ][sys-#331%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#331%NODE%xyzGridNodeName% for timeout(ms)=41277
> 2019-07-04 06:29:03.650[WARN
> ][sys-#291%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#291%NODE%xyzGridNodeName% for timeout(ms)=17151
> 2019-07-04 06:29:03.650[WARN
> ][sys-#308%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#308%NODE%xyzGridNodeName% for timeout(ms)=39312
> 2019-07-04 06:29:03.650[WARN
> ][sys-#322%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#322%NODE%xyzGridNodeName% for timeout(ms)=43341
> 2019-07-04 06:29:03.650[WARN
> ][sys-#306%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#306%NODE%xyzGridNodeName% for timeout(ms)=21890
> 2019-07-04 06:29:03.650[WARN
> ][sys-#315%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#315%NODE%xyzGridNodeName% for timeout(ms)=18909
> 2019-07-04 06:29:03.650[WARN
> ][sys-#321%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#321%NODE%xyzGridNodeName% for timeout(ms)=74129
> 2019-07-04 06:29:03.650[WARN
> ][sys-#305%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#305%NODE%xyzGridNodeName% for timeout(ms)=26608
> 2019-07-04 06:29:03.650[WARN
> ][sys-#309%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#309%NODE%xyzGridNodeName% for timeout(ms)=77835
> 2019-07-04 06:29:03.650[WARN
> ][sys-#291%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#291%NODE%xyzGridNodeName% for timeout(ms)=90104
> 2019-07-04 06:29:03.650[WARN
>
[jira] [Commented] (IGNITE-12006) Threads may be parked for indefinite time during throttling after spurious wakeups
[
https://issues.apache.org/jira/browse/IGNITE-12006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16893691#comment-16893691
]
Dmitriy Govorukhin commented on IGNITE-12006:
-
[~antonovsergey93] Looks like unused an excpetion in
org.apache.ignite.internal.processors.cache.persistence.pagemem.IgniteThrottlingUnitTest#wakeupThrottledThread
method throws, also code formating issued in first loop.
> Threads may be parked for indefinite time during throttling after spurious
> wakeups
> --
>
> Key: IGNITE-12006
> URL: https://issues.apache.org/jira/browse/IGNITE-12006
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the log we see the following behavior:
> {noformat}
> 2019-07-04 06:29:03.649[WARN
> ][sys-#328%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#328%NODE%xyzGridNodeName% for timeout(ms)=16335
> 2019-07-04 06:29:03.649[WARN
> ][sys-#326%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#326%NODE%xyzGridNodeName% for timeout(ms)=13438
> 2019-07-04 06:29:03.649[WARN
> ][sys-#277%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#277%NODE%xyzGridNodeName% for timeout(ms)=11609
> 2019-07-04 06:29:03.649[WARN
> ][sys-#331%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#331%NODE%xyzGridNodeName% for timeout(ms)=18009
> 2019-07-04 06:29:03.649[WARN
> ][sys-#321%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#321%NODE%xyzGridNodeName% for timeout(ms)=15557
> 2019-07-04 06:29:03.650[WARN
> ][sys-#307%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#307%NODE%xyzGridNodeName% for timeout(ms)=27938
> 2019-07-04 06:29:03.649[WARN
> ][sys-#316%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#316%NODE%xyzGridNodeName% for timeout(ms)=12189
> 2019-07-04 06:29:03.649[WARN
> ][sys-#311%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#311%NODE%xyzGridNodeName% for timeout(ms)=11056
> 2019-07-04 06:29:03.650[WARN
> ][sys-#295%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#295%NODE%xyzGridNodeName% for timeout(ms)=20848
> 2019-07-04 06:29:03.649[WARN
> ][sys-#290%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#290%NODE%xyzGridNodeName% for timeout(ms)=14816
> 2019-07-04 06:29:03.649[WARN
> ][sys-#332%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#332%NODE%xyzGridNodeName% for timeout(ms)=14110
> 2019-07-04 06:29:03.649[WARN
> ][sys-#298%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#298%NODE%xyzGridNodeName% for timeout(ms)=10028
> 2019-07-04 06:29:03.650[WARN
> ][sys-#304%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#304%NODE%xyzGridNodeName% for timeout(ms)=19855
> 2019-07-04 06:29:03.650[WARN
> ][sys-#331%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#331%NODE%xyzGridNodeName% for timeout(ms)=41277
> 2019-07-04 06:29:03.650[WARN
> ][sys-#291%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#291%NODE%xyzGridNodeName% for timeout(ms)=17151
> 2019-07-04 06:29:03.650[WARN
> ][sys-#308%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#308%NODE%xyzGridNodeName% for timeout(ms)=39312
> 2019-07-04 06:29:03.650[WARN
> ][sys-#322%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#322%NODE%xyzGridNodeName% for timeout(ms)=43341
> 2019-07-04 06:29:03.650[WARN
> ][sys-#306%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#306%NODE%xyzGridNodeName% for timeout(ms)=21890
> 2019-07-04 06:29:03.650[WARN
> ][sys-#315%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#315%NODE%xyzGridNodeName% for timeout(ms)=18909
> 2019-07-04 06:29:03.650[WARN
> ][sys-#321%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#321%NODE%xyzGridNodeName% for timeout(ms)=74129
> 2019-07-04 06:29:03.650[WARN
> ][sys-#305%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#305%NODE%xyzGridNodeName% for timeout(ms)=26608
> 2019-07-04 06:29:03.650[WARN
> ][sys-#309%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#309%NODE%xyzGridNodeName% for timeout(ms)=77835
> 2019-07-04 06:29:03.650[WARN
>
[jira] [Assigned] (IGNITE-12013) NullPointerException is thrown by ExchangeLatchManager during cache creation
[
https://issues.apache.org/jira/browse/IGNITE-12013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-12013:
Assignee: Vyacheslav Koptilin
> NullPointerException is thrown by ExchangeLatchManager during cache creation
>
>
> Key: IGNITE-12013
> URL: https://issues.apache.org/jira/browse/IGNITE-12013
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Attachments: ignitenullpointer.log
>
>
> {{NullPointerException}} may be thrown during cluster topology change:
> {code:java}
> [14:15:49,820][SEVERE][exchange-worker-#63][GridDhtPartitionsExchangeFuture]
> Failed to reinitialize local partitions (rebalancing will be stopped):
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=468,
> minorTopVer=1], discoEvt=DiscoveryCustomEvent
> [customMsg=DynamicCacheChangeBatch
> [id=728f11e1c61-11d31f36-508d-47e0-9a9c-d4f5a270948d,
> reqs=[DynamicCacheChangeRequest [cacheName=SQL_PUBLIC_UPRIYA_112093_TB,
> hasCfg=true, nodeId=10a0b1a4-09bb-4aa6-81e0-537a6431283b,
> clientStartOnly=false, stop=false, destroy=false, disabledAfterStartfalse]],
> exchangeActions=ExchangeActions [startCaches=[SQL_PUBLIC_UPRIYA_112093_TB],
> stopCaches=null, startGrps=[SQL_PUBLIC_UPRIYA_112093_TB], stopGrps=[],
> resetParts=null, stateChangeRequest=null], startCaches=false],
> affTopVer=AffinityTopologyVersion [topVer=468, minorTopVer=1],
> super=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=10a0b1a4-09bb-4aa6-81e0-537a6431283b, addrs=[0:0:0:0:0:0:0:1%lo,
> 10.244.1.100, 127.0.0.1], sockAddrs=[/10.244.1.100:0, /0:0:0:0:0:0:0:1%lo:0,
> /127.0.0.1:0], discPort=0, order=39, intOrder=27,
> lastExchangeTime=1563872413854, loc=false, ver=2.7.0#20181130-sha1:256ae401,
> isClient=true], topVer=468, nodeId8=6a076901, msg=null,
> type=DISCOVERY_CUSTOM_EVT, tstamp=1563891349722]], nodeId=10a0b1a4,
> evt=DISCOVERY_CUSTOM_EVT]
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.latch.ExchangeLatchManager.canSkipJoiningNodes(ExchangeLatchManager.java:327)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1401)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:806)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2667)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2539)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> The original topic on the user-list:
> [http://apache-ignite-users.70518.x6.nabble.com/Ignite-2-7-0-server-node-null-pointer-exception-td28899.html]
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-12016) Is there option to increase or decrease Ignite SQL Table backup count after its initialized?
[ https://issues.apache.org/jira/browse/IGNITE-12016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16893366#comment-16893366 ] Ivan Pavlukhin commented on IGNITE-12016: - Hi [~hirik], I am not aware of such feature. Consider using _user mailing list_ for asking questions. You can find instructions at the very top of https://ignite.apache.org/community/resources.html > Is there option to increase or decrease Ignite SQL Table backup count after > its initialized? > > > Key: IGNITE-12016 > URL: https://issues.apache.org/jira/browse/IGNITE-12016 > Project: Ignite > Issue Type: New Feature >Reporter: hirik >Priority: Major > > Hi, > We are working in a dynamic environment, based on the new nodes we should > update the backup count of existing SQL tables. is there any api available to > support this requirement? -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (IGNITE-11353) Web console: responses with status 401 do not redirect to signin page
[ https://issues.apache.org/jira/browse/IGNITE-11353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-11353. - > Web console: responses with status 401 do not redirect to signin page > - > > Key: IGNITE-11353 > URL: https://issues.apache.org/jira/browse/IGNITE-11353 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > Time Spent: 1h 16m > Remaining Estimate: 0h > > What happens: > On page reload, when backend API responds with status of 401, the app is > stuck on "loading" screen and does not redirect to signin screen. > What should happen: > The app should redirect to signin screen when 401 happens (except for a few > exceptions). > How to reproduce: > 1. Sign out. > 2. Open profile page URL (/settings/profile). -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-3195) Rebalancing: IgniteConfiguration.rebalanceThreadPoolSize is wrongly treated
[
https://issues.apache.org/jira/browse/IGNITE-3195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16893344#comment-16893344
]
Ignite TC Bot commented on IGNITE-3195:
---
{panel:title=Branch: [pull/6688/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4394852buildTypeId=IgniteTests24Java8_RunAll]
> Rebalancing: IgniteConfiguration.rebalanceThreadPoolSize is wrongly treated
> ---
>
> Key: IGNITE-3195
> URL: https://issues.apache.org/jira/browse/IGNITE-3195
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Denis Magda
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-16
> Fix For: 2.8
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Presently it's considered that the maximum number of threads that has to
> process all demand and supply messages coming from all the nodes must not be
> bigger than {{IgniteConfiguration.rebalanceThreadPoolSize}}.
> Current implementation relies on ordered messages functionality creating a
> number of topics equal to {{IgniteConfiguration.rebalanceThreadPoolSize}}.
> However, the implementation doesn't take into account that ordered messages,
> that correspond to a particular topic, are processed in parallel for
> different nodes. Refer to the implementation of
> {{GridIoManager.processOrderedMessage}} to see that for every topic there
> will be a unique {{GridCommunicationMessageSet}} for every node.
> Also to prove that this is true you can refer to this execution stack
> {noformat}
> java.lang.RuntimeException: HAPPENED DEMAND
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:378)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:364)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:622)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:320)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$300(GridCacheIoManager.java:81)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1125)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1219)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:105)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2456)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1179)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1900(GridIoManager.java:105)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:1148)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> All this means that in fact the number of threads that will be busy with
> replication activity will be equal to
> {{IgniteConfiguration.rebalanceThreadPoolSize}} x
> number_of_nodes_participated_in_rebalancing
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
