[jira] [Commented] (IGNITE-8772) WebSessionFilter does not work with jetty 9.4 anymore
[
https://issues.apache.org/jira/browse/IGNITE-8772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16873527#comment-16873527
]
Ignite TC Bot commented on IGNITE-8772:
---
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Core Linux){color} [[tests 3 TIMEOUT
|https://ci.ignite.apache.org/viewLog.html?buildId=4205913]]
{color:#d04437}Platform .NET{color} [[tests 1 TIMEOUT
|https://ci.ignite.apache.org/viewLog.html?buildId=4205912]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4205941buildTypeId=IgniteTests24Java8_RunAll]
> WebSessionFilter does not work with jetty 9.4 anymore
> -
>
> Key: IGNITE-8772
> URL: https://issues.apache.org/jira/browse/IGNITE-8772
> Project: Ignite
> Issue Type: Bug
> Components: websession
>Affects Versions: 2.5
> Environment: * jetty-distribution-9.4.10.v20180503
> * ignite 2.5.0
>Reporter: Michael Bierwirth
>Assignee: Saikat Maitra
>Priority: Blocker
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Jetty adds a workername suffix to the session cookie, using . as delimeter:
> {{SESSIONID.node0}}
>
> In doFilterV2 the requested sessionid is read from cookie, which contains the
> suffix:
>
> {code:java}
> private String doFilterV2(HttpServletRequest httpReq, ServletResponse res,
> FilterChain chain)
> throws IOException, ServletException, CacheException {
> WebSessionV2 cached = null;String sesId = httpReq.getRequestedSessionId();
> {code}
>
> This id will never be found in the cache, because the cache key for new
> sessions is just the part before the dot.
>
> This is/may be fixed, by adding another session id transformer in the init
> method. For example:
>
> {code:java}
> if (srvInfo != null && srvInfo.contains("jetty")) {
> sesIdTransformer = s -> {
> int idx = s.indexOf('.');
> if (idx < 0 || idx == s.length() - 1) {
> return s;
> }
>2 return s.substring(0, idx);
> };
> }
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11935) Checkstyle must support NewlineAtEndOfFile rule
[
https://issues.apache.org/jira/browse/IGNITE-11935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16873447#comment-16873447
]
Aleksey Plekhanov commented on IGNITE-11935:
[~Mmuzaf] looks good to me. Merged to master.
Thanks for the contribution!
> Checkstyle must support NewlineAtEndOfFile rule
> ---
>
> Key: IGNITE-11935
> URL: https://issues.apache.org/jira/browse/IGNITE-11935
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
> Labels: checkstyle
> Fix For: 2.8
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Add support {{}} to the checkstyle plugin.
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Whitespacesandemptylines
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11907) Registration of continuous query should fail if nodes don't have remote filter class
[ https://issues.apache.org/jira/browse/IGNITE-11907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16873392#comment-16873392 ] Ivan Pavlukhin commented on IGNITE-11907: - It seems that CQ notifications can arrive to a _local listener_ before a query is registered on all nodes. Need to check that such behavior is valid. > Registration of continuous query should fail if nodes don't have remote > filter class > > > Key: IGNITE-11907 > URL: https://issues.apache.org/jira/browse/IGNITE-11907 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Assignee: Ivan Pavlukhin >Priority: Major > Attachments: > ContinuousQueryRemoteFilterMissingInClassPathSelfTest.java > > > If one of data nodes doesn't have a remote filter class, then registration of > continuous queries should fail with an exception. Currently nodes fail > instead. > Reproducer is attached: > [^ContinuousQueryRemoteFilterMissingInClassPathSelfTest.java] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8772) WebSessionFilter does not work with jetty 9.4 anymore
[
https://issues.apache.org/jira/browse/IGNITE-8772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-8772:
Reviewer: Ilya Kasnacheev
> WebSessionFilter does not work with jetty 9.4 anymore
> -
>
> Key: IGNITE-8772
> URL: https://issues.apache.org/jira/browse/IGNITE-8772
> Project: Ignite
> Issue Type: Bug
> Components: websession
>Affects Versions: 2.5
> Environment: * jetty-distribution-9.4.10.v20180503
> * ignite 2.5.0
>Reporter: Michael Bierwirth
>Assignee: Saikat Maitra
>Priority: Blocker
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Jetty adds a workername suffix to the session cookie, using . as delimeter:
> {{SESSIONID.node0}}
>
> In doFilterV2 the requested sessionid is read from cookie, which contains the
> suffix:
>
> {code:java}
> private String doFilterV2(HttpServletRequest httpReq, ServletResponse res,
> FilterChain chain)
> throws IOException, ServletException, CacheException {
> WebSessionV2 cached = null;String sesId = httpReq.getRequestedSessionId();
> {code}
>
> This id will never be found in the cache, because the cache key for new
> sessions is just the part before the dot.
>
> This is/may be fixed, by adding another session id transformer in the init
> method. For example:
>
> {code:java}
> if (srvInfo != null && srvInfo.contains("jetty")) {
> sesIdTransformer = s -> {
> int idx = s.indexOf('.');
> if (idx < 0 || idx == s.length() - 1) {
> return s;
> }
>2 return s.substring(0, idx);
> };
> }
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11895) .NET Resharper inspections got broken after update
[ https://issues.apache.org/jira/browse/IGNITE-11895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16873321#comment-16873321 ] Alexandr Shapkin commented on IGNITE-11895: --- Fixed directly in IGNITE-9876 > .NET Resharper inspections got broken after update > -- > > Key: IGNITE-11895 > URL: https://issues.apache.org/jira/browse/IGNITE-11895 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.7 >Reporter: Alexandr Shapkin >Assignee: Alexandr Shapkin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Resharper Inspection add new violation after migration from 2018.1.4 to > version 2019.1 > Lets suppress this new warning -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11907) Registration of continuous query should fail if nodes don't have remote filter class
[ https://issues.apache.org/jira/browse/IGNITE-11907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16873314#comment-16873314 ] Ivan Pavlukhin commented on IGNITE-11907: - Also, it was coined that there are 2 mechanisms for CQ registration. One used with a ring discovery and another with Zookeeper. A latter one seems to behave as expected during a query registration with a missing class. > Registration of continuous query should fail if nodes don't have remote > filter class > > > Key: IGNITE-11907 > URL: https://issues.apache.org/jira/browse/IGNITE-11907 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Assignee: Ivan Pavlukhin >Priority: Major > Attachments: > ContinuousQueryRemoteFilterMissingInClassPathSelfTest.java > > > If one of data nodes doesn't have a remote filter class, then registration of > continuous queries should fail with an exception. Currently nodes fail > instead. > Reproducer is attached: > [^ContinuousQueryRemoteFilterMissingInClassPathSelfTest.java] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11943) Checkstyle must support RedundantImport rule
[
https://issues.apache.org/jira/browse/IGNITE-11943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-11943:
-
Ignite Flags: (was: Docs Required)
> Checkstyle must support RedundantImport rule
>
>
> Key: IGNITE-11943
> URL: https://issues.apache.org/jira/browse/IGNITE-11943
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
> Labels: checkstyle
> Fix For: 2.8
>
>
> Add support {{}} checkstyle plugin.
> https://checkstyle.sourceforge.io/config_imports.html#RedundantImport
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11943) Checkstyle must support RedundantImport rule
Maxim Muzafarov created IGNITE-11943:
Summary: Checkstyle must support RedundantImport rule
Key: IGNITE-11943
URL: https://issues.apache.org/jira/browse/IGNITE-11943
Project: Ignite
Issue Type: Bug
Reporter: Maxim Muzafarov
Assignee: Maxim Muzafarov
Fix For: 2.8
Add support {{}} checkstyle plugin.
https://checkstyle.sourceforge.io/config_imports.html#RedundantImport
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11907) Registration of continuous query should fail if nodes don't have remote filter class
[ https://issues.apache.org/jira/browse/IGNITE-11907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16873291#comment-16873291 ] Ivan Pavlukhin commented on IGNITE-11907: - It turns out that a case with a joining node is handled. In that case a node is able to join a cluster but CQ does not start. Such behavior can lead to user problems and should be revised. > Registration of continuous query should fail if nodes don't have remote > filter class > > > Key: IGNITE-11907 > URL: https://issues.apache.org/jira/browse/IGNITE-11907 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Assignee: Ivan Pavlukhin >Priority: Major > Attachments: > ContinuousQueryRemoteFilterMissingInClassPathSelfTest.java > > > If one of data nodes doesn't have a remote filter class, then registration of > continuous queries should fail with an exception. Currently nodes fail > instead. > Reproducer is attached: > [^ContinuousQueryRemoteFilterMissingInClassPathSelfTest.java] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11844) Should to filtered indexes by cache name instead of validate all caches in group
[ https://issues.apache.org/jira/browse/IGNITE-11844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16873282#comment-16873282 ] Sergey Chugunov commented on IGNITE-11844: -- [~6uest], It is possible that cacheNames collection which you're using for filtering in ValidateIndexesClosure is null (take a look a few lines of code above: there are checks for the collection to be null). So the fix makes it possible for NPE to be thrown. Please fix this and add a test to verify that the code is NPE bulletproof. > Should to filtered indexes by cache name instead of validate all caches in > group > > > Key: IGNITE-11844 > URL: https://issues.apache.org/jira/browse/IGNITE-11844 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Andrey Kalinin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > control.sh utility method validate_indexes checks all indexes of all caches > in group. Just do specify one caches (from generic group) in caches list, > then all indexes from all caches (that group) will be start to validate and > this can consume more time, than checks indexes only specified caches. > Will be correct to validate only indexes of specified caches, for the purpose > need to filtered caches, by list from parameters, in shared group. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11844) Should to filtered indexes by cache name instead of validate all caches in group
[ https://issues.apache.org/jira/browse/IGNITE-11844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-11844: - Reviewer: Sergey Chugunov (was: Dmitriy Govorukhin) > Should to filtered indexes by cache name instead of validate all caches in > group > > > Key: IGNITE-11844 > URL: https://issues.apache.org/jira/browse/IGNITE-11844 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Andrey Kalinin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > control.sh utility method validate_indexes checks all indexes of all caches > in group. Just do specify one caches (from generic group) in caches list, > then all indexes from all caches (that group) will be start to validate and > this can consume more time, than checks indexes only specified caches. > Will be correct to validate only indexes of specified caches, for the purpose > need to filtered caches, by list from parameters, in shared group. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11917) Row count [select count(*) from table] not matching with the actual row count present in the table
[
https://issues.apache.org/jira/browse/IGNITE-11917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-11917:
-
Description:
To reproduce, create a sample table using JDBC endpoint:
{code}
CREATE TABLE person(Id VARCHAR, birthTime TIMESTAMP, name VARCHAR, PRIMARY
KEY(Id)) WITH "TEMPLATE=templateEternal,CACHE_NAME=person,
KEY_TYPE=personKey,VALUE_TYPE=person";
{code}
and configure cache expiry policy as below
{code}
{code}
with above cache configuration records will start expiring at the end of 10
minute, batch insert around 1 records to the table and after 10 minute
records will start expiring but after some time check the records count [select
count(*) from person] most of the time it will show some non zero number but if
rows are selected instead of count to see the actual data with [select * from
person] there will be zero rows.
why count is not becoming zero even though there is no data (rows) in the table
?
{code}
0: jdbc:ignite:thin://10.*.*.*:10800> select count(*) from person;
++
|COUNT(*)|
++
|70|
++
1 row selected (0.004 seconds)
0: jdbc:ignite:thin://10.*.*.*:10800> select * from person;
+--+--++++-
|ID|BIRTHTIME|NAME|
+--+--++++-
+--+--++++-
No rows selected (0.015 seconds)
0: jdbc:ignite:thin://10.*.*.*:10800>
{code}
was:
To reproduce, create a sample table using JDBC endpoint:
CREATE TABLE person(Id VARCHAR, birthTime TIMESTAMP, name VARCHAR, PRIMARY
KEY(Id)) WITH "TEMPLATE=templateEternal,CACHE_NAME=person,
KEY_TYPE=personKey,VALUE_TYPE=person";
and configure cache expiry policy as below
with above cache configuration records will start expiring at the end of 10
minute, batch insert around 1 records to the table and after 10 minute
records will start expiring but after some time check the records count [select
count(*) from person] most of the time it will show some non zero number but if
rows are selected instead of count to see the actual data with [select * from
person] there will be zero rows.
why count is not becoming zero even though there is no data (rows) in the table
?
0: jdbc:ignite:thin://10.*.*.*:10800> select count(*) from person;
++
|COUNT(*)|
++
|70|
++
1 row selected (0.004 seconds)
0: jdbc:ignite:thin://10.*.*.*:10800> select * from person;
+--+--++++-
|ID|BIRTHTIME|NAME|
+--+--++++-
+--+--++++-
No rows selected (0.015 seconds)
0: jdbc:ignite:thin://10.*.*.*:10800>
> Row count [select count(*) from table] not matching with the actual row count
> present in the table
> ---
>
> Key: IGNITE-11917
> URL: https://issues.apache.org/jira/browse/IGNITE-11917
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: shivakumar
>Assignee: Evgeniy Rudenko
>Priority: Major
>
> To reproduce, create a sample table using JDBC endpoint:
> {code}
> CREATE TABLE person(Id VARCHAR, birthTime TIMESTAMP, name VARCHAR, PRIMARY
> KEY(Id)) WITH "TEMPLATE=templateEternal,CACHE_NAME=person,
> KEY_TYPE=personKey,VALUE_TYPE=person";
> {code}
> and configure cache expiry policy as below
> {code}
>
>
> class="org.apache.ignite.configuration.CacheConfiguration">
>
>
>
>
>
> factory-method="factoryOf">
>
>
>
>
>
>
>
>
>
>
>
> {code}
> with above cache configuration records will start expiring at the end of 10
> minute, batch insert around 1 records to the table and after 10 minute
> records will start expiring but after some time check the records count
> [select
