[jira] [Commented] (IGNITE-9409) yarn IgniteProvider uses an obsolete URL for a version check
[ https://issues.apache.org/jira/browse/IGNITE-9409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863622#comment-16863622 ] Roman Shtykh commented on IGNITE-9409: -- [~ilyak] Thanks for your work! > yarn IgniteProvider uses an obsolete URL for a version check > > > Key: IGNITE-9409 > URL: https://issues.apache.org/jira/browse/IGNITE-9409 > Project: Ignite > Issue Type: Bug > Components: yarn >Reporter: Roman Shtykh >Assignee: Ilya Kasnacheev >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11919) Change message format for incompatible fields' types changes
[
https://issues.apache.org/jira/browse/IGNITE-11919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-11919:
-
Description:
Follow this discussion thread to find out the reason for the change:
http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-stops-working-suddenly-during-dev-td42207.html
It's suggested to apply the following format:
{code}
ERROR: Type 'ClassName/TypeName' has a different/incorrect type
for field 'FieldName'. Expected 'type1' but 'type2' was provided. Field
type's modification is unsupported, clean {root_path}/marshaller directory
if the type change is required.
{code}
That's an example of how it will look like:
{code}
ERROR: Type 'Person' has a different/incorrect type
for field 'salary'. Expected 'double' but 'string' was provided. Field
type's modification is unsupported, clean {root_path}/marshaller directory
if the type change is required.
{code}
was:
Follow this discussion thread to find out the reason for the change:
http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-stops-working-suddenly-during-dev-td42207.html
It's suggested to apply the following format:
_ERROR: Type 'ClassName/TypeName' has a different/incorrect type
for field 'FieldName'. Expected 'type1' but 'type2' was provided. Field
type's modification is unsupported, clean {root_path}/marshaller directory
if the type change is required._
That's an example of how it will look like:
_ERROR: Type 'Person' has a different/incorrect type
for field 'salary'. Expected 'double' but 'string' was provided. Field
type's modification is unsupported, clean {root_path}/marshaller directory
if the type change is required._
> Change message format for incompatible fields' types changes
>
>
> Key: IGNITE-11919
> URL: https://issues.apache.org/jira/browse/IGNITE-11919
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Magda
>Priority: Blocker
> Fix For: 2.8
>
>
> Follow this discussion thread to find out the reason for the change:
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-stops-working-suddenly-during-dev-td42207.html
> It's suggested to apply the following format:
> {code}
> ERROR: Type 'ClassName/TypeName' has a different/incorrect type
> for field 'FieldName'. Expected 'type1' but 'type2' was provided. Field
> type's modification is unsupported, clean {root_path}/marshaller directory
> if the type change is required.
> {code}
> That's an example of how it will look like:
> {code}
> ERROR: Type 'Person' has a different/incorrect type
> for field 'salary'. Expected 'double' but 'string' was provided. Field
> type's modification is unsupported, clean {root_path}/marshaller directory
> if the type change is required.
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11919) Change message format for incompatible fields' types changes
Denis Magda created IGNITE-11919:
Summary: Change message format for incompatible fields' types
changes
Key: IGNITE-11919
URL: https://issues.apache.org/jira/browse/IGNITE-11919
Project: Ignite
Issue Type: Task
Reporter: Denis Magda
Fix For: 2.8
Follow this discussion thread to find out the reason for the change:
http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-stops-working-suddenly-during-dev-td42207.html
It's suggested to apply the following format:
_ERROR: Type 'ClassName/TypeName' has a different/incorrect type
for field 'FieldName'. Expected 'type1' but 'type2' was provided. Field
type's modification is unsupported, clean {root_path}/marshaller directory
if the type change is required._
That's an example of how it will look like:
_ERROR: Type 'Person' has a different/incorrect type
for field 'salary'. Expected 'double' but 'string' was provided. Field
type's modification is unsupported, clean {root_path}/marshaller directory
if the type change is required._
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11918) extend test coverage for KILL QUERY
[ https://issues.apache.org/jira/browse/IGNITE-11918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863481#comment-16863481 ] Pavel Kuznetsov commented on IGNITE-11918: -- tests run https://ci.ignite.apache.org/viewQueued.html?itemId=4113648 > extend test coverage for KILL QUERY > --- > > Key: IGNITE-11918 > URL: https://issues.apache.org/jira/browse/IGNITE-11918 > Project: Ignite > Issue Type: Test >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently we have implemented KILL QUERY COMMAND. However not all cases > covered by tests and probably it doesn't work properly for all cases. > On first look need to add following test scenarios for KILL QUERY command: > 1) not stable topology - when node couldn't reserve partitions. > 2) map and reduce parts > 3) with concrete partition > 4) when partition pruning is work. > 5) local query > 6) distributed joins. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11848) [IEP-35] Monitoring Phase 1
[ https://issues.apache.org/jira/browse/IGNITE-11848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863454#comment-16863454 ] Vyacheslav Daradur commented on IGNITE-11848: - [~NIzhikov] Looks good to me. Please run tests once again before the merge, just to be sure. > [IEP-35] Monitoring Phase 1 > -- > > Key: IGNITE-11848 > URL: https://issues.apache.org/jira/browse/IGNITE-11848 > Project: Ignite > Issue Type: Task >Affects Versions: 2.7 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > Time Spent: 6h 50m > Remaining Estimate: 0h > > Umbrella ticket for the IEP-35. Monitoring and profiling. > Phase 1 should include: > * NextGen monitoring subsystem implementation to manage > ** metrics > ** -lists- (will be implemented in the following tickets) > ** exporters > * JMX, SQLView, Log exporters > * Migration of existing metrics to new manager > * -Lists for all Ignite user API- -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11918) extend test coverage for KILL QUERY
Pavel Kuznetsov created IGNITE-11918: Summary: extend test coverage for KILL QUERY Key: IGNITE-11918 URL: https://issues.apache.org/jira/browse/IGNITE-11918 Project: Ignite Issue Type: Test Reporter: Pavel Kuznetsov Assignee: Pavel Kuznetsov Currently we have implemented KILL QUERY COMMAND. However not all cases covered by tests and probably it doesn't work properly for all cases. On first look need to add following test scenarios for KILL QUERY command: 1) not stable topology - when node couldn't reserve partitions. 2) map and reduce parts 3) with concrete partition 4) when partition pruning is work. 5) local query 6) distributed joins. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11916) reorder fields for GridQueryKillResponse and GridQueryKillRequest
[ https://issues.apache.org/jira/browse/IGNITE-11916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863384#comment-16863384 ] Pavel Kuznetsov commented on IGNITE-11916: -- Test run : https://ci.ignite.apache.org/viewQueued.html?itemId=4112673 > reorder fields for GridQueryKillResponse and GridQueryKillRequest > - > > Key: IGNITE-11916 > URL: https://issues.apache.org/jira/browse/IGNITE-11916 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > > need to reorder all fields for GridQueryKillResponse and GridQueryKillRequest > messages using MessageCodeGenerator to have right order of fields to avoid > upgrade issues. -- 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 ] shivakumar updated IGNITE-11917: Description: 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 are now 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> 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 start expiring but after some time check the records count [select count(*) from person] it should show some non zero number but if rows are selected instead of count to see the actual data with [select * from person] [select * from person] there will be zero rows. why count is not becoming zero? 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 >Priority: Major > > 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 > > > class="org.apache.ignite.configuration.CacheConfiguration"> > > > > > > factory-method="factoryOf"> > > > > > > > > > > > > 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]
[jira] [Created] (IGNITE-11917) Row count [select count(*) from table] not matching with the actual row count present in the table
shivakumar created IGNITE-11917: --- Summary: 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 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 start expiring but after some time check the records count [select count(*) from person] it should show some non zero number but if rows are selected instead of count to see the actual data with [select * from person] [select * from person] there will be zero rows. why count is not becoming zero? 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> -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11771) Kubernetes discovery support for non-ready pods
[ https://issues.apache.org/jira/browse/IGNITE-11771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863308#comment-16863308 ] Denis Magda commented on IGNITE-11771: -- [~shroman], sorry my bad. Sure, please disregard that suggestion. > Kubernetes discovery support for non-ready pods > --- > > Key: IGNITE-11771 > URL: https://issues.apache.org/jira/browse/IGNITE-11771 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Balazs Peterfi >Assignee: Denis Magda >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > I have a use case where Ignite is running in embedded mode and on start-up > there is a time consuming task to warm-up the cache. During that time > Kubernetes sees the pods as not ready due to the loading, thus the current > implementation doesn't return them as potential members. Eventually they > would become ready and see each-other but by then it would be a split-brain > situation. > The idea is to return IPs not only for "ready" pods but for "not ready" ones > as well in case the discovery client is configured that way. See more details > here: > [https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.13/#endpointsubset-v1-core] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11916) reorder fields for GridQueryKillResponse and GridQueryKillRequest
Pavel Kuznetsov created IGNITE-11916: Summary: reorder fields for GridQueryKillResponse and GridQueryKillRequest Key: IGNITE-11916 URL: https://issues.apache.org/jira/browse/IGNITE-11916 Project: Ignite Issue Type: Bug Reporter: Pavel Kuznetsov Assignee: Pavel Kuznetsov need to reorder all fields for GridQueryKillResponse and GridQueryKillRequest messages using MessageCodeGenerator to have right order of fields to avoid upgrade issues. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11910) JDBC v2: adds 'schema' to URL parameters, makes 'cache' parameter is optional for the most cases
[ https://issues.apache.org/jira/browse/IGNITE-11910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-11910: -- Summary: JDBC v2: adds 'schema' to URL parameters, makes 'cache' parameter is optional for the most cases (was: JDBC v2: adds 'schema' to URL parameters, makes 'cache' parameter is optional fpr the most cases) > JDBC v2: adds 'schema' to URL parameters, makes 'cache' parameter is optional > for the most cases > > > Key: IGNITE-11910 > URL: https://issues.apache.org/jira/browse/IGNITE-11910 > Project: Ignite > Issue Type: Bug > Components: jdbc >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.8 > > > We have to do changes for the JDBC v2: > - makes 'cache' parameter is optional. > - add 'schema' parameter to URL. > When cache and schema parameters are not defined 'PUBLIC' schema is used. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9409) yarn IgniteProvider uses an obsolete URL for a version check
[ https://issues.apache.org/jira/browse/IGNITE-9409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-9409: Component/s: yarn > yarn IgniteProvider uses an obsolete URL for a version check > > > Key: IGNITE-9409 > URL: https://issues.apache.org/jira/browse/IGNITE-9409 > Project: Ignite > Issue Type: Bug > Components: yarn >Reporter: Roman Shtykh >Assignee: Ilya Kasnacheev >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11915) Document all ways to download Ignite in YARN
Ilya Kasnacheev created IGNITE-11915: Summary: Document all ways to download Ignite in YARN Key: IGNITE-11915 URL: https://issues.apache.org/jira/browse/IGNITE-11915 Project: Ignite Issue Type: Bug Components: documentation Reporter: Ilya Kasnacheev Fix For: 2.8 That is, automatic mirror download, download by URL, local file, HDFS path, HDFS releases dir. For other properties it would be nice to mention whether they accept local or HDFS paths because it's not obvious. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9409) yarn IgniteProvider uses an obsolete URL for a version check
[ https://issues.apache.org/jira/browse/IGNITE-9409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-9409: Ignite Flags: (was: Docs Required) > yarn IgniteProvider uses an obsolete URL for a version check > > > Key: IGNITE-9409 > URL: https://issues.apache.org/jira/browse/IGNITE-9409 > Project: Ignite > Issue Type: Bug >Reporter: Roman Shtykh >Assignee: Ilya Kasnacheev >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9409) yarn IgniteProvider uses an obsolete URL for a version check
[ https://issues.apache.org/jira/browse/IGNITE-9409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863174#comment-16863174 ] Ilya Kasnacheev commented on IGNITE-9409: - I did a full range of tests on EMR, was able to start a cluster. Going to merge. [~shroman] thanks for review. > yarn IgniteProvider uses an obsolete URL for a version check > > > Key: IGNITE-9409 > URL: https://issues.apache.org/jira/browse/IGNITE-9409 > Project: Ignite > Issue Type: Bug >Reporter: Roman Shtykh >Assignee: Ilya Kasnacheev >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-3653) P2P doesn't work for remote filter and filter factory.
[
https://issues.apache.org/jira/browse/IGNITE-3653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863141#comment-16863141
]
Ignite TC Bot commented on IGNITE-3653:
---
{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=4108742]]
{color:#d04437}Platform .NET{color} [[tests 3 TIMEOUT
|https://ci.ignite.apache.org/viewLog.html?buildId=4108744]]
* exe:
CacheQueriesRestartServerTest.Test_ScanQueryAfterClientReconnect_ReturnsResults(False)
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4102688buildTypeId=IgniteTests24Java8_RunAll]
> P2P doesn't work for remote filter and filter factory.
> --
>
> Key: IGNITE-3653
> URL: https://issues.apache.org/jira/browse/IGNITE-3653
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.6
>Reporter: Nikolai Tikhonov
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.8
>
> Attachments: CCP2PTest.patch
>
>
> Remote filter and filter factory classes were not deployed on nodes which
> join to cluster after their initialization. Test attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11876) control.sh idle verify --cache-filter doesn't work without --dump option
[
https://issues.apache.org/jira/browse/IGNITE-11876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov reassigned IGNITE-11876:
-
Assignee: Denis Chudov
> control.sh idle verify --cache-filter doesn't work without --dump option
>
>
> Key: IGNITE-11876
> URL: https://issues.apache.org/jira/browse/IGNITE-11876
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Antonov
>Assignee: Denis Chudov
>Priority: Major
>
> At this moment control.sh {{--cache idle_verify --cache-filter PERSISTENT}}
> doesn't work (see {{VerifyBackupPartitionsTaskV2#isCacheMatchFilter()}}). We
> should fix it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10913) Reduce heap occupation by o.a.i.i.processors.cache.persistence.file.FilePageStore instances.
[
https://issues.apache.org/jira/browse/IGNITE-10913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863018#comment-16863018
]
Ignite TC Bot commented on IGNITE-10913:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Core Linux){color} [[tests 2 TIMEOUT
|https://ci.ignite.apache.org/viewLog.html?buildId=4086454]]
{color:#d04437}Platform .NET{color} [[tests 0 TIMEOUT
|https://ci.ignite.apache.org/viewLog.html?buildId=4086453]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4086482buildTypeId=IgniteTests24Java8_RunAll]
> Reduce heap occupation by
> o.a.i.i.processors.cache.persistence.file.FilePageStore instances.
>
>
> Key: IGNITE-10913
> URL: https://issues.apache.org/jira/browse/IGNITE-10913
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexei Scherbakov
>Assignee: Denis Chudov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> With large topology and large amount of caches/partitions and enabled
> persistence could be millions of FilePageStore objects in heap (for each
> partition).
> Each instance has a reference to a File (field cfgFile) storing as String
> absolute path to a partition.
> Also internal File inplementation (on example UnixFile) also allocates space
> for file path.
> I observed about 2Gb of heap space occupied by these objects in one of
> environments.
> Solution: dereference (set to null) cfgFile after object creation, create
> File object lazily on demand when needed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11911) GridToStringBuilder allocates redundant memory
[
https://issues.apache.org/jira/browse/IGNITE-11911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16862987#comment-16862987
]
Ryabov Dmitrii commented on IGNITE-11911:
-
Looks good.
> GridToStringBuilder allocates redundant memory
> --
>
> Key: IGNITE-11911
> URL: https://issues.apache.org/jira/browse/IGNITE-11911
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> A lot of classes in Ignite uses {{GridToStringBuilder}} to implement their
> {{toString()}} method. {{GridToStringBuilder}} uses thread local buffer to
> generate string representation. This buffer extended on demand but never
> shrank. On the final step {{GridToStringBuilder}} uses java {{StringBuilder}}
> class to produce output string and uses own buffer size as {{StringBuilder}}
> initial capacity. This leads to unnecessary memory allocation since we only
> need to allocate memory for meaningful data, but not for all buffer.
> Reproducer:
>
> {code:java}
> public void testSB() {
> GridToStringBuilder.toString(C1.class, new C1(1_000_000));
> GridToStringBuilder.toString(C1.class, new C1(100));
> }
> public class C1 {
> private String f;
> C1(int len) {
> f = new String(new char[len]);
> }
> }
> {code}
> Here on the second line about 1 million chars StringBuilder will be
> allocated, but only about 100 chars needed.
>
> Problem code (SBLimitedLength.java:293):
>
> {code:java}
> StringBuilder res = new StringBuilder(impl().capacity() + tailLen + 100);
> {code}
> Here {{length()}} method can be used instead of {{capacity()}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11848) [IEP-35] Monitoring Phase 1
[ https://issues.apache.org/jira/browse/IGNITE-11848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16862974#comment-16862974 ] Andrey Gura commented on IGNITE-11848: -- [~NIzhikov] Thanks! LGTM. If you are ready, please, proceed with merge. > [IEP-35] Monitoring Phase 1 > -- > > Key: IGNITE-11848 > URL: https://issues.apache.org/jira/browse/IGNITE-11848 > Project: Ignite > Issue Type: Task >Affects Versions: 2.7 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > Time Spent: 6h 50m > Remaining Estimate: 0h > > Umbrella ticket for the IEP-35. Monitoring and profiling. > Phase 1 should include: > * NextGen monitoring subsystem implementation to manage > ** metrics > ** -lists- (will be implemented in the following tickets) > ** exporters > * JMX, SQLView, Log exporters > * Migration of existing metrics to new manager > * -Lists for all Ignite user API- -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11913) Incorrect formatting of idle_verify output
[
https://issues.apache.org/jira/browse/IGNITE-11913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-11913:
--
Ignite Flags: (was: Docs Required)
> Incorrect formatting of idle_verify output
> --
>
> Key: IGNITE-11913
> URL: https://issues.apache.org/jira/browse/IGNITE-11913
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
>
> Command:
> {noformat}
> bin/control.sh --cache idle_verify cachepoc1.* --cache-filter PERSISTENT
> --host 172.25.1.29
> {noformat}
> Output:
> {noformat}
> Control utility [ver. 2.5.8#20190511-sha1:8b27f3a6]
> 2019 Copyright(C) Apache Software Foundation
> User: isuntsov
> Time: 2019-05-14T15:22:20.565
>
> idle_verify failed.There are no caches matching given filter options.Idle
> verify failed on nodes:
> Node ID: e5a981f6-9d0b-4cd7-aad3-fe3cc7fa6101 [172.25.1.29] consistent ID:
> poc-tester-server-172.25.1.29-id-0
> See log for additional information.
> /home/isuntsov/858_test/idle_verify-2019-05-14T15-22-20_895.txt
> {noformat}
> In general, the output is CORRECT but I think it will be more readable with
> the following formatting:
> {noformat}
> idle_verify failed.
> There are no caches matching given filter options: [ cachepoc1.*; PERSISTENT].
> Idle verify failed on nodes:
> Node ID: e5a981f6-9d0b-4cd7-aad3-fe3cc7fa6101 [172.25.1.29]
> Consistent ID: poc-tester-server-172.25.1.29-id-0
> See log for additional information:
> /home/isuntsov/858_test/idle_verify-2019-05-14T15-22-20_895.txt
> {noformat}
> Also, I guess that *null* in "Exception message" should be replaced with some
> meaningful message:
> \{noformat}
> cat /home/isuntsov/858_test/idle_verify-2019-05-14T15-22-20_895.txt
> idle_verify failed.There are no caches matching given filter options.Idle
> verify failed on nodes:
> Node ID: e5a981f6-9d0b-4cd7-aad3-fe3cc7fa6101 [172.25.1.29] consistent ID:
> poc-tester-server-172.25.1.29-id-0
> Exception message:
> null
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11914) Failures to deserialize discovery data should be handled by a failure handler
Denis Mekhanikov created IGNITE-11914:
-
Summary: Failures to deserialize discovery data should be handled
by a failure handler
Key: IGNITE-11914
URL: https://issues.apache.org/jira/browse/IGNITE-11914
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7.5
Reporter: Denis Mekhanikov
When a node during join receives a discovery data packet, that it cannot
deserialize, then this error is printed to log and not handled in any way. It
leads to swallowing potentially important failures.
For example, a failure to deserialize a continuous query remote filter should
be propagated to a failure handler, but it doesn't happen. Test is attached.
Error message:
{noformat}
Failed to unmarshal discovery data for component: 0
class org.apache.ignite.IgniteCheckedException: Failed to find class with given
class loader for unmarshalling (make sure same versions of all classes are
available on all nodes or enable peer-class-loading)
[clsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2,
cls=org.apache.ignite.tests.p2p.CacheDeploymentEntryEventFilterFactory]
at
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:146)
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:93)
at
org.apache.ignite.internal.util.IgniteUtils.unmarshalZip(IgniteUtils.java:10068)
at
org.apache.ignite.spi.discovery.tcp.internal.DiscoveryDataPacket.unmarshalData(DiscoveryDataPacket.java:292)
at
org.apache.ignite.spi.discovery.tcp.internal.DiscoveryDataPacket.unmarshalGridData(DiscoveryDataPacket.java:154)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:2065)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddFinishedMessage(ServerImpl.java:4882)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2964)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2696)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7527)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2818)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7458)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:61)
Caused by: java.lang.ClassNotFoundException:
org.apache.ignite.tests.p2p.CacheDeploymentEntryEventFilterFactory
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at
org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8672)
at
org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:59)
at
java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1863)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1746)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2037)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1568)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:428)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandlerV2.readExternal(CacheContinuousQueryHandlerV2.java:179)
at
java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:2113)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2062)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1568)
at
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2282)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2206)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2064)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1568)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:428)
at java.util.HashMap.readObject(HashMap.java:1409)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1158)
at
[jira] [Created] (IGNITE-11913) Incorrect formatting of idle_verify output
Denis Chudov created IGNITE-11913:
-
Summary: Incorrect formatting of idle_verify output
Key: IGNITE-11913
URL: https://issues.apache.org/jira/browse/IGNITE-11913
Project: Ignite
Issue Type: Bug
Reporter: Denis Chudov
Assignee: Denis Chudov
Command:
{noformat}
bin/control.sh --cache idle_verify cachepoc1.* --cache-filter PERSISTENT --host
172.25.1.29
{noformat}
Output:
{noformat}
Control utility [ver. 2.5.8#20190511-sha1:8b27f3a6]
2019 Copyright(C) Apache Software Foundation
User: isuntsov
Time: 2019-05-14T15:22:20.565
idle_verify failed.There are no caches matching given filter options.Idle
verify failed on nodes:
Node ID: e5a981f6-9d0b-4cd7-aad3-fe3cc7fa6101 [172.25.1.29] consistent ID:
poc-tester-server-172.25.1.29-id-0
See log for additional information.
/home/isuntsov/858_test/idle_verify-2019-05-14T15-22-20_895.txt
{noformat}
In general, the output is CORRECT but I think it will be more readable with the
following formatting:
{noformat}
idle_verify failed.
There are no caches matching given filter options: [ cachepoc1.*; PERSISTENT].
Idle verify failed on nodes:
Node ID: e5a981f6-9d0b-4cd7-aad3-fe3cc7fa6101 [172.25.1.29]
Consistent ID: poc-tester-server-172.25.1.29-id-0
See log for additional information:
/home/isuntsov/858_test/idle_verify-2019-05-14T15-22-20_895.txt
{noformat}
Also, I guess that *null* in "Exception message" should be replaced with some
meaningful message:
\{noformat}
cat /home/isuntsov/858_test/idle_verify-2019-05-14T15-22-20_895.txt
idle_verify failed.There are no caches matching given filter options.Idle
verify failed on nodes:
Node ID: e5a981f6-9d0b-4cd7-aad3-fe3cc7fa6101 [172.25.1.29] consistent ID:
poc-tester-server-172.25.1.29-id-0
Exception message:
null
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11848) [IEP-35] Monitoring Phase 1
[ https://issues.apache.org/jira/browse/IGNITE-11848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16862851#comment-16862851 ] Nikolay Izhikov commented on IGNITE-11848: -- [~ascherbakov] Thanks for the review! I answered all of your questions. > [IEP-35] Monitoring Phase 1 > -- > > Key: IGNITE-11848 > URL: https://issues.apache.org/jira/browse/IGNITE-11848 > Project: Ignite > Issue Type: Task >Affects Versions: 2.7 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > Time Spent: 5.5h > Remaining Estimate: 0h > > Umbrella ticket for the IEP-35. Monitoring and profiling. > Phase 1 should include: > * NextGen monitoring subsystem implementation to manage > ** metrics > ** -lists- (will be implemented in the following tickets) > ** exporters > * JMX, SQLView, Log exporters > * Migration of existing metrics to new manager > * -Lists for all Ignite user API- -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11912) [IEP-35] Research possibility to optimize MetricRegistry
Nikolay Izhikov created IGNITE-11912: Summary: [IEP-35] Research possibility to optimize MetricRegistry Key: IGNITE-11912 URL: https://issues.apache.org/jira/browse/IGNITE-11912 Project: Ignite Issue Type: Improvement Reporter: Nikolay Izhikov Assignee: Nikolay Izhikov We should research and benchmark different data structure for a MetricRegistry implementation. A basic assumption of `MetricRegistry` usage: 1. Collection of metrics almost constant during Ignite lifetime. It will be changed on cache creation(destroy) and other not frequent operations. 2. Collection of metrics will be read very frequently(each several seconds or frequently) by configured metric exporters. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5037) Fix broken @AffinityKeyMapped annotation for compute jobs.
[ https://issues.apache.org/jira/browse/IGNITE-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-5037: -- Labels: (was: newbie) > Fix broken @AffinityKeyMapped annotation for compute jobs. > -- > > Key: IGNITE-5037 > URL: https://issues.apache.org/jira/browse/IGNITE-5037 > Project: Ignite > Issue Type: Improvement >Affects Versions: 1.7 >Reporter: Alexei Scherbakov >Priority: Major > > See related discussion on dev list entitled Proper collocation of > computations and data > (http://apache-ignite-developers.2346864.n4.nabble.com/Proper-collocation-of-computations-and-data-td16945.html). > We must repair data affinity routing for compute jobs. It should work same as > for affinityCall/Run with partition. > Currently, ComputeTask map method returns Map ClusterNode>, > but we have to provide some API allows to map ComputeJobs to partitions or > keys. > This can be done using AffinityKeyMapped annotation or any other way. > Since that's a publiс API any fixes should be discussed on dev list prior to > implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
