[jira] [Commented] (IGNITE-8915) NPE during executing local SqlQuery from client node
[
https://issues.apache.org/jira/browse/IGNITE-8915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559363#comment-16559363
]
Nikolay Izhikov commented on IGNITE-8915:
-
[~zstan], [~vozerov]
Guys, please, share your thoughts about an extended patch.
> NPE during executing local SqlQuery from client node
>
>
> Key: IGNITE-8915
> URL: https://issues.apache.org/jira/browse/IGNITE-8915
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Vyacheslav Daradur
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.7
>
> Attachments: IgniteCacheReplicatedClientLocalQuerySelfTest.java
>
>
> NPE when trying to execute {{SqlQuery}} with {{setLocal(true)}} from client
> node.
> [Reproducer|^IgniteCacheReplicatedClientLocalQuerySelfTest.java].
> UPD:
> Right behavior:
> Local query should be forbidden and a sensible exception should be thrown if
> it is executed on client node.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7165) Re-balancing is cancelled if client node joins
[ https://issues.apache.org/jira/browse/IGNITE-7165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559371#comment-16559371 ] ASF GitHub Bot commented on IGNITE-7165: GitHub user Mmuzaf opened a pull request: https://github.com/apache/ignite/pull/4442 IGNITE-7165: skip rebalance if assigns not changed You can merge this pull request into a Git repository by running: $ git pull https://github.com/Mmuzaf/ignite ignite-7165 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4442.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4442 commit e38cd5db2b3f3c1529d08e78875eb0e043c0d9f1 Author: Maxim Muzafarov Date: 2018-07-27T07:27:58Z IGNITE-7165: skip rebalance if assigns not changed > Re-balancing is cancelled if client node joins > -- > > Key: IGNITE-7165 > URL: https://issues.apache.org/jira/browse/IGNITE-7165 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Cherkasov >Assignee: Maxim Muzafarov >Priority: Critical > Labels: rebalance > Fix For: 2.7 > > > Re-balancing is canceled if client node joins. Re-balancing can take hours > and each time when client node joins it starts again: > [15:10:05,700][INFO][disco-event-worker-#61%statement_grid%][GridDiscoveryManager] > Added new node to topology: TcpDiscoveryNode > [id=979cf868-1c37-424a-9ad1-12db501f32ef, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, > 172.31.16.213], sockAddrs=[/0:0:0:0:0:0:0:1:0, /127.0.0.1:0, > /172.31.16.213:0], discPort=0, order=36, intOrder=24, > lastExchangeTime=1512907805688, loc=false, ver=2.3.1#20171129-sha1:4b1ec0fe, > isClient=true] > [15:10:05,701][INFO][disco-event-worker-#61%statement_grid%][GridDiscoveryManager] > Topology snapshot [ver=36, servers=7, clients=5, CPUs=128, heap=160.0GB] > [15:10:05,702][INFO][exchange-worker-#62%statement_grid%][time] Started > exchange init [topVer=AffinityTopologyVersion [topVer=36, minorTopVer=0], > crd=false, evt=NODE_JOINED, evtNode=979cf868-1c37-424a-9ad1-12db501f32ef, > customEvt=null, allowMerge=true] > [15:10:05,702][INFO][exchange-worker-#62%statement_grid%][GridDhtPartitionsExchangeFuture] > Finish exchange future [startVer=AffinityTopologyVersion [topVer=36, > minorTopVer=0], resVer=AffinityTopologyVersion [topVer=36, minorTopVer=0], > err=null] > [15:10:05,702][INFO][exchange-worker-#62%statement_grid%][time] Finished > exchange init [topVer=AffinityTopologyVersion [topVer=36, minorTopVer=0], > crd=false] > [15:10:05,703][INFO][exchange-worker-#62%statement_grid%][GridCachePartitionExchangeManager] > Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion > [topVer=36, minorTopVer=0], evt=NODE_JOINED, > node=979cf868-1c37-424a-9ad1-12db501f32ef] > [15:10:08,706][INFO][exchange-worker-#62%statement_grid%][GridDhtPartitionDemander] > Cancelled rebalancing from all nodes [topology=AffinityTopologyVersion > [topVer=35, minorTopVer=0]] > [15:10:08,707][INFO][exchange-worker-#62%statement_grid%][GridCachePartitionExchangeManager] > Rebalancing scheduled [order=[statementp]] > [15:10:08,707][INFO][exchange-worker-#62%statement_grid%][GridCachePartitionExchangeManager] > Rebalancing started [top=null, evt=NODE_JOINED, > node=a8be3c14-9add-48c3-b099-3fd304cfdbf4] > [15:10:08,707][INFO][exchange-worker-#62%statement_grid%][GridDhtPartitionDemander] > Starting rebalancing [mode=ASYNC, > fromNode=2f6bde48-ffb5-4815-bd32-df4e57dc13e0, partitionsCount=18, > topology=AffinityTopologyVersion [topVer=36, minorTopVer=0], > updateSeq=-1754630006] > [15:10:08,707][INFO][exchange-worker-#62%statement_grid%][GridDhtPartitionDemander] > Starting rebalancing [mode=ASYNC, > fromNode=35d01141-4dce-47dd-adf6-a4f3b2bb9da9, partitionsCount=15, > topology=AffinityTopologyVersion [topVer=36, minorTopVer=0], > updateSeq=-1754630006] > [15:10:08,708][INFO][exchange-worker-#62%statement_grid%][GridDhtPartitionDemander] > Starting rebalancing [mode=ASYNC, > fromNode=b3a8be53-e61f-4023-a906-a265923837ba, partitionsCount=15, > topology=AffinityTopologyVersion [topVer=36, minorTopVer=0], > updateSeq=-1754630006] > [15:10:08,708][INFO][exchange-worker-#62%statement_grid%][GridDhtPartitionDemander] > Starting rebalancing [mode=ASYNC, > fromNode=f825cb4e-7dcc-405f-a40d-c1dc1a3ade5a, partitionsCount=12, > topology=AffinityTopologyVersion [topVer=36, minorTopVer=0], > updateSeq=-1754630006] > [15:10:08,708][INFO][exchange-worker-#62%statement_grid%][GridDhtPartitionDemander] > Starting rebalancing [mode=ASYNC, > fromNode=4ae1db91-8b88-4180-a84b-127a303959e9, partitionsCount=11, > topology=AffinityTopologyVersion [topVer=36
[jira] [Comment Edited] (IGNITE-7165) Re-balancing is cancelled if client node joins
[
https://issues.apache.org/jira/browse/IGNITE-7165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541426#comment-16541426
]
Maxim Muzafarov edited comment on IGNITE-7165 at 7/27/18 7:34 AM:
--
h5. Changes ready
* TC:
* PR: [#4442|https://github.com/apache/ignite/pull/4442]
* Upsource:
[IGNT-CR-699|https://reviews.ignite.apache.org/ignite/review/IGNT-CR-699]
h5. Implementation details
# _Keep topology version to rebalance (now it's not the last topology version)_
To calculate affinity assignment difference with the last topology version we
should save version on which rebalance is being currently running.
# _REPLICATED cache processing_
Affinity assignment for this type of cache always not changed. We don't need
to stop rebalance for this cache each time new topology version arrived.
Rebalance should be run only once, except situations when nodes {{LEFT}} or
{{FAIL}} cluster from which cache partition being demanded for this group.
# _EMPTY assignments handling_
Each time {{generateAssignments}} method determind no difference with current
topology version (return empty map) no matter how affinity changed we should
return successfull result as fast as possible.
# _RENTING\EVICTING partiton after PME_
PME prepares partition to be {{RENTED}} or {{EVICTED}} if they are not assign
on local node regarding new affinity calculation. Processing stale supply
message (on previous versions) can lead to exceptions with getting partitions
on local node with incorrect state. Thats why stale
{{GridDhtPartitionSupplyMessage}} must be ignored by {{Demander}}.
# _Clear suppy contex map changed_
Previously, supply context map have been cleared after each topology version
change occurs. Since we can preform rebalance not on the latest topology
version this behavior should be changed. Clear context only for nodes
left\failed from topology.
# _{{LEFT}} or {{FAIL}} nodes from cluster (rebalance restart)_
If rebalance future demand partitions from nodes which have left the cluster
rebalance must be restarted.
# _OWNING → MOVING on coordinator due to obsolete partititon update counter_
Affinity assingment can have no chanes and rebalance is currently running.
Coordinator performs PME and after megre all SingleMessages marks partitions
with obsolete update sequence to be demanded from remote nodes (by change
OWNING -> MOVING partition state). We should schedule new rebalance in this
case.
was (Author: mmuzaf):
h5. Changes ready
* TC: [#2722 (14 Jul 18
19:46)|https://ci.ignite.apache.org/viewLog.html?buildId=1497012&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_RunAll]
* PR: [#4097|https://github.com/apache/ignite/pull/4097]
* Upsource:
[IGNT-CR-670|https://reviews.ignite.apache.org/ignite/review/IGNT-CR-670]
h5. Implementation details
# _Keep topology version to demand (now it's not the last topology version)_
To calculate affinity assignment difference with the last topology version we
should save version on which rebalance is being currently running. Update this
version from exchange thread after PME will keep us away from unnecessary
processing of stale supply messages.
# _{{RebalanceFuture.demanded}} to process cache groups independently_
We have a long chain for starting rebalance process of cache groups builded by
{{addAssignments}} method (e.g. {{ignite-sys-cache -> cacheR -> cacheR3 ->
cacheR2}}). If rebalance started but initial demand message for some groups
have not been sent (e.g. due to long cleaning\evicting processes previous
groups) it can be easily cancelled and started new rebalance future.
# _REPLICATED cache processing_
Affinity assignment for this type of cache always not changed. We don't need
to stop rebalance for this cache each time new topology version arrived.
Rebalance should be run only once, except situations when nodes {{LEFT}} or
{{FAIL}} cluster from which cache partition being demanded for this group.
# _EMPTY assignments handling_
Each time {{generateAssignments}} method determind no difference with current
topology version (return empty map) no matter how affinity changed we should
return successfull result as fast as possible.
# _Pengind exchanges handling (cancelled assignments)_
Exchange thread can have pending exchanges in it's queue
({{hasPendingExchanges}} method). If such pending changes exists starting new
rebalance routine has no meaning and we should skip rebalance. This pengind
changes can cause no affinity assignments partition changes in our case and
that's why we do not need to cancel current rebalance future.
# _RENTING\EVICTING partiton after PME_
PME prepares partition to be {{RENTED}} or {{EVICTED}} if they are not assign
on local node regarding new affinity calculation. Processing stale supply
message (on previous versions) can lead to exceptions with getting partitions
on local node
[jira] [Updated] (IGNITE-3499) GridCacheReplicatedFullApiMultithreadedSelfTest1 is commented
[ https://issues.apache.org/jira/browse/IGNITE-3499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-3499: Labels: newbie (was: ) > GridCacheReplicatedFullApiMultithreadedSelfTest1 is commented > - > > Key: IGNITE-3499 > URL: https://issues.apache.org/jira/browse/IGNITE-3499 > Project: Ignite > Issue Type: Test > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexey Goncharuk >Priority: Major > Labels: newbie > > The whole body of GridCacheReplicatedFullApiMultithreadedSelfTest1 is > commented out. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-3499) GridCacheReplicatedFullApiMultithreadedSelfTest1 is commented
[ https://issues.apache.org/jira/browse/IGNITE-3499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559404#comment-16559404 ] Maxim Muzafarov commented on IGNITE-3499: - Disscusstion: http://apache-ignite-developers.2346864.n4.nabble.com/GridCacheReplicatedFullApiMultithreadedSelfTest1-not-used-not-compile-Remove-td32801.html > GridCacheReplicatedFullApiMultithreadedSelfTest1 is commented > - > > Key: IGNITE-3499 > URL: https://issues.apache.org/jira/browse/IGNITE-3499 > Project: Ignite > Issue Type: Test > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexey Goncharuk >Priority: Major > Labels: newbie > > The whole body of GridCacheReplicatedFullApiMultithreadedSelfTest1 is > commented out. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9101) Fix configuration e2e tests
Alexander Kalinin created IGNITE-9101: - Summary: Fix configuration e2e tests Key: IGNITE-9101 URL: https://issues.apache.org/jira/browse/IGNITE-9101 Project: Ignite Issue Type: Bug Reporter: Alexander Kalinin Assignee: Alexander Kalinin Current e2e tests are failing. Should be investigated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-3499) GridCacheReplicatedFullApiMultithreadedSelfTest1 is commented
[ https://issues.apache.org/jira/browse/IGNITE-3499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559405#comment-16559405 ] ASF GitHub Bot commented on IGNITE-3499: GitHub user Mmuzaf opened a pull request: https://github.com/apache/ignite/pull/4443 IGNITE-3499: remove unused class You can merge this pull request into a Git repository by running: $ git pull https://github.com/Mmuzaf/ignite ignite-3499 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4443.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4443 commit b2fdf7dce4d8b32b155a3895e24dc4d4bc5fffe8 Author: Maxim Muzafarov Date: 2018-07-27T08:10:26Z IGNITE-3499: remove unused class > GridCacheReplicatedFullApiMultithreadedSelfTest1 is commented > - > > Key: IGNITE-3499 > URL: https://issues.apache.org/jira/browse/IGNITE-3499 > Project: Ignite > Issue Type: Test > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexey Goncharuk >Priority: Major > Labels: newbie > > The whole body of GridCacheReplicatedFullApiMultithreadedSelfTest1 is > commented out. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-3499) GridCacheReplicatedFullApiMultithreadedSelfTest1 is commented
[ https://issues.apache.org/jira/browse/IGNITE-3499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov reassigned IGNITE-3499: --- Assignee: Maxim Muzafarov > GridCacheReplicatedFullApiMultithreadedSelfTest1 is commented > - > > Key: IGNITE-3499 > URL: https://issues.apache.org/jira/browse/IGNITE-3499 > Project: Ignite > Issue Type: Test > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexey Goncharuk >Assignee: Maxim Muzafarov >Priority: Major > Labels: newbie > > The whole body of GridCacheReplicatedFullApiMultithreadedSelfTest1 is > commented out. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-3499) GridCacheReplicatedFullApiMultithreadedSelfTest1 is commented
[ https://issues.apache.org/jira/browse/IGNITE-3499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559406#comment-16559406 ] Maxim Muzafarov commented on IGNITE-3499: - Folks, PR prepeared. Please, review https://github.com/apache/ignite/pull/4443/files Hope it doesn't required TC runs because it not used nowhere. > GridCacheReplicatedFullApiMultithreadedSelfTest1 is commented > - > > Key: IGNITE-3499 > URL: https://issues.apache.org/jira/browse/IGNITE-3499 > Project: Ignite > Issue Type: Test > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexey Goncharuk >Priority: Major > Labels: newbie > > The whole body of GridCacheReplicatedFullApiMultithreadedSelfTest1 is > commented out. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9102) Remove support for IE10
Alexander Kalinin created IGNITE-9102: - Summary: Remove support for IE10 Key: IGNITE-9102 URL: https://issues.apache.org/jira/browse/IGNITE-9102 Project: Ignite Issue Type: Task Reporter: Alexander Kalinin Assignee: Alexander Kalinin Internet expolored 10 is an obsolete browser that needs much development efforts. We should remove and suggest user to update if user opens web app from IE11. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9103) Select menu component doesn't strip html entities.
Alexander Kalinin created IGNITE-9103: - Summary: Select menu component doesn't strip html entities. Key: IGNITE-9103 URL: https://issues.apache.org/jira/browse/IGNITE-9103 Project: Ignite Issue Type: Bug Reporter: Alexander Kalinin Assignee: Alexander Kalinin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9104) Enhance UI grid feature
Alexander Kalinin created IGNITE-9104: - Summary: Enhance UI grid feature Key: IGNITE-9104 URL: https://issues.apache.org/jira/browse/IGNITE-9104 Project: Ignite Issue Type: Improvement Reporter: Alexander Kalinin Assignee: Alexander Kalinin We need the following changes in ui grid: 1) Show number of selected rows 2) Change :export to csv" button design. 3) Change "no data screen" for ui grid. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9102) Remove support for IE11
[ https://issues.apache.org/jira/browse/IGNITE-9102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9102: - Summary: Remove support for IE11 (was: Remove support for IE10) > Remove support for IE11 > --- > > Key: IGNITE-9102 > URL: https://issues.apache.org/jira/browse/IGNITE-9102 > Project: Ignite > Issue Type: Task >Reporter: Alexander Kalinin >Assignee: Alexander Kalinin >Priority: Major > > Internet expolored 10 is an obsolete browser that needs much development > efforts. We should remove and suggest user to update if user opens web app > from IE11. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9102) Remove support for IE11
[ https://issues.apache.org/jira/browse/IGNITE-9102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9102: - Description: Internet Expolorer 11 is an obsolete browser that needs much development efforts. We should remove and suggest user to update if user opens web app from IE11. was:Internet expolored 10 is an obsolete browser that needs much development efforts. We should remove and suggest user to update if user opens web app from IE11. > Remove support for IE11 > --- > > Key: IGNITE-9102 > URL: https://issues.apache.org/jira/browse/IGNITE-9102 > Project: Ignite > Issue Type: Task >Reporter: Alexander Kalinin >Assignee: Alexander Kalinin >Priority: Major > > Internet Expolorer 11 is an obsolete browser that needs much development > efforts. > We should remove and suggest user to update if user opens web app from IE11. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9105) Move to canvas-based chart rendering library.
Alexander Kalinin created IGNITE-9105: - Summary: Move to canvas-based chart rendering library. Key: IGNITE-9105 URL: https://issues.apache.org/jira/browse/IGNITE-9105 Project: Ignite Issue Type: Improvement Reporter: Alexander Kalinin Assignee: Alexander Kalinin Currenty we are using nvd3 lib for rendering charts, but it's svg-based and is inconvinient. We should move to canvas based libs, like ChartJS. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9106) Add bytes abbreviation filter.
Alexander Kalinin created IGNITE-9106: - Summary: Add bytes abbreviation filter. Key: IGNITE-9106 URL: https://issues.apache.org/jira/browse/IGNITE-9106 Project: Ignite Issue Type: Improvement Reporter: Alexander Kalinin Assignee: Alexander Kalinin Rendering bytes in digits like 1024 is not good UX. we should implement abbreviations for cases like 1024 -> 1 kb etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8297) TxRollbackOnTimeoutNearCacheTest.testRandomMixedTxConfigurations fails flakily
[ https://issues.apache.org/jira/browse/IGNITE-8297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov resolved IGNITE-8297. -- Resolution: Fixed Assignee: (was: Semen Boikov) Fixed to complete KeyLockFuture on timeout (f4d834b697745a7b04c42cbb08ac7451300b8ab3). > TxRollbackOnTimeoutNearCacheTest.testRandomMixedTxConfigurations fails > flakily > --- > > Key: IGNITE-8297 > URL: https://issues.apache.org/jira/browse/IGNITE-8297 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Andrey Kuznetsov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > Attachments: 7770-new2.txt > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8446) Ability to check and completely fill transactions on creation
[
https://issues.apache.org/jira/browse/IGNITE-8446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559448#comment-16559448
]
Anton Vinogradov commented on IGNITE-8446:
--
[~vkulichenko],
Thanks for your feedback. I've fixed PR according to your comments.
[~dmagda],
Could you please perform final review?
> Ability to check and completely fill transactions on creation
> -
>
> Key: IGNITE-8446
> URL: https://issues.apache.org/jira/browse/IGNITE-8446
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Fix For: 2.7
>
>
> Since {{label}} added to {{tx}} at IGNITE-6827 we'd like to have ability to
> guarantee it filled.
> So, we have to add special event fired on {{tx}} creation.
> This event can be used to provide such guarantee.
> Plan:
> Event EVT_TX_STARTED should be created.
> Tx.label should be recodred as a part of this event.
> Test, checking it's possible to restrict tx creation without filling the meta
> should be added.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8645) CacheMetrics.getCacheTxCommits() doesn't include transactions started on client node
[ https://issues.apache.org/jira/browse/IGNITE-8645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559459#comment-16559459 ] Alexey Kuznetsov commented on IGNITE-8645: -- [~dpavlov] Hi, sorry for delay. The ticket appeared to be not truly implemented. The root cause of the bug is that client metrics protocol is incorrect. Clients have got local cache metrics, e.g. tx-commits-count, but these metrics are not distributed to nodes(see metrics distribution message *TcpDiscoveryClientMetricsUpdateMessage* carries no cache metrics, only cluster metrics). This leads to current bug. So client metrics protocol shall be fixed in first place. Im going to fix it within current ticket. > CacheMetrics.getCacheTxCommits() doesn't include transactions started on > client node > > > Key: IGNITE-8645 > URL: https://issues.apache.org/jira/browse/IGNITE-8645 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.4 >Reporter: Roman Guseinov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > Attachments: CacheTxCommitsMetricTest.java > > > The test is attached [^CacheTxCommitsMetricTest.java] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7700) SQL system view for list of nodes
[ https://issues.apache.org/jira/browse/IGNITE-7700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559475#comment-16559475 ] ASF GitHub Bot commented on IGNITE-7700: Github user devozerov closed the pull request at: https://github.com/apache/ignite/pull/4424 > SQL system view for list of nodes > - > > Key: IGNITE-7700 > URL: https://issues.apache.org/jira/browse/IGNITE-7700 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-13, sql > Fix For: 2.7 > > > Implement SQL system view to show list of nodes in topology. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7700) SQL system view for list of nodes
[ https://issues.apache.org/jira/browse/IGNITE-7700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559479#comment-16559479 ] ASF GitHub Bot commented on IGNITE-7700: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4185 > SQL system view for list of nodes > - > > Key: IGNITE-7700 > URL: https://issues.apache.org/jira/browse/IGNITE-7700 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-13, sql > Fix For: 2.7 > > > Implement SQL system view to show list of nodes in topology. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9101) Fix configuration e2e tests
[ https://issues.apache.org/jira/browse/IGNITE-9101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559511#comment-16559511 ] Alexander Kalinin commented on IGNITE-9101: --- Done. branch ignite-9101 > Fix configuration e2e tests > --- > > Key: IGNITE-9101 > URL: https://issues.apache.org/jira/browse/IGNITE-9101 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Kalinin >Assignee: Alexander Kalinin >Priority: Major > > Current e2e tests are failing. Should be investigated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9101) Fix configuration e2e tests
[ https://issues.apache.org/jira/browse/IGNITE-9101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-9101: - Assignee: Alexey Kuznetsov (was: Alexander Kalinin) > Fix configuration e2e tests > --- > > Key: IGNITE-9101 > URL: https://issues.apache.org/jira/browse/IGNITE-9101 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Kalinin >Assignee: Alexey Kuznetsov >Priority: Major > > Current e2e tests are failing. Should be investigated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9102) Remove support for IE11
[ https://issues.apache.org/jira/browse/IGNITE-9102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-9102: - Assignee: Alexey Kuznetsov (was: Alexander Kalinin) Done. branch ignite-9102 > Remove support for IE11 > --- > > Key: IGNITE-9102 > URL: https://issues.apache.org/jira/browse/IGNITE-9102 > Project: Ignite > Issue Type: Task >Reporter: Alexander Kalinin >Assignee: Alexey Kuznetsov >Priority: Major > > Internet Expolorer 11 is an obsolete browser that needs much development > efforts. > We should remove and suggest user to update if user opens web app from IE11. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9103) Select menu component doesn't strip html entities.
[ https://issues.apache.org/jira/browse/IGNITE-9103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-9103: - Assignee: Alexey Kuznetsov (was: Alexander Kalinin) Done. Branch ignite-9103 > Select menu component doesn't strip html entities. > -- > > Key: IGNITE-9103 > URL: https://issues.apache.org/jira/browse/IGNITE-9103 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Kalinin >Assignee: Alexey Kuznetsov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9105) Move to canvas-based chart rendering library.
[ https://issues.apache.org/jira/browse/IGNITE-9105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-9105: - Assignee: Alexey Kuznetsov (was: Alexander Kalinin) > Move to canvas-based chart rendering library. > - > > Key: IGNITE-9105 > URL: https://issues.apache.org/jira/browse/IGNITE-9105 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Kalinin >Assignee: Alexey Kuznetsov >Priority: Major > > Currenty we are using nvd3 lib for rendering charts, but it's svg-based and > is inconvinient. We should move to canvas based libs, like ChartJS. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9104) Enhance UI grid feature
[ https://issues.apache.org/jira/browse/IGNITE-9104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-9104: - Assignee: Alexey Kuznetsov (was: Alexander Kalinin) Done. Branch ignite-9104 > Enhance UI grid feature > --- > > Key: IGNITE-9104 > URL: https://issues.apache.org/jira/browse/IGNITE-9104 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Kalinin >Assignee: Alexey Kuznetsov >Priority: Major > > We need the following changes in ui grid: > 1) Show number of selected rows > 2) Change :export to csv" button design. > 3) Change "no data screen" for ui grid. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9105) Move to canvas-based chart rendering library.
[ https://issues.apache.org/jira/browse/IGNITE-9105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-9105: - Assignee: Alexander Kalinin (was: Alexey Kuznetsov) > Move to canvas-based chart rendering library. > - > > Key: IGNITE-9105 > URL: https://issues.apache.org/jira/browse/IGNITE-9105 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Kalinin >Assignee: Alexander Kalinin >Priority: Major > > Currenty we are using nvd3 lib for rendering charts, but it's svg-based and > is inconvinient. We should move to canvas based libs, like ChartJS. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9105) Move to canvas-based chart rendering library.
[ https://issues.apache.org/jira/browse/IGNITE-9105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559522#comment-16559522 ] Alexander Kalinin edited comment on IGNITE-9105 at 7/27/18 10:07 AM: - Done. Branch ignite-9105 was (Author: alexdel): Done. Branch ignite-9104 > Move to canvas-based chart rendering library. > - > > Key: IGNITE-9105 > URL: https://issues.apache.org/jira/browse/IGNITE-9105 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Kalinin >Assignee: Alexey Kuznetsov >Priority: Major > > Currenty we are using nvd3 lib for rendering charts, but it's svg-based and > is inconvinient. We should move to canvas based libs, like ChartJS. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9106) Add bytes abbreviation filter.
[ https://issues.apache.org/jira/browse/IGNITE-9106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-9106: - Assignee: Alexey Kuznetsov (was: Alexander Kalinin) Done. Branch ignite-9106 > Add bytes abbreviation filter. > -- > > Key: IGNITE-9106 > URL: https://issues.apache.org/jira/browse/IGNITE-9106 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Kalinin >Assignee: Alexey Kuznetsov >Priority: Major > > Rendering bytes in digits like 1024 is not good UX. we should implement > abbreviations for cases like 1024 -> 1 kb etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9105) Move to canvas-based chart rendering library.
[ https://issues.apache.org/jira/browse/IGNITE-9105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-9105: - Assignee: Alexey Kuznetsov (was: Alexander Kalinin) Done. Branch ignite-9104 > Move to canvas-based chart rendering library. > - > > Key: IGNITE-9105 > URL: https://issues.apache.org/jira/browse/IGNITE-9105 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Kalinin >Assignee: Alexey Kuznetsov >Priority: Major > > Currenty we are using nvd3 lib for rendering charts, but it's svg-based and > is inconvinient. We should move to canvas based libs, like ChartJS. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8900) SqlFieldsQuery provides incorrect result when item size exceeds page size
[ https://issues.apache.org/jira/browse/IGNITE-8900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-8900: --- Fix Version/s: 2.7 > SqlFieldsQuery provides incorrect result when item size exceeds page size > - > > Key: IGNITE-8900 > URL: https://issues.apache.org/jira/browse/IGNITE-8900 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.4 >Reporter: Anton Kurbanov >Assignee: Ilya Lantukh >Priority: Blocker > Fix For: 2.7 > > Attachments: Main.java, Node.java > > > Start several server nodes, then start client, execute queries with value > range in where clause. Duplicate entries may be found, some entries may be > missing. > Results as an example: > expected 5 results but got back 3 results (query range 61002664327616 to > 610026643276160004), cache.getAll returned 5 entries. > expected 8 results but got back 7 results (query range 61002664327616 to > 610026643276160007), cache.getAll returned 8 entries. > Query results: [61002664327616, 610026643276160003, 610026643276160004, > 610026643276160005, 610026643276160005, 610026643276160006, > 610026643276160007] > Please find reproducer attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8926) Deadlock in meta data registration
[ https://issues.apache.org/jira/browse/IGNITE-8926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-8926: --- Fix Version/s: 2.7 > Deadlock in meta data registration > -- > > Key: IGNITE-8926 > URL: https://issues.apache.org/jira/browse/IGNITE-8926 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Mikhail Cherkasov >Assignee: Ilya Lantukh >Priority: Major > Fix For: 2.7 > > Attachments: DeadlockTest.java, file.jstack > > > > Please file the attached jstack file with a deadlock. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9068) Node fails to stop when CacheObjectBinaryProcessor.addMeta() is executed inside guard()/unguard()
[
https://issues.apache.org/jira/browse/IGNITE-9068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Govorukhin updated IGNITE-9068:
---
Fix Version/s: 2.7
> Node fails to stop when CacheObjectBinaryProcessor.addMeta() is executed
> inside guard()/unguard()
> -
>
> Key: IGNITE-9068
> URL: https://issues.apache.org/jira/browse/IGNITE-9068
> Project: Ignite
> Issue Type: Bug
> Components: binary, managed services
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Lantukh
>Priority: Major
> Labels: test
> Fix For: 2.7
>
> Attachments: GridServiceDeadlockTest.java, MyService.java
>
>
> When addMeta is called in e.g. service deployment it us executed inside
> guard()/unguard()
> If node will be stopped at this point, Ignite.stop() will hang.
> Consider the following thread dump:
> {code}
> "Thread-1" #57 prio=5 os_prio=0 tid=0x7f7780005000 nid=0x7f26 runnable
> [0x7f766cbef000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0005cb7b0468> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireNanos(AbstractQueuedSynchronizer.java:934)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireNanos(AbstractQueuedSynchronizer.java:1247)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.tryLock(ReentrantReadWriteLock.java:1115)
> at
> org.apache.ignite.internal.util.StripedCompositeReadWriteLock$WriteLock.tryLock(StripedCompositeReadWriteLock.java:220)
> at
> org.apache.ignite.internal.GridKernalGatewayImpl.tryWriteLock(GridKernalGatewayImpl.java:143)
> // Waiting for lock to cancel futures of BinaryMetadataTransport
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2171)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2094)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2545)
> - locked <0x0005cb423f00> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2508)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.run(IgnitionEx.java:2033)
> "test-runner-#1%service.GridServiceDeadlockTest%" #13 prio=5 os_prio=0
> tid=0x7f77b87d5800 nid=0x7eb8 waiting on condition [0x7f778cdfc000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> // May never return if there's discovery problems
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:463)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.addMeta(CacheObjectBinaryProcessorImpl.java:188)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:802)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerClassDescriptor(BinaryContext.java:761)
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForClass(BinaryContext.java:627)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:174)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:157)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:144)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:254)
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.marshal0(BinaryMarshaller.java:82)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:58)
> at
> org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10069)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.prepareServiceConfigurations(GridServiceProcessor.java:570)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:622)
> at
> org.apache.
[jira] [Assigned] (IGNITE-5103) TcpDiscoverySpi ignores maxMissedClientHeartbeats property
[
https://issues.apache.org/jira/browse/IGNITE-5103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Karachentsev reassigned IGNITE-5103:
---
Assignee: (was: Dmitry Karachentsev)
> TcpDiscoverySpi ignores maxMissedClientHeartbeats property
> --
>
> Key: IGNITE-5103
> URL: https://issues.apache.org/jira/browse/IGNITE-5103
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.9
>Reporter: Valentin Kulichenko
>Priority: Major
> Fix For: 2.7
>
> Attachments: TcpDiscoveryClientSuspensionSelfTest.java
>
>
> Test scenario is the following:
> * Start one or more servers.
> * Start a client node.
> * Suspend client process using {{-SIGSTOP}} signal.
> * Wait for {{maxMissedClientHeartbeats*heartbeatFrequency}}.
> * Client node is expected to be removed from topology, but server nodes don't
> do that.
> Attached is the unit test reproducing the same by stopping the heartbeat
> sender thread on the client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6259) GridServiceProcessor may leave futures hanging on unstable topology
[ https://issues.apache.org/jira/browse/IGNITE-6259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559551#comment-16559551 ] Vyacheslav Daradur commented on IGNITE-6259: [~ezhuravl], [~dmekhanikov], I'd like to pick up this ticket if you don't mind? > GridServiceProcessor may leave futures hanging on unstable topology > --- > > Key: IGNITE-6259 > URL: https://issues.apache.org/jira/browse/IGNITE-6259 > Project: Ignite > Issue Type: Bug >Affects Versions: 1.7, 1.8, 1.9, 2.0, 2.1 >Reporter: Denis Mekhanikov >Assignee: Evgenii Zhuravlev >Priority: Major > > GridServiceProcessor subscribes to updates on the internal cache to get > information about new deployments or cancellations of services. Some of such > updates may be lost under conditions of unstable topology. It leads to > services not being deployed and client futures infinitely hanging. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8715) Problems with Closeable objects from Factory
[ https://issues.apache.org/jira/browse/IGNITE-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559607#comment-16559607 ] Denis Garus commented on IGNITE-8715: - LGTM > Problems with Closeable objects from Factory > > > Key: IGNITE-8715 > URL: https://issues.apache.org/jira/browse/IGNITE-8715 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexander Menshikov >Assignee: Pavel Pereslegin >Priority: Major > Labels: iep-21 > Fix For: 2.7 > > > According to specification Cache#close() should clean up all Closeable > objects (CacheLoader, CacheWriter, CacheEntryListener, ExpiryPolicy) created > by factories. > And in TCK 1.0.1 there are no such tests. But in TCK 1.1.0 there are checks > for it. And Ignite fails it because hasn't such functionality. > So this task about improvement. > Please see links for details. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6259) GridServiceProcessor may leave futures hanging on unstable topology
[ https://issues.apache.org/jira/browse/IGNITE-6259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559619#comment-16559619 ] Evgenii Zhuravlev commented on IGNITE-6259: --- Hi Vyacheslav, sure, please take it over. > GridServiceProcessor may leave futures hanging on unstable topology > --- > > Key: IGNITE-6259 > URL: https://issues.apache.org/jira/browse/IGNITE-6259 > Project: Ignite > Issue Type: Bug >Affects Versions: 1.7, 1.8, 1.9, 2.0, 2.1 >Reporter: Denis Mekhanikov >Assignee: Evgenii Zhuravlev >Priority: Major > > GridServiceProcessor subscribes to updates on the internal cache to get > information about new deployments or cancellations of services. Some of such > updates may be lost under conditions of unstable topology. It leads to > services not being deployed and client futures infinitely hanging. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-6259) GridServiceProcessor may leave futures hanging on unstable topology
[ https://issues.apache.org/jira/browse/IGNITE-6259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev reassigned IGNITE-6259: - Assignee: (was: Evgenii Zhuravlev) > GridServiceProcessor may leave futures hanging on unstable topology > --- > > Key: IGNITE-6259 > URL: https://issues.apache.org/jira/browse/IGNITE-6259 > Project: Ignite > Issue Type: Bug >Affects Versions: 1.7, 1.8, 1.9, 2.0, 2.1 >Reporter: Denis Mekhanikov >Priority: Major > > GridServiceProcessor subscribes to updates on the internal cache to get > information about new deployments or cancellations of services. Some of such > updates may be lost under conditions of unstable topology. It leads to > services not being deployed and client futures infinitely hanging. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9073) Ignite modules should use jackson2 dependency rater then jackson1
[ https://issues.apache.org/jira/browse/IGNITE-9073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559624#comment-16559624 ] ASF GitHub Bot commented on IGNITE-9073: Github user zzzadruga closed the pull request at: https://github.com/apache/ignite/pull/4431 > Ignite modules should use jackson2 dependency rater then jackson1 > - > > Key: IGNITE-9073 > URL: https://issues.apache.org/jira/browse/IGNITE-9073 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Garus >Assignee: Nikolai kulagin >Priority: Major > Fix For: 2.7 > > > Ignite modules should use jackson2 dependency rater then jackson1. > It is required to run RunAll to check all tests passed, check full build > locally using build.sh. > Probably it is required to run release step to make sure release candidate > can be prepared -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9053) testReentrantLockConstantTopologyChangeNonFailoverSafe can hang in case of broken tx
[
https://issues.apache.org/jira/browse/IGNITE-9053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov reassigned IGNITE-9053:
Assignee: Anton Vinogradov
> testReentrantLockConstantTopologyChangeNonFailoverSafe can hang in case of
> broken tx
>
>
> Key: IGNITE-9053
> URL: https://issues.apache.org/jira/browse/IGNITE-9053
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 2.5
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> -GridCachePartitionedDataStructuresFailoverSelfTest#testReentrantLockConstantTopologyChangeNonFailoverSafe
> -GridCachePartitionedDataStructuresFailoverSelfTest#testCountDownLatchConstantTopologyChange
>
> can hang in case of broken tx
> {noformat}
> Pending transactions:
> [2018-07-15 14:13:41,210][WARN
> ][exchange-worker-#1596354%partitioned.GridCachePartitionedDataStructuresFailoverSelfTest1%][diagnostic]
> >>> [txVer=AffinityTopologyVersion [topVer=7, minorTopVer=0], exchWait=true,
> tx=GridDhtTxLocal [nearNodeId=1392b1bd-c807-4479-9bfe-fc9f7050,
> nearFutId=14ffca0a461-999e75d0-a333-4bd6-a2a2-7f143d0af773, nearMiniId=1,
> nearFinFutId=null, nearFinMiniId=0, nearXidVer=GridCacheVersion
> [topVer=143133203, order=1531653200153, nodeOrder=1],
> super=GridDhtTxLocalAdapter [nearOnOriginatingNode=false, nearNodes=[],
> dhtNodes=[], explicitLock=false, super=IgniteTxLocalAdapter
> [completedBase=null, sndTransformedVals=false, depEnabled=false,
> txState=IgniteTxStateImpl [activeCacheIds=[1968300681], recovery=false,
> txMap=[IgniteTxEntry [key=KeyCacheObjectImpl [part=494,
> val=GridCacheInternalKeyImpl [name=structure,
> grpName=default-volatile-ds-group], hasValBytes=true], cacheId=1968300681,
> txKey=IgniteTxKey [key=KeyCacheObjectImpl [part=494,
> val=GridCacheInternalKeyImpl [name=structure,
> grpName=default-volatile-ds-group], hasValBytes=true], cacheId=1968300681],
> val=[op=NOOP, val=null], prevVal=[op=NOOP, val=null], oldVal=[op=NOOP,
> val=null], entryProcessorsCol=null, ttl=-1, conflictExpireTime=-1,
> conflictVer=null, explicitVer=null, dhtVer=null, filters=[],
> filtersPassed=false, filtersSet=false, entry=GridDhtCacheEntry [rdrs=[],
> part=494, super=GridDistributedCacheEntry [super=GridCacheMapEntry
> [key=KeyCacheObjectImpl [part=494, val=GridCacheInternalKeyImpl
> [name=structure, grpName=default-volatile-ds-group], hasValBytes=true],
> val=CacheObjectImpl [val=null, hasValBytes=true], ver=GridCacheVersion
> [topVer=143133201, order=1531653200154, nodeOrder=2], hash=2095426867,
> extras=GridCacheMvccEntryExtras [mvcc=GridCacheMvcc
> [locs=[GridCacheMvccCandidate [nodeId=1bf28b00-feed-412b-a20b-ca9fc111,
> ver=GridCacheVersion [topVer=143133203, order=1531653200157, nodeOrder=2],
> threadId=1947290, id=31143709, topVer=AffinityTopologyVersion [topVer=7,
> minorTopVer=0], reentry=null,
> otherNodeId=1392b1bd-c807-4479-9bfe-fc9f7050, otherVer=GridCacheVersion
> [topVer=143133203, order=1531653200153, nodeOrder=1], mappedDhtNodes=null,
> mappedNearNodes=null, ownerVer=null, serOrder=null, key=KeyCacheObjectImpl
> [part=494, val=GridCacheInternalKeyImpl [name=structure,
> grpName=default-volatile-ds-group], hasValBytes=true],
> masks=local=1|owner=1|ready=1|reentry=0|used=0|tx=1|single_implicit=0|dht_local=1|near_local=0|removed=0|read=0,
> prevVer=null, nextVer=null]], rmts=null]], flags=2]]], prepared=0,
> locked=false, nodeId=null, locMapped=false, expiryPlc=null,
> transferExpiryPlc=false, flags=0, partUpdateCntr=0, serReadVer=null,
> xidVer=GridCacheVersion [topVer=143133203, order=1531653200157,
> nodeOrder=2, super=IgniteTxAdapter [xidVer=GridCacheVersion
> [topVer=143133203, order=1531653200157, nodeOrder=2], writeVer=null,
> implicit=false, loc=true, threadId=1947290, startTime=1531653200578,
> nodeId=1bf28b00-feed-412b-a20b-ca9fc111, startVer=GridCacheVersion
> [topVer=143133203, order=1531653200157, nodeOrder=2], endVer=null,
> isolation=REPEATABLE_READ, concurrency=PESSIMISTIC, timeout=0,
> sysInvalidate=false, sys=true, plc=2, commitVer=null, finalizing=NONE,
> invalidParts=null, state=ACTIVE, timedOut=false,
> topVer=AffinityTopologyVersion [topVer=7, minorTopVer=0], duration=20632ms,
> onePhaseCommit=false], size=1
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8924) [ML] Parameter Grid for tuning hyper-parameters in Cross-Validation process
[ https://issues.apache.org/jira/browse/IGNITE-8924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559645#comment-16559645 ] ASF GitHub Bot commented on IGNITE-8924: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4425 > [ML] Parameter Grid for tuning hyper-parameters in Cross-Validation process > --- > > Key: IGNITE-8924 > URL: https://issues.apache.org/jira/browse/IGNITE-8924 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Yury Babak >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.7 > > > We want to have an analogue of Parameter Grid from scikit-learn to tune > hyper-parameters in Cross-Validation process. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5037) Fix broken @AffinityKeyMapped annotation for compute jobs.
[ https://issues.apache.org/jira/browse/IGNITE-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559647#comment-16559647 ] Ihor Parashynets commented on IGNITE-5037: -- hi [~ezhuravl] If I may ask - is there a chance that you did some progress for this ticket? Many thanks in advance! > 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 >Assignee: Evgenii Zhuravlev >Priority: Major > Labels: newbie > > 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)
[jira] [Commented] (IGNITE-9089) Web Agent not starting in docker container.
[
https://issues.apache.org/jira/browse/IGNITE-9089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559652#comment-16559652
]
ASF GitHub Bot commented on IGNITE-9089:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4438
> Web Agent not starting in docker container.
> ---
>
> Key: IGNITE-9089
> URL: https://issues.apache.org/jira/browse/IGNITE-9089
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Ilya Murchenko
>Assignee: Peter Ivanov
>Priority: Minor
> Fix For: 2.7
>
>
> After a successful build from the Dockerfile in the [Github
> repository|https://github.com/apache/ignite/blob/master/docker/web-agent/Dockerfile]
> Web Agent application not starting in docker container with the following
> error:
>
> {code:java}
> /bin/sh: ignite-web-agent.sh: not found
> {code}
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-6259) GridServiceProcessor may leave futures hanging on unstable topology
[ https://issues.apache.org/jira/browse/IGNITE-6259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur reassigned IGNITE-6259: -- Assignee: Vyacheslav Daradur > GridServiceProcessor may leave futures hanging on unstable topology > --- > > Key: IGNITE-6259 > URL: https://issues.apache.org/jira/browse/IGNITE-6259 > Project: Ignite > Issue Type: Bug >Affects Versions: 1.7, 1.8, 1.9, 2.0, 2.1 >Reporter: Denis Mekhanikov >Assignee: Vyacheslav Daradur >Priority: Major > Fix For: 2.7 > > > GridServiceProcessor subscribes to updates on the internal cache to get > information about new deployments or cancellations of services. Some of such > updates may be lost under conditions of unstable topology. It leads to > services not being deployed and client futures infinitely hanging. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6259) GridServiceProcessor may leave futures hanging on unstable topology
[ https://issues.apache.org/jira/browse/IGNITE-6259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur updated IGNITE-6259: --- Fix Version/s: 2.7 > GridServiceProcessor may leave futures hanging on unstable topology > --- > > Key: IGNITE-6259 > URL: https://issues.apache.org/jira/browse/IGNITE-6259 > Project: Ignite > Issue Type: Bug >Affects Versions: 1.7, 1.8, 1.9, 2.0, 2.1 >Reporter: Denis Mekhanikov >Assignee: Vyacheslav Daradur >Priority: Major > Fix For: 2.7 > > > GridServiceProcessor subscribes to updates on the internal cache to get > information about new deployments or cancellations of services. Some of such > updates may be lost under conditions of unstable topology. It leads to > services not being deployed and client futures infinitely hanging. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8900) SqlFieldsQuery provides incorrect result when item size exceeds page size
[ https://issues.apache.org/jira/browse/IGNITE-8900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559655#comment-16559655 ] Ilya Lantukh commented on IGNITE-8900: -- [~agoncharuk], thanks for noticing it! Changes done in this ticket weren't the cause of these failures, they were fixed in https://issues.apache.org/jira/browse/IGNITE-8791. After I merged those changes, failures have stopped. > SqlFieldsQuery provides incorrect result when item size exceeds page size > - > > Key: IGNITE-8900 > URL: https://issues.apache.org/jira/browse/IGNITE-8900 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.4 >Reporter: Anton Kurbanov >Assignee: Ilya Lantukh >Priority: Blocker > Fix For: 2.7 > > Attachments: Main.java, Node.java > > > Start several server nodes, then start client, execute queries with value > range in where clause. Duplicate entries may be found, some entries may be > missing. > Results as an example: > expected 5 results but got back 3 results (query range 61002664327616 to > 610026643276160004), cache.getAll returned 5 entries. > expected 8 results but got back 7 results (query range 61002664327616 to > 610026643276160007), cache.getAll returned 8 entries. > Query results: [61002664327616, 610026643276160003, 610026643276160004, > 610026643276160005, 610026643276160005, 610026643276160006, > 610026643276160007] > Please find reproducer attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8981) [ML] Parallel optimizations for BaggingTrainer
[ https://issues.apache.org/jira/browse/IGNITE-8981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559660#comment-16559660 ] Yury Babak commented on IGNITE-8981: reviewed and merged > [ML] Parallel optimizations for BaggingTrainer > --- > > Key: IGNITE-8981 > URL: https://issues.apache.org/jira/browse/IGNITE-8981 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Yury Babak >Assignee: Alexey Platonov >Priority: Major > Fix For: 2.7 > > > We could improve performance of BaggingTrainer using parallel optimizations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9107) FINE log level causes slow transactional cache
Greg Bakos created IGNITE-9107: -- Summary: FINE log level causes slow transactional cache Key: IGNITE-9107 URL: https://issues.apache.org/jira/browse/IGNITE-9107 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.6, 2.4 Environment: Docker Hub Image with 2.4.0 and 2.6.0 versions. Reporter: Greg Bakos java.util.logging.properties file's org.apache.ignite.level=FINE setting causes slow transactional putAll call. Cache config: || || || || || || || || || || || -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8009) SQL local query to a cache with queryParallelism>1 doesn't use index
[ https://issues.apache.org/jira/browse/IGNITE-8009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559670#comment-16559670 ] Vladimir Ozerov commented on IGNITE-8009: - [~amashenkov], [~pvinokurov], Join order is enforced for map part of all two-step queries. There is nothing wrong with parallelism here. If you get this result with parallelism, you will get the same result without it when there are several nodes. > SQL local query to a cache with queryParallelism>1 doesn't use index > - > > Key: IGNITE-8009 > URL: https://issues.apache.org/jira/browse/IGNITE-8009 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.3, 2.4 >Reporter: Pavel Vinokurov >Priority: Major > Attachments: ExplainAndIndexReproducer.java > > > queryParallelism>1 + setLocal(true) changes the query plan and exclude usage > of the sql index. > Explain query with setLocal(false) and queryParallelism=1 : > SELECT > T__Z0.ID AS __C0_0 > FROM TABLE(COL VARCHAR='name0') I__Z1 > /* function */ > INNER JOIN PUBLIC.PERSON T__Z0 > /* PUBLIC.PERSON_NAME: NAME = I__Z1.COL */ > ON 1=1 > WHERE (T__Z0.SOURNAME = 'sourname0') > AND (T__Z0.NAME = I__Z1.COL) > Explain query with setLocal(true) and queryParallelism=2 : > SELECT > T__Z1.ID AS __C0_0 > FROM PUBLIC.PERSON T__Z1 > /* PUBLIC.PERSON.__SCAN_ */ > /* WHERE T__Z1.SOURNAME = 'sourname0' > */ > INNER JOIN TABLE(COL VARCHAR='name0') I__Z0 > /* function: COL = T__Z1.NAME */ > ON 1=1 > WHERE (T__Z1.SOURNAME = 'sourname0') > AND (T__Z1.NAME = I__Z0.COL) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9107) FINE log level causes slow transactional cache
[
https://issues.apache.org/jira/browse/IGNITE-9107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Bakos updated IGNITE-9107:
---
Description:
java.util.logging.properties file's org.apache.ignite.level=FINE setting causes
slow transactional putAll call.
Cache config:
{code:java}
{code}
was:
java.util.logging.properties file's org.apache.ignite.level=FINE setting causes
slow transactional putAll call.
Cache config:
{code:java}
{code}
> FINE log level causes slow transactional cache
> --
>
> Key: IGNITE-9107
> URL: https://issues.apache.org/jira/browse/IGNITE-9107
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.4, 2.6
> Environment: Docker Hub Image with 2.4.0 and 2.6.0 versions.
>Reporter: Greg Bakos
>Priority: Major
>
> java.util.logging.properties file's org.apache.ignite.level=FINE setting
> causes slow transactional putAll call.
> Cache config:
> {code:java}
>
>
>
>
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9107) FINE log level causes slow transactional cache
[
https://issues.apache.org/jira/browse/IGNITE-9107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Bakos updated IGNITE-9107:
---
Description:
java.util.logging.properties file's org.apache.ignite.level=FINE setting causes
slow transactional putAll call.
Cache config:
{code:java}
{code}
was:
java.util.logging.properties file's org.apache.ignite.level=FINE setting causes
slow transactional putAll call.
Cache config:
||
||
||
||
||
||
||
||
||
||
||
> FINE log level causes slow transactional cache
> --
>
> Key: IGNITE-9107
> URL: https://issues.apache.org/jira/browse/IGNITE-9107
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.4, 2.6
> Environment: Docker Hub Image with 2.4.0 and 2.6.0 versions.
>Reporter: Greg Bakos
>Priority: Major
>
> java.util.logging.properties file's org.apache.ignite.level=FINE setting
> causes slow transactional putAll call.
> Cache config:
> {code:java}
>
>
>
>
>
>
>
>
>
>
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9073) Ignite modules should use jackson2 dependency rater then jackson1
[ https://issues.apache.org/jira/browse/IGNITE-9073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559692#comment-16559692 ] ASF GitHub Bot commented on IGNITE-9073: GitHub user zzzadruga opened a pull request: https://github.com/apache/ignite/pull/ IGNITE-9073 Use jackson2 dependency instead of jackson1 and remove un… …used dependencies You can merge this pull request into a Git repository by running: $ git pull https://github.com/zzzadruga/ignite IGNITE-9073 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes # commit 12153ab22a05c815872f529adb4c6f76d45caec6 Author: zzzadruga Date: 2018-07-27T12:08:43Z IGNITE-9073 Use jackson2 dependency instead of jackson1 and remove unused dependencies > Ignite modules should use jackson2 dependency rater then jackson1 > - > > Key: IGNITE-9073 > URL: https://issues.apache.org/jira/browse/IGNITE-9073 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Garus >Assignee: Nikolai kulagin >Priority: Major > Fix For: 2.7 > > > Ignite modules should use jackson2 dependency rater then jackson1. > It is required to run RunAll to check all tests passed, check full build > locally using build.sh. > Probably it is required to run release step to make sure release candidate > can be prepared -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7701) SQL system view for node attributes
[ https://issues.apache.org/jira/browse/IGNITE-7701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559703#comment-16559703 ] ASF GitHub Bot commented on IGNITE-7701: GitHub user alex-plekhanov opened a pull request: https://github.com/apache/ignite/pull/4445 IGNITE-7701 SQL system view for node attributes You can merge this pull request into a Git repository by running: $ git pull https://github.com/alex-plekhanov/ignite ignite-7701 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4445.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4445 commit 2884364ef68855217f96be2e5d9fd362722ca99e Author: Aleksey Plekhanov Date: 2018-07-27T12:25:37Z IGNITE-7701 SQL system view for node attributes > SQL system view for node attributes > --- > > Key: IGNITE-7701 > URL: https://issues.apache.org/jira/browse/IGNITE-7701 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-13, sql > Fix For: 2.7 > > > Implement SQL system view to show attributes for each node in topology. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9100) Split Basic and Cache TC configurations on pure in-memory and with disk usage one
[ https://issues.apache.org/jira/browse/IGNITE-9100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559718#comment-16559718 ] Alexey Stelmak commented on IGNITE-9100: Looks good for me :) > Split Basic and Cache TC configurations on pure in-memory and with disk usage > one > - > > Key: IGNITE-9100 > URL: https://issues.apache.org/jira/browse/IGNITE-9100 > Project: Ignite > Issue Type: Improvement >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-3499) GridCacheReplicatedFullApiMultithreadedSelfTest1 is commented
[ https://issues.apache.org/jira/browse/IGNITE-3499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-3499: --- Fix Version/s: 2.7 > GridCacheReplicatedFullApiMultithreadedSelfTest1 is commented > - > > Key: IGNITE-3499 > URL: https://issues.apache.org/jira/browse/IGNITE-3499 > Project: Ignite > Issue Type: Test > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexey Goncharuk >Assignee: Maxim Muzafarov >Priority: Major > Labels: newbie > Fix For: 2.7 > > > The whole body of GridCacheReplicatedFullApiMultithreadedSelfTest1 is > commented out. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-3499) GridCacheReplicatedFullApiMultithreadedSelfTest1 is commented
[ https://issues.apache.org/jira/browse/IGNITE-3499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559727#comment-16559727 ] ASF GitHub Bot commented on IGNITE-3499: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4443 > GridCacheReplicatedFullApiMultithreadedSelfTest1 is commented > - > > Key: IGNITE-3499 > URL: https://issues.apache.org/jira/browse/IGNITE-3499 > Project: Ignite > Issue Type: Test > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexey Goncharuk >Assignee: Maxim Muzafarov >Priority: Major > Labels: newbie > Fix For: 2.7 > > > The whole body of GridCacheReplicatedFullApiMultithreadedSelfTest1 is > commented out. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9108) Spark DataFrames With Cache Key and Value Objects
Stuart Macdonald created IGNITE-9108:
Summary: Spark DataFrames With Cache Key and Value Objects
Key: IGNITE-9108
URL: https://issues.apache.org/jira/browse/IGNITE-9108
Project: Ignite
Issue Type: New Feature
Components: spark
Reporter: Stuart Macdonald
Add support for _key and _val columns within Ignite-provided Spark DataFrames,
which represent the cache key and value objects similar to the current
_key/_val column semantics in Ignite SQL.
If the cache key or value objects are standard SQL types (eg. String, Int, etc)
they will be represented as such in the DataFrame schema, otherwise they are
represented as Binary types encoded as either: 1. Ignite BinaryObjects, in
which case we'd need to supply a Spark Encoder implementation for
BinaryObjects, eg:
{code:java}
IgniteSparkSession session = ...
Dataset dataFrame = ...
Dataset valDataSet =
dataFrame.select("_val_).as(session.binaryObjectEncoder(MyValClass.class))
{code}
Or 2. Kryo-serialised versions of the objects, eg:
{code:java}
Dataset dataFrame = ...
DataSet dataSet =
dataFrame.select("_val_).as(Encoders.kryo(MyValClass.class))
{code}
Option 1 would probably be more efficient but option 2 would be more idiomatic
Spark.
The rationale behind this is the same as the Ignite SQL _key and _val columns:
to allow access to the full cache objects from a SQL context.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-5103) TcpDiscoverySpi ignores maxMissedClientHeartbeats property
[
https://issues.apache.org/jira/browse/IGNITE-5103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgenii Zhuravlev reassigned IGNITE-5103:
-
Assignee: Evgenii Zhuravlev
> TcpDiscoverySpi ignores maxMissedClientHeartbeats property
> --
>
> Key: IGNITE-5103
> URL: https://issues.apache.org/jira/browse/IGNITE-5103
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.9
>Reporter: Valentin Kulichenko
>Assignee: Evgenii Zhuravlev
>Priority: Major
> Fix For: 2.7
>
> Attachments: TcpDiscoveryClientSuspensionSelfTest.java
>
>
> Test scenario is the following:
> * Start one or more servers.
> * Start a client node.
> * Suspend client process using {{-SIGSTOP}} signal.
> * Wait for {{maxMissedClientHeartbeats*heartbeatFrequency}}.
> * Client node is expected to be removed from topology, but server nodes don't
> do that.
> Attached is the unit test reproducing the same by stopping the heartbeat
> sender thread on the client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9044) Update scala dependency version in Apache Ignite
[ https://issues.apache.org/jira/browse/IGNITE-9044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559785#comment-16559785 ] Nikolai kulagin commented on IGNITE-9044: - [~dpavlov], good idea. I will do it > Update scala dependency version in Apache Ignite > > > Key: IGNITE-9044 > URL: https://issues.apache.org/jira/browse/IGNITE-9044 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitriy Pavlov >Assignee: Nikolai kulagin >Priority: Major > Fix For: 2.7 > > > *ignite-scalar* > scala.library.version=2.11.8, need to be at least 2.11.12 or newer. > *ignite-scalar_2.10* > scala210.library.version 2.10.6, need to be at least 2.10.7, probably newer > *visor 2.10* > scala210.jline.version = 2.10.4 , need to be at least 2.10.7, probably newer > Probably impact would be wider. > We need at least run run-all, local build.sh and optionally release candate > step on TC. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5510) AssertionError: null instead of GridCacheReturnCompletableWrapper
[
https://issues.apache.org/jira/browse/IGNITE-5510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559788#comment-16559788
]
Semen Boikov commented on IGNITE-5510:
--
I think assert in IgniteTxManager.removeTxReturn is not correct. First, it is
possible that removeTxReturn can be called concurrently from
processDhtTxOnePhaseCommitAckRequest and from node left handler. In this test
it fails since sometimes tx does not start on backup since partition is already
evicted when prepare request is processed (cache with 0 backups).
> AssertionError: null instead of GridCacheReturnCompletableWrapper
> -
>
> Key: IGNITE-5510
> URL: https://issues.apache.org/jira/browse/IGNITE-5510
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Vladimir Ozerov
>Assignee: Semen Boikov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, test-fail
>
> Reproducer: {{CacheLateAffinityAssignmentTest#testNoForceKeysRequests}}
> Sample log:
> http://ci.ignite.apache.org/viewLog.html?buildId=666034&tab=buildResultsDiv&buildTypeId=Ignite20Tests_IgniteCache5
> Stack trace:
> {code}
> java.lang.AssertionError: null instead of GridCacheReturnCompletableWrapper
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.removeTxReturn(IgniteTxManager.java:1040)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxOnePhaseCommitAckRequest(IgniteTxHandler.java:1070)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$700(IgniteTxHandler.java:95)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$8.apply(IgniteTxHandler.java:183)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$8.apply(IgniteTxHandler.java:181)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1032)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:553)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:371)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:301)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:104)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:291)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1554)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1182)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:124)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1095)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:483)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-5103) TcpDiscoverySpi ignores maxMissedClientHeartbeats property
[
https://issues.apache.org/jira/browse/IGNITE-5103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559801#comment-16559801
]
ASF GitHub Bot commented on IGNITE-5103:
GitHub user ezhuravl opened a pull request:
https://github.com/apache/ignite/pull/4446
IGNITE-5103 - Server drops client node from cluster when no metrics u…
…pdate messages received in clienFailureDetectionTimeout
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-5103
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4446.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4446
commit 63733ec7ce2875bf92a473534506ee0d354346ba
Author: ezhuravl
Date: 2018-07-27T13:51:04Z
IGNITE-5103 - Server drops client node from cluster when no metrics update
messages received in clienFailureDetectionTimeout
> TcpDiscoverySpi ignores maxMissedClientHeartbeats property
> --
>
> Key: IGNITE-5103
> URL: https://issues.apache.org/jira/browse/IGNITE-5103
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.9
>Reporter: Valentin Kulichenko
>Assignee: Evgenii Zhuravlev
>Priority: Major
> Fix For: 2.7
>
> Attachments: TcpDiscoveryClientSuspensionSelfTest.java
>
>
> Test scenario is the following:
> * Start one or more servers.
> * Start a client node.
> * Suspend client process using {{-SIGSTOP}} signal.
> * Wait for {{maxMissedClientHeartbeats*heartbeatFrequency}}.
> * Client node is expected to be removed from topology, but server nodes don't
> do that.
> Attached is the unit test reproducing the same by stopping the heartbeat
> sender thread on the client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9058) Update Apache Tomcat dependency version
[
https://issues.apache.org/jira/browse/IGNITE-9058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559830#comment-16559830
]
ASF GitHub Bot commented on IGNITE-9058:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4435
> Update Apache Tomcat dependency version
> ---
>
> Key: IGNITE-9058
> URL: https://issues.apache.org/jira/browse/IGNITE-9058
> Project: Ignite
> Issue Type: Improvement
>Reporter: Dmitriy Pavlov
>Assignee: Ivan Fedotov
>Priority: Major
> Fix For: 2.7
>
>
> Update tomcat-servlet-api to newer version (at least 8.0.52, 8.5.31+ or
> 9.0.9+). E.g. to
> {noformat}
>
> org.apache.tomcat
> tomcat-servlet-api
> 9.0.10
>
> {noformat}
> At least Ignite-rest-http, ignite-urideploy, and ignite-web will be affected
> by this change.
> It is required to run TC tartget RunAll to check all tests passed, it is
> required to build fabric using DEVNOTES.txt to make sure full build will be
> successfull
> Probably it is required to run release step to make sure release candidate
> can be prepared.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-6888) Cache involved tables set for statement
[
https://issues.apache.org/jira/browse/IGNITE-6888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin resolved IGNITE-6888.
Resolution: Fixed
> Cache involved tables set for statement
> ---
>
> Key: IGNITE-6888
> URL: https://issues.apache.org/jira/browse/IGNITE-6888
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Igor Seliverstov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.7
>
>
> Currently we have to create AST from {{PreparedStatement}} to collect and
> process all involved
> in the query caches (See {{IgniteH2Indexing#mvccTracker}}). It makes sense
> to cache parse results per statements by analogy with statements itself.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9043) Collections cannot be assigned to fields of type Object in BinaryObject
[
https://issues.apache.org/jira/browse/IGNITE-9043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559839#comment-16559839
]
ASF GitHub Bot commented on IGNITE-9043:
GitHub user dmekhanikov opened a pull request:
https://github.com/apache/ignite/pull/4447
IGNITE-9043 let values of any type be written to Object field
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite IGNITE-9043
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4447.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4447
commit 734f56495292d6cbaff34c73f5d6593432e78ee3
Author: Denis Mekhanikov
Date: 2018-07-27T14:27:41Z
IGNITE-9043 let values of any type be written to Object field
> Collections cannot be assigned to fields of type Object in BinaryObject
> ---
>
> Key: IGNITE-9043
> URL: https://issues.apache.org/jira/browse/IGNITE-9043
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.6
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Labels: usability
> Fix For: 2.7
>
>
> When a binary type is registered during first insertion without use of
> BinaryObject, then fields of type {{Map}} are registered as {{Object}}-s.
> But if you try to assign a {{HashMap}} to this field afterwards, then
> exception is thrown.
> The following code results in an exception:
> {code:java}
> public static void main(String[] args) {
> Ignite ignite = Ignition.start("config/ignite.xml");
> IgniteCache cache =
> ignite.getOrCreateCache("cache");
> cache.put(1, new ExamplePojo());
> BinaryObject val = cache.withKeepBinary().get(1);
> Map map = val.field("map");
> BinaryObjectBuilder bldr = val.toBuilder();
> bldr.setField("map", map);
> bldr.build(); // Throws exception.
> }
> static class ExamplePojo {
> Map map = new HashMap<>();
> }
> {code}
> Stacktrace:
> {noformat}
> Exception in thread "main" class
> org.apache.ignite.binary.BinaryObjectException: Wrong value has been set
> [typeName=binary.BinaryObjectMapExample$ExamplePojo, fieldName=map,
> fieldType=Object, assignedValueType=Map]
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.checkMetadata(BinaryObjectBuilderImpl.java:428)
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:223)
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.build(BinaryObjectBuilderImpl.java:183)
> at binary.BinaryObjectMapExample.main(BinaryObjectMapExample.java:26)
> {noformat}
> It would be convenient, if objects of any type could be written as {{Object}}
> without the need to specify the type explicitly in
> {{BinaryObjectBuilder.setField(...)}} method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8936) Remove AffinityAssignment#clientEventChange as not used
[ https://issues.apache.org/jira/browse/IGNITE-8936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559850#comment-16559850 ] ASF GitHub Bot commented on IGNITE-8936: GitHub user zzzadruga opened a pull request: https://github.com/apache/ignite/pull/4448 IGNITE-8936 Remove AffinityAssignment#clientEventChange as not used You can merge this pull request into a Git repository by running: $ git pull https://github.com/zzzadruga/ignite IGNITE-8936 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4448.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4448 commit 4dd3609b5d21a88f1645f993faa84351110e62fd Author: zzzadruga Date: 2018-07-26T12:33:38Z IGNITE-8936 Remove AffinityAssignment#clientEventChange as not used > Remove AffinityAssignment#clientEventChange as not used > --- > > Key: IGNITE-8936 > URL: https://issues.apache.org/jira/browse/IGNITE-8936 > Project: Ignite > Issue Type: Task >Affects Versions: 2.7 >Reporter: Maxim Muzafarov >Assignee: Nikolai kulagin >Priority: Minor > Labels: newbie > Attachments: ClientEventChange (1).png > > > We should try to keep Ignite project code as simple as possible. > Motivation: > http://apache-ignite-developers.2346864.n4.nabble.com/Cases-of-using-AffinityAssignment-clientEventChange-method-td32068.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8559) WAL rollOver can be blocked by WAL iterator reservation
[
https://issues.apache.org/jira/browse/IGNITE-8559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559865#comment-16559865
]
ASF GitHub Bot commented on IGNITE-8559:
GitHub user akalash opened a pull request:
https://github.com/apache/ignite/pull/4449
IGNITE-8559 extract segment index storage to out of WAL manager
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-8559
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4449.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4449
commit daf4b1e97db3b82017b03042623babe94dd00ee3
Author: Anton Kalashnikov
Date: 2018-07-27T14:22:42Z
IGNITE-8559 extract segment index storage to out of WAL manager
> WAL rollOver can be blocked by WAL iterator reservation
> ---
>
> Key: IGNITE-8559
> URL: https://issues.apache.org/jira/browse/IGNITE-8559
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Anton Kalashnikov
>Priority: Critical
> Fix For: 2.7
>
>
> I've got the following thread dump from one of the Ignite nodes (only
> meaningful threads are kept for simplicity)
> WAL archiver is waiting for locked segment release
> TX commit is waiting for WAL rollover
> WAL rollover is blocked by the archiver
> Exchange is blocked by TX commit
> {code}
> "sys-stripe-55-#56%GRID%GridNodeName%" #246 daemon prio=5 os_prio=0
> tid=0x7fdd1eeff000 nid=0x164252 waiting on condition [0x7fdb36eec000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x7fe0a5e96278> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitUninterruptibly(AbstractQueuedSynchronizer.java:1976)
> at
> org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:7400)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.awaitNext(FileWriteAheadLogManager.java:2819)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.access$2900(FileWriteAheadLogManager.java:2390)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.rollOver(FileWriteAheadLogManager.java:1065)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.log(FileWriteAheadLogManager.java:715)
> at
> org.gridgain.grid.internal.processors.cache.database.snapshot.GridCacheSnapshotManager.onChangeTrackerPage(GridCacheSnapshotManager.java:2436)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$9.applyx(GridCacheDatabaseSharedManager.java:942)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$9.applyx(GridCacheDatabaseSharedManager.java:935)
> at
> org.apache.ignite.internal.util.lang.GridInClosure3X.apply(GridInClosure3X.java:34)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.writeUnlockPage(PageMemoryImpl.java:1341)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.writeUnlock(PageMemoryImpl.java:415)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.writeUnlock(PageMemoryImpl.java:409)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writeUnlock(PageHandler.java:377)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writePage(PageHandler.java:287)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.write(DataStructure.java:282)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.insertDataRow(AbstractFreeList.java:509)
> at
> org.apache.ignite.internal.processors.cache.persistence.RowStore.addRow(RowStore.java:102)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.createRow(IgniteCacheOffheapManagerImpl.java:1252)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.createRow(GridCacheOffheapManager.java:1370)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntr
[jira] [Created] (IGNITE-9109) CPP Thin: Implement SQL API
Igor Sapego created IGNITE-9109: --- Summary: CPP Thin: Implement SQL API Key: IGNITE-9109 URL: https://issues.apache.org/jira/browse/IGNITE-9109 Project: Ignite Issue Type: New Feature Components: platforms Affects Versions: 2.6 Reporter: Igor Sapego Need to implement SQL API for C++ thin client. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9110) Tx commit hangs after cross-cache operations with LOCAL cache
Ryabov Dmitrii created IGNITE-9110:
--
Summary: Tx commit hangs after cross-cache operations with LOCAL
cache
Key: IGNITE-9110
URL: https://issues.apache.org/jira/browse/IGNITE-9110
Project: Ignite
Issue Type: Task
Components: cache
Reporter: Ryabov Dmitrii
Commit hangs when tx contains operations on LOCAL and PARTITIONED or REPLICATED
caches in some cases. Example:
{code:java}
public class LocalCacheFails extends GridCommonAbstractTest {
/** */
public void testLocalCache() throws Exception {
IgniteEx ignite = startGrid(0);
IgniteCache locCache =
ignite.createCache(getConfig(LOCAL));
IgniteCache partCache =
ignite.createCache(getConfig(PARTITIONED));
try (Transaction tx = ignite.transactions().txStart(OPTIMISTIC,
SERIALIZABLE)) {
locCache.put(1, 1);
partCache.put(1, 1);
tx.commit(); // Fails here.
}
}
/** */
private CacheConfiguration getConfig(CacheMode cacheMode)
{
CacheConfiguration cfg = new CacheConfiguration<>();
cfg.setCacheMode(cacheMode);
cfg.setName(cacheMode.name());
cfg.setAtomicityMode(TRANSACTIONAL);
return cfg;
}
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9110) Tx commit hangs after cross-cache operations with LOCAL cache
[
https://issues.apache.org/jira/browse/IGNITE-9110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryabov Dmitrii updated IGNITE-9110:
---
Description:
Commit hangs when tx contains operations on LOCAL and PARTITIONED or REPLICATED
caches in some cases. Example:
{code:java}
public class LocalCacheFails extends GridCommonAbstractTest {
/** */
public void testLocalCache() throws Exception {
IgniteEx ignite = startGrid(0);
IgniteCache locCache =
ignite.createCache(getConfig(LOCAL));
IgniteCache partCache =
ignite.createCache(getConfig(PARTITIONED));
try (Transaction tx = ignite.transactions().txStart(OPTIMISTIC,
SERIALIZABLE)) {
locCache.put(1, 1);
partCache.put(1, 1);
tx.commit(); // Fails here.
}
}
/** */
private CacheConfiguration getConfig(CacheMode cacheMode)
{
CacheConfiguration cfg = new CacheConfiguration<>();
cfg.setCacheMode(cacheMode);
cfg.setName(cacheMode.name());
cfg.setAtomicityMode(TRANSACTIONAL);
return cfg;
}
}
{code}
Stacktrace here:
{code:java}
[18:05:44] (err) Failed to execute compound future reducer:
GridNearTxFinishFuture [futId=ff3264cd461-707c41df-7a8c-4067-8367-5d941df0aec1,
tx=GridNearTxLocal [mappings=IgniteTxMappingsImpl [], nearLocallyMapped=false,
colocatedLocallyMapped=true, needCheckBackup=null, hasRemoteLocks=false,
trackTimeout=false, lb=null,
thread=test-runner-#1%transactions.LocalCacheFails%,
mappings=IgniteTxMappingsImpl [], super=GridDhtTxLocalAdapter
[nearOnOriginatingNode=false, nearNodes=[], dhtNodes=[], explicitLock=false,
super=IgniteTxLocalAdapter [completedBase=null, sndTransformedVals=false,
depEnabled=false, txState=IgniteTxStateImpl
[activeCacheIds=[72607563,-887906071], recovery=false, txMap=[IgniteTxEntry
[key=KeyCacheObjectImpl [part=0, val=1, hasValBytes=true], cacheId=72607563,
txKey=IgniteTxKey [key=KeyCacheObjectImpl [part=0, val=1, hasValBytes=true],
cacheId=72607563], val=[op=CREATE, val=UserCacheObjectImpl [val=1,
hasValBytes=true]], prevVal=[op=CREATE, val=UserCacheObjectImpl [val=1,
hasValBytes=true]], oldVal=[op=NOOP, val=null], entryProcessorsCol=null,
ttl=-1, conflictExpireTime=-1, conflictVer=null, explicitVer=null, dhtVer=null,
filters=[], filtersPassed=false, filtersSet=true, entry=GridLocalCacheEntry
[super=GridCacheMapEntry [key=KeyCacheObjectImpl [part=0, val=1,
hasValBytes=true], val=CacheObjectImpl [val=null, hasValBytes=true],
ver=GridCacheVersion [topVer=144183944, order=1532703942007, nodeOrder=1],
hash=1, extras=null, flags=2]], prepared=1, locked=false,
nodeId=1068e98c-9c17-4fee-967b-8270, locMapped=false, expiryPlc=null,
transferExpiryPlc=false, flags=0, partUpdateCntr=0, serReadVer=null,
xidVer=GridCacheVersion [topVer=144183944, order=1532703942006, nodeOrder=1]],
IgniteTxEntry [key=KeyCacheObjectImpl [part=1, val=1, hasValBytes=true],
cacheId=-887906071, txKey=IgniteTxKey [key=KeyCacheObjectImpl [part=1, val=1,
hasValBytes=true], cacheId=-887906071], val=[op=CREATE, val=UserCacheObjectImpl
[val=1, hasValBytes=true]], prevVal=[op=CREATE, val=UserCacheObjectImpl [val=1,
hasValBytes=true]], oldVal=[op=NOOP, val=null], entryProcessorsCol=null,
ttl=-1, conflictExpireTime=-1, conflictVer=null, explicitVer=null, dhtVer=null,
filters=[], filtersPassed=false, filtersSet=true, entry=GridDhtCacheEntry
[rdrs=[], part=1, super=GridDistributedCacheEntry [super=GridCacheMapEntry
[key=KeyCacheObjectImpl [part=1, val=1, hasValBytes=true], val=CacheObjectImpl
[val=null, hasValBytes=true], ver=GridCacheVersion [topVer=144183944,
order=1532703942007, nodeOrder=1], hash=1, extras=GridCacheMvccEntryExtras
[mvcc=GridCacheMvcc [locs=[GridCacheMvccCandidate
[nodeId=1068e98c-9c17-4fee-967b-8270, ver=GridCacheVersion
[topVer=144183944, order=1532703942006, nodeOrder=1], threadId=14, id=2,
topVer=AffinityTopologyVersion [topVer=1, minorTopVer=2], reentry=null,
otherNodeId=1068e98c-9c17-4fee-967b-8270, otherVer=GridCacheVersion
[topVer=144183944, order=1532703942006, nodeOrder=1], mappedDhtNodes=null,
mappedNearNodes=null, ownerVer=null, serOrder=GridCacheVersion
[topVer=144183944, order=1532703942006, nodeOrder=1], key=KeyCacheObjectImpl
[part=1, val=1, hasValBytes=true],
masks=local=1|owner=1|ready=1|reentry=0|used=0|tx=1|single_implicit=0|dht_local=1|near_local=0|removed=0|read=0,
prevVer=GridCacheVersion [topVer=144183944, order=1532703942006, nodeOrder=1],
nextVer=null]], rmts=null]], flags=2]]], prepared=1, locked=false,
nodeId=1068e98c-9c17-4fee-967b-8270, locMapped=false, expiryPlc=null,
transferExpiryPlc=false, flags=0, partUpdateCntr=1, serReadVer=null,
xidVer=GridCacheVersion [topVer=144183944, order=1532703942006,
nodeOrder=1, super=IgniteTxAdapter [xidVer=GridCacheVersion
[topVer=144183944, order=1532703942006, nodeOrder=1], writeVer=GridC
[jira] [Updated] (IGNITE-9110) Tx commit hangs after cross-cache operations with LOCAL cache
[
https://issues.apache.org/jira/browse/IGNITE-9110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryabov Dmitrii updated IGNITE-9110:
---
Issue Type: Bug (was: Task)
> Tx commit hangs after cross-cache operations with LOCAL cache
> -
>
> Key: IGNITE-9110
> URL: https://issues.apache.org/jira/browse/IGNITE-9110
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Ryabov Dmitrii
>Priority: Minor
>
> Commit hangs when tx contains operations on LOCAL and PARTITIONED or
> REPLICATED caches in some cases. Example:
> {code:java}
> public class LocalCacheFails extends GridCommonAbstractTest {
> /** */
> public void testLocalCache() throws Exception {
> IgniteEx ignite = startGrid(0);
> IgniteCache locCache =
> ignite.createCache(getConfig(LOCAL));
> IgniteCache partCache =
> ignite.createCache(getConfig(PARTITIONED));
> try (Transaction tx = ignite.transactions().txStart(OPTIMISTIC,
> SERIALIZABLE)) {
> locCache.put(1, 1);
> partCache.put(1, 1);
> tx.commit(); // Fails here.
> }
> }
> /** */
> private CacheConfiguration getConfig(CacheMode
> cacheMode) {
> CacheConfiguration cfg = new CacheConfiguration<>();
> cfg.setCacheMode(cacheMode);
> cfg.setName(cacheMode.name());
> cfg.setAtomicityMode(TRANSACTIONAL);
> return cfg;
> }
> }
> {code}
> Stacktrace here:
> {code:java}
> [18:05:44] (err) Failed to execute compound future reducer:
> GridNearTxFinishFuture
> [futId=ff3264cd461-707c41df-7a8c-4067-8367-5d941df0aec1, tx=GridNearTxLocal
> [mappings=IgniteTxMappingsImpl [], nearLocallyMapped=false,
> colocatedLocallyMapped=true, needCheckBackup=null, hasRemoteLocks=false,
> trackTimeout=false, lb=null,
> thread=test-runner-#1%transactions.LocalCacheFails%,
> mappings=IgniteTxMappingsImpl [], super=GridDhtTxLocalAdapter
> [nearOnOriginatingNode=false, nearNodes=[], dhtNodes=[], explicitLock=false,
> super=IgniteTxLocalAdapter [completedBase=null, sndTransformedVals=false,
> depEnabled=false, txState=IgniteTxStateImpl
> [activeCacheIds=[72607563,-887906071], recovery=false, txMap=[IgniteTxEntry
> [key=KeyCacheObjectImpl [part=0, val=1, hasValBytes=true], cacheId=72607563,
> txKey=IgniteTxKey [key=KeyCacheObjectImpl [part=0, val=1, hasValBytes=true],
> cacheId=72607563], val=[op=CREATE, val=UserCacheObjectImpl [val=1,
> hasValBytes=true]], prevVal=[op=CREATE, val=UserCacheObjectImpl [val=1,
> hasValBytes=true]], oldVal=[op=NOOP, val=null], entryProcessorsCol=null,
> ttl=-1, conflictExpireTime=-1, conflictVer=null, explicitVer=null,
> dhtVer=null, filters=[], filtersPassed=false, filtersSet=true,
> entry=GridLocalCacheEntry [super=GridCacheMapEntry [key=KeyCacheObjectImpl
> [part=0, val=1, hasValBytes=true], val=CacheObjectImpl [val=null,
> hasValBytes=true], ver=GridCacheVersion [topVer=144183944,
> order=1532703942007, nodeOrder=1], hash=1, extras=null, flags=2]],
> prepared=1, locked=false, nodeId=1068e98c-9c17-4fee-967b-8270,
> locMapped=false, expiryPlc=null, transferExpiryPlc=false, flags=0,
> partUpdateCntr=0, serReadVer=null, xidVer=GridCacheVersion [topVer=144183944,
> order=1532703942006, nodeOrder=1]], IgniteTxEntry [key=KeyCacheObjectImpl
> [part=1, val=1, hasValBytes=true], cacheId=-887906071, txKey=IgniteTxKey
> [key=KeyCacheObjectImpl [part=1, val=1, hasValBytes=true],
> cacheId=-887906071], val=[op=CREATE, val=UserCacheObjectImpl [val=1,
> hasValBytes=true]], prevVal=[op=CREATE, val=UserCacheObjectImpl [val=1,
> hasValBytes=true]], oldVal=[op=NOOP, val=null], entryProcessorsCol=null,
> ttl=-1, conflictExpireTime=-1, conflictVer=null, explicitVer=null,
> dhtVer=null, filters=[], filtersPassed=false, filtersSet=true,
> entry=GridDhtCacheEntry [rdrs=[], part=1, super=GridDistributedCacheEntry
> [super=GridCacheMapEntry [key=KeyCacheObjectImpl [part=1, val=1,
> hasValBytes=true], val=CacheObjectImpl [val=null, hasValBytes=true],
> ver=GridCacheVersion [topVer=144183944, order=1532703942007, nodeOrder=1],
> hash=1, extras=GridCacheMvccEntryExtras [mvcc=GridCacheMvcc
> [locs=[GridCacheMvccCandidate [nodeId=1068e98c-9c17-4fee-967b-8270,
> ver=GridCacheVersion [topVer=144183944, order=1532703942006, nodeOrder=1],
> threadId=14, id=2, topVer=AffinityTopologyVersion [topVer=1, minorTopVer=2],
> reentry=null, otherNodeId=1068e98c-9c17-4fee-967b-8270,
> otherVer=GridCacheVersion [topVer=144183944, order=1532703942006,
> nodeOrder=1], mappedDhtNodes=null, mappedNearNodes=null, ownerVer=null,
> serOrder=GridCacheVersion [topVer=144183944, order=1532703942006,
> nodeOrder=1], key=KeyCacheObjectImpl [part=1, val=1, hasValBytes=true],
> masks=local=1|owner=1|ready=1|reentry=0|used=0|tx
[jira] [Commented] (IGNITE-4380) Cache invoke calls can be lost
[
https://issues.apache.org/jira/browse/IGNITE-4380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559945#comment-16559945
]
Vitaliy Biryukov commented on IGNITE-4380:
--
[~Alexey Kuznetsov], LGYM.
> Cache invoke calls can be lost
> --
>
> Key: IGNITE-4380
> URL: https://issues.apache.org/jira/browse/IGNITE-4380
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.0
>Reporter: Semen Boikov
>Assignee: Alexey Kuznetsov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
>
> * Recently added test
> GridCacheAbstractFullApiSelfTest.testInvokeAllMultithreaded fails on TC in
> various configurations with transactional cache.
> Example of failure
> GridCacheReplicatedOffHeapTieredMultiNodeFullApiSelfTest.testInvokeAllMultithreaded:
> {noformat}
> junit.framework.AssertionFailedError: expected:<2> but was:<10868>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.Assert.assertEquals(Assert.java:241)
> at junit.framework.TestCase.assertEquals(TestCase.java:409)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAbstractFullApiSelfTest.testInvokeAllMultithreaded(GridCacheAbstractFullApiSelfTest.java:342)
> at sun.reflect.GeneratedMethodAccessor96.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1803)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1718)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-1260) S3 IP finder should have an option to use a subfolder instead of bucket root
[ https://issues.apache.org/jira/browse/IGNITE-1260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559962#comment-16559962 ] Dmitriy Pavlov commented on IGNITE-1260: I've double checked, tests are running in AWS config after merge. > S3 IP finder should have an option to use a subfolder instead of bucket root > > > Key: IGNITE-1260 > URL: https://issues.apache.org/jira/browse/IGNITE-1260 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 1.1.4 >Reporter: Valentin Kulichenko >Assignee: Uday Kale >Priority: Minor > Labels: newbie, usability, user-request > Fix For: 2.7 > > > Current implementation forces user to use the bucket root which is not always > possible. Need to provide a configuration parameter that allows to provide a > path in addition to the bucket name. > Corresponding user@ thread: > http://apache-ignite-users.70518.x6.nabble.com/AWS-Integration-td495.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8778) Cache tests fail due short timeout
[ https://issues.apache.org/jira/browse/IGNITE-8778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8778: --- Labels: MakeTeamcityGreenAgain (was: ) > Cache tests fail due short timeout > -- > > Key: IGNITE-8778 > URL: https://issues.apache.org/jira/browse/IGNITE-8778 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > Cache tests can fail due time out: > [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-6515019727174930828&tab=testDetails] > > usually it passes, tests take ~50seconds, which is close to timeout. If TC is > overloaded, tests can take >60sec, which leads to false failures. > > we need to increase timeout to avoid this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8778) Cache tests fail due short timeout
[ https://issues.apache.org/jira/browse/IGNITE-8778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8778: --- Fix Version/s: 2.7 > Cache tests fail due short timeout > -- > > Key: IGNITE-8778 > URL: https://issues.apache.org/jira/browse/IGNITE-8778 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > Cache tests can fail due time out: > [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-6515019727174930828&tab=testDetails] > > usually it passes, tests take ~50seconds, which is close to timeout. If TC is > overloaded, tests can take >60sec, which leads to false failures. > > we need to increase timeout to avoid this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8778) Cache tests fail due short timeout
[ https://issues.apache.org/jira/browse/IGNITE-8778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559966#comment-16559966 ] ASF GitHub Bot commented on IGNITE-8778: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4180 > Cache tests fail due short timeout > -- > > Key: IGNITE-8778 > URL: https://issues.apache.org/jira/browse/IGNITE-8778 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > Cache tests can fail due time out: > [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-6515019727174930828&tab=testDetails] > > usually it passes, tests take ~50seconds, which is close to timeout. If TC is > overloaded, tests can take >60sec, which leads to false failures. > > we need to increase timeout to avoid this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8683) Tests fail after IGNITE-6639
[ https://issues.apache.org/jira/browse/IGNITE-8683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559967#comment-16559967 ] Dmitriy Pavlov commented on IGNITE-8683: Hi, fix version is empty. I've set 2.7, please set another version if commit was cherry-picked. > Tests fail after IGNITE-6639 > > > Key: IGNITE-8683 > URL: https://issues.apache.org/jira/browse/IGNITE-8683 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > Fix For: 2.7 > > > Example of failed tests: > org.apache.ignite.internal.processors.service.GridServiceProcessorMultiNodeSelfTest#testDeployOnEachNodeButClientUpdateTopology > > instead of checking address for loopback we should compare addr with locHost, > because nodes can use the same port, but different local address and both > addresses can be loopback. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8683) Tests fail after IGNITE-6639
[ https://issues.apache.org/jira/browse/IGNITE-8683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8683: --- Fix Version/s: 2.7 > Tests fail after IGNITE-6639 > > > Key: IGNITE-8683 > URL: https://issues.apache.org/jira/browse/IGNITE-8683 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > Fix For: 2.7 > > > Example of failed tests: > org.apache.ignite.internal.processors.service.GridServiceProcessorMultiNodeSelfTest#testDeployOnEachNodeButClientUpdateTopology > > instead of checking address for loopback we should compare addr with locHost, > because nodes can use the same port, but different local address and both > addresses can be loopback. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9111) Do not wait for deactivation in GridClusterStateProcessor#publicApiActiveState
Pavel Kovalenko created IGNITE-9111: --- Summary: Do not wait for deactivation in GridClusterStateProcessor#publicApiActiveState Key: IGNITE-9111 URL: https://issues.apache.org/jira/browse/IGNITE-9111 Project: Ignite Issue Type: Improvement Components: cache Affects Versions: 2.5, 2.4 Reporter: Pavel Kovalenko Assignee: Pavel Kovalenko Fix For: 2.7 Currently, we wait for activation/deactivation future when check state of the cluster. But when deactivation is in progress it doesn't make sense to wait for it, because after the successful wait we will throw an exception that cluster is not active. Synchronous waiting for deactivation future may lead to deadlocks if operation obtains some locks before checking cluster state. As the solution, we should check and wait only for activation futures. In case of in-progress deactivation, we should fail fast and return "false" from publicApiActiveState method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-4380) Cache invoke calls can be lost
[
https://issues.apache.org/jira/browse/IGNITE-4380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559945#comment-16559945
]
Vitaliy Biryukov edited comment on IGNITE-4380 at 7/27/18 4:40 PM:
---
[~Alexey Kuznetsov], LGTM.
was (Author: vitaliyb):
[~Alexey Kuznetsov], LGYM.
> Cache invoke calls can be lost
> --
>
> Key: IGNITE-4380
> URL: https://issues.apache.org/jira/browse/IGNITE-4380
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.0
>Reporter: Semen Boikov
>Assignee: Alexey Kuznetsov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
>
> * Recently added test
> GridCacheAbstractFullApiSelfTest.testInvokeAllMultithreaded fails on TC in
> various configurations with transactional cache.
> Example of failure
> GridCacheReplicatedOffHeapTieredMultiNodeFullApiSelfTest.testInvokeAllMultithreaded:
> {noformat}
> junit.framework.AssertionFailedError: expected:<2> but was:<10868>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.Assert.assertEquals(Assert.java:241)
> at junit.framework.TestCase.assertEquals(TestCase.java:409)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAbstractFullApiSelfTest.testInvokeAllMultithreaded(GridCacheAbstractFullApiSelfTest.java:342)
> at sun.reflect.GeneratedMethodAccessor96.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1803)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1718)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9112) Pre-touch for Ignite off-heap memory
Alexander Gerus created IGNITE-9112:
---
Summary: Pre-touch for Ignite off-heap memory
Key: IGNITE-9112
URL: https://issues.apache.org/jira/browse/IGNITE-9112
Project: Ignite
Issue Type: New Feature
Affects Versions: 2.6, 2.5, 2.4
Reporter: Alexander Gerus
At the moment Ignite off-heap memory is allocated in virtual memory of
operating system, not physical memory: it is recorded in an internal data
structure to avoid it being used by any other process. Not even a single page
will be allocated in physical memory until it's actually accessed. When the
Ignite needs memory, the operating system will allocate pages as needed.
The proposal is to add an option to Ignite that will touch every single byte of
the max off heap with a '0', resulting in the memory being allocated in the
physical memory in addition to being reserved in the internal data structure
(virtual memory). Similar option is available in JVM {{-XX:+AlwaysPreTouch}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8617) Node Discovery Using AWS Application ELB
[ https://issues.apache.org/jira/browse/IGNITE-8617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559998#comment-16559998 ] Dmitriy Pavlov commented on IGNITE-8617: Hi [~dmagda], I'll do my absolute best to find free time to review. There is a chance that final review will be required by someone experienced in AWS and IpFinder. > Node Discovery Using AWS Application ELB > > > Key: IGNITE-8617 > URL: https://issues.apache.org/jira/browse/IGNITE-8617 > Project: Ignite > Issue Type: New Feature > Components: aws >Reporter: Uday Kale >Assignee: Uday Kale >Priority: Major > Fix For: 2.7 > > > Support for Node discovery using AWS Application ELB. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9112) Pre-touch for Ignite off-heap memory
[
https://issues.apache.org/jira/browse/IGNITE-9112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560004#comment-16560004
]
Dmitriy Pavlov commented on IGNITE-9112:
Hi [~agerus], proposal seems reasonable to me.
In the same time I would encourage you to discuss this issue on dev.list:
d...@ignite.apache.org so everybody in community could provide feedback.
> Pre-touch for Ignite off-heap memory
>
>
> Key: IGNITE-9112
> URL: https://issues.apache.org/jira/browse/IGNITE-9112
> Project: Ignite
> Issue Type: New Feature
>Affects Versions: 2.4, 2.5, 2.6
>Reporter: Alexander Gerus
>Priority: Major
> Labels: features, offheap
>
> At the moment Ignite off-heap memory is allocated in virtual memory of
> operating system, not physical memory: it is recorded in an internal data
> structure to avoid it being used by any other process. Not even a single page
> will be allocated in physical memory until it's actually accessed. When the
> Ignite needs memory, the operating system will allocate pages as needed.
> The proposal is to add an option to Ignite that will touch every single byte
> of the max off heap with a '0', resulting in the memory being allocated in
> the physical memory in addition to being reserved in the internal data
> structure (virtual memory). Similar option is available in JVM
> {{-XX:+AlwaysPreTouch}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9113) Allocate memory for a data region when first cache assigned to this region is created
Valentin Kulichenko created IGNITE-9113: --- Summary: Allocate memory for a data region when first cache assigned to this region is created Key: IGNITE-9113 URL: https://issues.apache.org/jira/browse/IGNITE-9113 Project: Ignite Issue Type: Improvement Components: cache Affects Versions: 2.6 Reporter: Valentin Kulichenko Fix For: 2.7 Currently we do not create any regions or allocate any offheap memory on client nodes unless it's explicitly configured. This is good behavior, however there is a usability issue caused by the fact that many users have the same config file for both server and clients. This can lead to unexpected excessive memory usage on client side and forces users to maintain two config files in most cases. Same issue is applied to server nodes that do not store any data (e.g. nodes running only services). It's better to allocate memory dynamically, when first cache assigned to a data region is created. More detailed discussion here: http://apache-ignite-developers.2346864.n4.nabble.com/Data-regions-on-client-nodes-td32834.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9114) Fail fast in org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor#query
Andrew Medvedev created IGNITE-9114: --- Summary: Fail fast in org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor#query Key: IGNITE-9114 URL: https://issues.apache.org/jira/browse/IGNITE-9114 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Andrew Medvedev org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor#query has infinite loop with exit condition on success, thus failure to make reservation on partition can "hang" query. Exception should be thrown and method should return if no partition reservation can be made in reasonable time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9004) Failed to reinitialize local partitions
[
https://issues.apache.org/jira/browse/IGNITE-9004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560021#comment-16560021
]
Eduard Shangareev commented on IGNITE-9004:
---
https://reviews.ignite.apache.org/ignite/review/IGNT-CR-701?filePath=/modules/clients/src/test/java/org/apache/ignite/internal/processors/rest/AbstractRestProcessorSelfTest.java
> Failed to reinitialize local partitions
> ---
>
> Key: IGNITE-9004
> URL: https://issues.apache.org/jira/browse/IGNITE-9004
> Project: Ignite
> Issue Type: Test
>Reporter: Anton Kalashnikov
>Assignee: Eduard Shangareev
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Reproduced by Activate/Deactivate suit, almost any tests in
> IgniteChangeGlobalStateTest class. for example
> IgniteChangeGlobalStateTest#testStopPrimaryAndActivateFromClientNode
> {noformat}
> Failed to reinitialize local partitions (preloading will be stopped):
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=6,
> minorTopVer=1], discoEvt=DiscoveryCustomEvent
> [customMsg=ChangeGlobalStateMessage
> [id=9093c48a461-165cdacd-8a3b-4072-9f48-e80e1b63fda9,
> reqId=07393ea5-1c6a-4581-b016-9eb88d6bd978,
> initiatingNodeId=8dced5ba-725d-494b-8e8e-ffc76453fecd, activate=true,
> baselineTopology=BaselineTopology [id=0, branchingHash=314980173,
> branchingType='Cluster activation', baselineNodes=[node2, node0, node1]],
> forceChangeBaselineTopology=false, timestamp=1531832492029],
> affTopVer=AffinityTopologyVersion [topVer=6, minorTopVer=1],
> super=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=8dced5ba-725d-494b-8e8e-ffc76453fecd, addrs=[0:0:0:0:0:0:0:1%lo,
> 127.0.0.1, 172.25.4.132], sockAddrs=[/172.25.4.132:47504,
> /0:0:0:0:0:0:0:1%lo:47504, /127.0.0.1:47504], discPort=47504, order=2,
> intOrder=2, lastExchangeTime=1531832486546, loc=false,
> ver=2.7.0#19700101-sha1:, isClient=false], topVer=6,
> nodeId8=9960f6b9, msg=null, type=DISCOVERY_CUSTOM_EVT,
> tstamp=1531832492035]], nodeId=8dced5ba, evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError: calculatedOffset=3072, allocated=2048,
> headerSize=1024
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.read(FilePageStore.java:358)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:400)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:384)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:783)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:627)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:144)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.init(PagesList.java:169)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.(AbstractFreeList.java:371)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage$FreeListImpl.(MetaStorage.java:484)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.init(MetaStorage.java:143)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:852)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:954)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:661)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2484)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2364)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Given:
> # Activated Node1-1 in grid1.
> # MetaStorage on node1-1 in OffHeap.
> # MetaStorage have not storage on disk yet.
> When:
> # Checkpoint on node1-1 is starting. Start checkpoint marker was written.
> # node2-1 in grid2 is starting.(grid1 and grid2 have same persistence)
> Then:
> # node2-1 found expected checkpoint marker("Found unexpected checkpoint
> marker") and initialize FilePageStore for metaStorage by empty page
> # node1-1 finished checkpoint and wrote MetaStorage on disk.
>
[jira] [Updated] (IGNITE-8920) Node should be failed when during tx finish indices are corrupted.
[ https://issues.apache.org/jira/browse/IGNITE-8920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kovalenko updated IGNITE-8920: Component/s: cache > Node should be failed when during tx finish indices are corrupted. > -- > > Key: IGNITE-8920 > URL: https://issues.apache.org/jira/browse/IGNITE-8920 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.5 >Reporter: Ivan Daschinskiy >Assignee: Pavel Kovalenko >Priority: Major > Fix For: 2.7 > > > While transaction is processed after receiving finish request > (IgniteTxHandler.finish) , node should be failed by FailureHandler if page > content of indices is corrupted. Currently this case is not handled properly > and cause to long running transactions over the grid. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8920) Node should be failed when during tx finish indices are corrupted.
[ https://issues.apache.org/jira/browse/IGNITE-8920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560025#comment-16560025 ] Pavel Kovalenko commented on IGNITE-8920: - Fix is ready. Branch ignite-8920. > Node should be failed when during tx finish indices are corrupted. > -- > > Key: IGNITE-8920 > URL: https://issues.apache.org/jira/browse/IGNITE-8920 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.5 >Reporter: Ivan Daschinskiy >Assignee: Pavel Kovalenko >Priority: Major > Fix For: 2.7 > > > While transaction is processed after receiving finish request > (IgniteTxHandler.finish) , node should be failed by FailureHandler if page > content of indices is corrupted. Currently this case is not handled properly > and cause to long running transactions over the grid. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9115) org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor#query has infinite loop with exit condition on success, thus failure to make reservation o
Andrew Medvedev created IGNITE-9115: --- Summary: org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor#query has infinite loop with exit condition on success, thus failure to make reservation on partition can "hang" query. Key: IGNITE-9115 URL: https://issues.apache.org/jira/browse/IGNITE-9115 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Andrew Medvedev org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor#query has infinite loop with exit condition on success, thus failure to make reservation on partition can "hang" query. More detailed logging should be made if reservation of partition fails -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9115) org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor#query has infinite loop with exit condition on success, thus failure to make reservation o
[ https://issues.apache.org/jira/browse/IGNITE-9115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Medvedev updated IGNITE-9115: Description: org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor#query has infinite loop with exit condition on success, thus failure to make reservation on partition can "hang" query. More detailed logging should be made if method does not succeed in reasonable time (was: org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor#query has infinite loop with exit condition on success, thus failure to make reservation on partition can "hang" query. More detailed logging should be made if reservation of partition fails) > org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor#query > has infinite loop with exit condition on success, thus failure to make > reservation on partition can "hang" query. > --- > > Key: IGNITE-9115 > URL: https://issues.apache.org/jira/browse/IGNITE-9115 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Andrew Medvedev >Priority: Major > > org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor#query > has infinite loop with exit condition on success, thus failure to make > reservation on partition can "hang" query. More detailed logging should be > made if method does not succeed in reasonable time -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9114) Fail fast in org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor#query
[ https://issues.apache.org/jira/browse/IGNITE-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Medvedev updated IGNITE-9114: Description: org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor#query has infinite loop with exit condition on success, thus failure to make reservation on partition can "hang" query. Exception should be thrown and method should return if cycle does not succeed in reasonable time. (was: org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor#query has infinite loop with exit condition on success, thus failure to make reservation on partition can "hang" query. Exception should be thrown and method should return if no partition reservation can be made in reasonable time.) > Fail fast in > org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor#query > - > > Key: IGNITE-9114 > URL: https://issues.apache.org/jira/browse/IGNITE-9114 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Andrew Medvedev >Priority: Major > > org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor#query > has infinite loop with exit condition on success, thus failure to make > reservation on partition can "hang" query. Exception should be thrown and > method should return if cycle does not succeed in reasonable time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9113) Allocate memory for a data region when first cache assigned to this region is created
[ https://issues.apache.org/jira/browse/IGNITE-9113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Setrakyan reassigned IGNITE-9113: - Assignee: Alexey Goncharuk > Allocate memory for a data region when first cache assigned to this region is > created > - > > Key: IGNITE-9113 > URL: https://issues.apache.org/jira/browse/IGNITE-9113 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.6 >Reporter: Valentin Kulichenko >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 2.7 > > > Currently we do not create any regions or allocate any offheap memory on > client nodes unless it's explicitly configured. This is good behavior, > however there is a usability issue caused by the fact that many users have > the same config file for both server and clients. This can lead to unexpected > excessive memory usage on client side and forces users to maintain two config > files in most cases. > Same issue is applied to server nodes that do not store any data (e.g. nodes > running only services). > It's better to allocate memory dynamically, when first cache assigned to a > data region is created. > More detailed discussion here: > http://apache-ignite-developers.2346864.n4.nabble.com/Data-regions-on-client-nodes-td32834.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9113) Allocate memory for a data region when first cache assigned to this region is created
[ https://issues.apache.org/jira/browse/IGNITE-9113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov reassigned IGNITE-9113: -- Assignee: (was: Alexey Goncharuk) > Allocate memory for a data region when first cache assigned to this region is > created > - > > Key: IGNITE-9113 > URL: https://issues.apache.org/jira/browse/IGNITE-9113 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.6 >Reporter: Valentin Kulichenko >Priority: Major > Fix For: 2.7 > > > Currently we do not create any regions or allocate any offheap memory on > client nodes unless it's explicitly configured. This is good behavior, > however there is a usability issue caused by the fact that many users have > the same config file for both server and clients. This can lead to unexpected > excessive memory usage on client side and forces users to maintain two config > files in most cases. > Same issue is applied to server nodes that do not store any data (e.g. nodes > running only services). > It's better to allocate memory dynamically, when first cache assigned to a > data region is created. > More detailed discussion here: > http://apache-ignite-developers.2346864.n4.nabble.com/Data-regions-on-client-nodes-td32834.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9116) .NET: LINQ: CacheConfiguration.SqlSchema is ignored
Pavel Tupitsyn created IGNITE-9116:
--
Summary: .NET: LINQ: CacheConfiguration.SqlSchema is ignored
Key: IGNITE-9116
URL: https://issues.apache.org/jira/browse/IGNITE-9116
Project: Ignite
Issue Type: Improvement
Components: platforms
Affects Versions: 2.6, 2.5
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 2.7
{{CacheConfiguration.SqlSchema}} and {{CacheClientConfiguration.SqlSchema}} are
ignored by LINQ provider, schema name is inferred only from cache name.
See {{ExpressionWalker.GetTableNameWithSchema}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8446) Ability to check and completely fill transactions on creation
[
https://issues.apache.org/jira/browse/IGNITE-8446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560408#comment-16560408
]
Denis Magda commented on IGNITE-8446:
-
[~avinogradov], I'm afraid I'm not a right person for the cache internals
review. [~agoncharuk], [~ivan.glukos], could you please finalize the review of
the cache internals?
> Ability to check and completely fill transactions on creation
> -
>
> Key: IGNITE-8446
> URL: https://issues.apache.org/jira/browse/IGNITE-8446
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Fix For: 2.7
>
>
> Since {{label}} added to {{tx}} at IGNITE-6827 we'd like to have ability to
> guarantee it filled.
> So, we have to add special event fired on {{tx}} creation.
> This event can be used to provide such guarantee.
> Plan:
> Event EVT_TX_STARTED should be created.
> Tx.label should be recodred as a part of this event.
> Test, checking it's possible to restrict tx creation without filling the meta
> should be added.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-8993) Configuring sticky LoadBalancer for Ignite Service with Kubernetes
[ https://issues.apache.org/jira/browse/IGNITE-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda resolved IGNITE-8993. - Resolution: Fixed Thanks, merged the changes! > Configuring sticky LoadBalancer for Ignite Service with Kubernetes > -- > > Key: IGNITE-8993 > URL: https://issues.apache.org/jira/browse/IGNITE-8993 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Major > Fix For: 2.7 > > Attachments: ignite-service.yaml > > > Ignite service used for Ignite pods auto-discovery and access to the cluster > from remote applications is deployed as LoadBalancer: > https://apacheignite.readme.io/docs/ignite-service > This might lead to problems when a stateful session is needed between an app > and the cluster. For instance, Ignite JDBC driver preserves the state of an > opened connection meaning that once LoadBalancer connects the driver to an > Ignite pod, all the queries have to be redirected to that Ignite pod only > (unless the pod is down). > We need to show how to configure a sticky LoadBalancer that will assign a > client connection to a specific pod and won't change it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8993) Configuring sticky LoadBalancer for Ignite Service with Kubernetes
[ https://issues.apache.org/jira/browse/IGNITE-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda closed IGNITE-8993. --- > Configuring sticky LoadBalancer for Ignite Service with Kubernetes > -- > > Key: IGNITE-8993 > URL: https://issues.apache.org/jira/browse/IGNITE-8993 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Major > Fix For: 2.7 > > Attachments: ignite-service.yaml > > > Ignite service used for Ignite pods auto-discovery and access to the cluster > from remote applications is deployed as LoadBalancer: > https://apacheignite.readme.io/docs/ignite-service > This might lead to problems when a stateful session is needed between an app > and the cluster. For instance, Ignite JDBC driver preserves the state of an > opened connection meaning that once LoadBalancer connects the driver to an > Ignite pod, all the queries have to be redirected to that Ignite pod only > (unless the pod is down). > We need to show how to configure a sticky LoadBalancer that will assign a > client connection to a specific pod and won't change it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7802) Clarify how to hook Ignite and a 3rd party persistence
[ https://issues.apache.org/jira/browse/IGNITE-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560422#comment-16560422 ] Denis Magda commented on IGNITE-7802: - [~pgarg], looks good to me. Please release the page and close the ticket. > Clarify how to hook Ignite and a 3rd party persistence > -- > > Key: IGNITE-7802 > URL: https://issues.apache.org/jira/browse/IGNITE-7802 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Major > Fix For: 2.7 > > > The existing documentation doesn't explain all the steps needed to integrate > Ignite with a 3rd party db: > [https://apacheignite.readme.io/docs/3rd-party-store] > Specifically, the following has to be covered: > * Dedicated section for RDBMS setup. Copying of a JDBC driver, enabling a > right CacheStore implementation, defining the mapping, or automating this > process with Web Console. > * NoSQL databases section. Refer to Cassandra pages. > * Other 3rd party stores. Clarify how to write a custom CacheStore that is > not supported out of the box. > The goal is to avoid questions like this: > http://apache-ignite-users.70518.x6.nabble.com/Ignite-with-mariadb-td20101.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7802) Clarify how to hook Ignite and a 3rd party persistence
[ https://issues.apache.org/jira/browse/IGNITE-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-7802: --- Assignee: Prachi Garg (was: Denis Magda) > Clarify how to hook Ignite and a 3rd party persistence > -- > > Key: IGNITE-7802 > URL: https://issues.apache.org/jira/browse/IGNITE-7802 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Prachi Garg >Priority: Major > Fix For: 2.7 > > > The existing documentation doesn't explain all the steps needed to integrate > Ignite with a 3rd party db: > [https://apacheignite.readme.io/docs/3rd-party-store] > Specifically, the following has to be covered: > * Dedicated section for RDBMS setup. Copying of a JDBC driver, enabling a > right CacheStore implementation, defining the mapping, or automating this > process with Web Console. > * NoSQL databases section. Refer to Cassandra pages. > * Other 3rd party stores. Clarify how to write a custom CacheStore that is > not supported out of the box. > The goal is to avoid questions like this: > http://apache-ignite-users.70518.x6.nabble.com/Ignite-with-mariadb-td20101.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8697) Flink sink throws java.lang.IllegalArgumentException when running in flink cluster mode.
[ https://issues.apache.org/jira/browse/IGNITE-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saikat Maitra reassigned IGNITE-8697: - Assignee: Andrew Mashenkov > Flink sink throws java.lang.IllegalArgumentException when running in flink > cluster mode. > > > Key: IGNITE-8697 > URL: https://issues.apache.org/jira/browse/IGNITE-8697 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.3, 2.4, 2.5 >Reporter: Ray >Assignee: Andrew Mashenkov >Priority: Blocker > > if I submit the Application to the Flink Cluster using Ignite flink sink I > get this error > > java.lang.ExceptionInInitializerError > at > org.apache.ignite.sink.flink.IgniteSink$SinkContext.getStreamer(IgniteSink.java:201) > at > org.apache.ignite.sink.flink.IgniteSink$SinkContext.access$100(IgniteSink.java:175) > at org.apache.ignite.sink.flink.IgniteSink.invoke(IgniteSink.java:165) > at > org.apache.flink.streaming.api.functions.sink.SinkFunction.invoke(SinkFunction.java:52) > at > org.apache.flink.streaming.api.operators.StreamSink.processElement(StreamSink.java:56) > at > org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.pushToOperator(OperatorChain.java:560) > at > org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect(OperatorChain.java:535) > at > org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect(OperatorChain.java:515) > at > org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect(AbstractStreamOperator.java:679) > at > org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect(AbstractStreamOperator.java:657) > at > org.apache.flink.streaming.api.operators.TimestampedCollector.collect(TimestampedCollector.java:51) > at > org.myorg.quickstart.InstrumentStreamer$Splitter.flatMap(InstrumentStreamer.java:97) > at > org.myorg.quickstart.InstrumentStreamer$Splitter.flatMap(InstrumentStreamer.java:1) > at > org.apache.flink.streaming.api.operators.StreamFlatMap.processElement(StreamFlatMap.java:50) > at > org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.pushToOperator(OperatorChain.java:560) > at > org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect(OperatorChain.java:535) > at > org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect(OperatorChain.java:515) > at > org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect(AbstractStreamOperator.java:679) > at > org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect(AbstractStreamOperator.java:657) > at > org.apache.flink.streaming.api.operators.StreamSourceContexts$NonTimestampContext.collect(StreamSourceContexts.java:104) > at > org.apache.flink.streaming.api.functions.source.SocketTextStreamFunction.run(SocketTextStreamFunction.java:110) > at > org.apache.flink.streaming.api.operators.StreamSource.run(StreamSource.java:87) > at > org.apache.flink.streaming.api.operators.StreamSource.run(StreamSource.java:56) > at > org.apache.flink.streaming.runtime.tasks.SourceStreamTask.run(SourceStreamTask.java:99) > at > org.apache.flink.streaming.runtime.tasks.StreamTask.invoke(StreamTask.java:306) > at org.apache.flink.runtime.taskmanager.Task.run(Task.java:703) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.IllegalArgumentException: Ouch! Argument is invalid: > Cache name must not be null or empty. > at > org.apache.ignite.internal.util.GridArgumentCheck.ensure(GridArgumentCheck.java:109) > at > org.apache.ignite.internal.processors.cache.GridCacheUtils.validateCacheName(GridCacheUtils.java:1581) > at > org.apache.ignite.internal.IgniteKernal.dataStreamer(IgniteKernal.java:3284) > at > org.apache.ignite.sink.flink.IgniteSink$SinkContext$Holder.(IgniteSink.java:183) > ... 27 more -- This message was sent by Atlassian JIRA (v7.6.3#76005)
