Re: Set gitter aside

[Konstantin Dudkov]

Agree.

IMHO we should remove link to gitter from everywhere and keep answering 
there, but for questions about product usage we should ask to ask the 
question in userlist.


27/10/2017 02:10, Dmitriy Setrakyan пишет:

How about we continue to have the Gitter channel, but remove the link from
the website?

On Thu, Oct 26, 2017 at 3:05 PM, Yakov Zhdanov  wrote:


I would consider moving decent questions to mailing lists asking to do so
in response to gitter requests and at some point stop gitter.

--Yakov





--
Regards, Konstantin.

Set gitter aside

[Konstantin Dudkov]

Igniters,

Last months there are a lot of questions in userlist and gitter and 
answering that questions I found gitter completely inappropriate for 
user support:


 - there are no threads there, so it's hard to track discussion or see 
unanswered questions
 - when somebody post stacktrace or code snippet all message list 
scrolls far up, hiding previous messages
 - many questions that need more than simple answer or some kind of 
discussion are moved to anyway
 - using gitter people are waiting for fast answer, that is not always 
possible (timezones, etc.)


I think it is better to remove link to gitter from all our sites/manuals 
and to focus on answering in userlist and StackOverflow only.


Thoughts?

--
Regards, Konstantin.

[jira] [Created] (IGNITE-6661) fix client deadlock in 2.x

[Konstantin Dudkov (JIRA)]

Konstantin Dudkov created IGNITE-6661:
-

 Summary: fix client deadlock in 2.x
 Key: IGNITE-6661
 URL: https://issues.apache.org/jira/browse/IGNITE-6661
 Project: Ignite
  Issue Type: Sub-task
Affects Versions: 2.3
Reporter: Konstantin Dudkov
Assignee: Konstantin Dudkov






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6655) gracefully handle AmazonS3Exception: Slow Down in TcpDiscoveryS3IpFinder

[Konstantin Dudkov (JIRA)]

Konstantin Dudkov created IGNITE-6655:
-

 Summary: gracefully handle AmazonS3Exception: Slow Down in 
TcpDiscoveryS3IpFinder
 Key: IGNITE-6655
 URL: https://issues.apache.org/jira/browse/IGNITE-6655
 Project: Ignite
  Issue Type: Improvement
  Security Level: Public (Viewable by anyone)
Affects Versions: 2.1
Reporter: Konstantin Dudkov
Assignee: Konstantin Dudkov


for now if we got "AmazonS3Exception: Slow Down" in TcpDiscoveryS3IpFinder node 
stops

we should handle this situation with some kind of backoff algorithm



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6581) clent deadlock in spiStart

[Konstantin Dudkov (JIRA)]

Konstantin Dudkov created IGNITE-6581:
-

 Summary: clent deadlock in spiStart
 Key: IGNITE-6581
 URL: https://issues.apache.org/jira/browse/IGNITE-6581
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.9
Reporter: Konstantin Dudkov
Assignee: Konstantin Dudkov



{code:java}
"tcp-client-disco-msg-worker-#4%soloots-tg-ManagementFabric%" #50 prio=5 
os_prio=0 tid=0x7fafecd50800 nid=0x469e sleeping[0x7fafc3bfa000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at 
org.apache.ignite.internal.util.GridSpinReadWriteLock.tryWriteLock(GridSpinReadWriteLock.java:349)
at 
org.apache.ignite.internal.GridKernalGatewayImpl.writeLock(GridKernalGatewayImpl.java:121)
at 
org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:3427)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:601)
at 
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2400)
at 
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2379)
at 
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1707)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)

"main" #1 prio=5 os_prio=0 tid=0x7fafec01 nid=0x4644 waiting on 
condition [0x7faff325]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0x00068a331ad0> (a 
java.util.concurrent.CountDownLatch$Sync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
at 
org.apache.ignite.spi.discovery.tcp.ClientImpl.spiStart(ClientImpl.java:265)
at 
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1862)
at 
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:268)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:690)
at 
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1682)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:940)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1814)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1605)
- locked <0x0004107210e8> (a 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:569)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:516)
at org.apache.ignite.Ignition.start(Ignition.java:322)
at 
com.workday.fabric.ignite.IgniteFabric.lambda$start$1(IgniteFabric.java:143)
at 
com.workday.fabric.ignite.IgniteFabric$$Lambda$6/576020159.run(Unknown Source)
at 
com.workday.fabric.util.InvocationInterceptor.invokeRunnable(InvocationInterceptor.java:119)
at com.workday.fabric.ignite.IgniteFabric.start(IgniteFabric.java:138)
- locked <0x0004107212e0> (a 
com.workday.fabric.ignite.IgniteWorkdayFabric)
at com.workday.fabric.FabricManager.ensureFabric(FabricManager.java:146)
- locked <0x000410721368> (a java.util.concurrent.ConcurrentHashMap)
at 
com.workday.fabric.WorkdayFabricManager.ensureFabric(WorkdayFabricManager.java:76)
at 
com.workday.fabric.verifier.FabricVerifier.verify(FabricVerifier.java:347)
at 
com.workday.fabric.verifier.FabricVerifier.main(FabricVerifier.java:276)
{code}




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Identifying grid transactions

[Konstantin Dudkov]

Hi,

.withTag maybe?

04/10/2017 14:52, Sergey Kozlov пишет:

Hi

.withApplication and .withMetatData may narrow use case. Looks like .
withDescription can have more sense and allow use write any information
valuable for further debugging.

On Wed, Oct 4, 2017 at 2:47 PM, Dmitriy Setrakyan 
wrote:


I would rename to "withMetadata()".

On Wed, Oct 4, 2017 at 2:31 PM, Vladimir Ozerov 
wrote:


Alex,

I do not think we have such feature in the product at the moment. But

this

could be very valuable addition. For example, we have somewhat similar

task

for JDBC - to track applications that use the driver [1]. We can think of
adding a single optional string to transaction protocol, so that we can
track application/module on any node. E.g.:

IgniteTransactions transactions = ignite.transactions().

withApplication("

*myApp:myModule*");

And then all usages of this facade will propagate application to all

nodes.


Thoughts?

[1] https://issues.apache.org/jira/browse/IGNITE-5453

On Wed, Oct 4, 2017 at 1:22 PM, Alexei Scherbakov <
alexey.scherbak...@gmail.com> wrote:


Alexey,

Simplest way: wrap IgniteTransactions instance returned by
ignite.transactions() with delegate using advanced logging capabilities

for

tx* methods, like current thread and stack trace.

There is no notion of transaction parameters.

2017-10-04 12:40 GMT+03:00 Alexey Inozemtsev <

alexey.inozemt...@gmail.com

:



Igniters,
A team I'm working with uses Apache Ignite massively.
There are many application modules using the cluster.
We've faced a problem on how to identify the external app
modules which keep transactions open in the grid.
Right now we have to restart client nodes to get reed of them.

Is there a parameter on Ignite transaction to (ala MODULE in Oracle)

which

can be set on a client side?
Are there other ways to manage such a situation?

Have a nice day,
Alexey





--

Best regards,
Alexei Scherbakov











--
Regards, Konstantin.

Re: [VOTE] Apache Ignite 2.2.0 RC2

[Konstantin Dudkov]

+1


15/09/2017 17:48, Anton Vinogradov пишет:

Igniters,

We have uploaded a 2.2.0 release candidate to
https://dist.apache.org/repos/dist/dev/ignite/2.2.0-rc2/

Git tag name is
2.2.0-rc2

This release includes the following changes:

Ignite:
* Checkpointing algorithm optimized
* Default max memory size changed from 80% to 20%

Complete list of closed issues:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.2%20AND%20(status%20%3D%20closed%20or%20status%20%3D%20resolved)

DEVNOTES
https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=refs/tags/2.2.0-rc2

RELEASE NOTES
https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.2.0-rc2

Please start voting.

+1 - to accept Apache Ignite 2.2.0-RC2
0 - don't care either way
-1 - DO NOT accept Apache Ignite 2.2.0-RC2 (explain why)

This vote will go for 72 hours.

Re: Persistence per memory policy configuration

[Konstantin Dudkov]

Can we have separate MemoryPolycy for every CacheGroup? In that case we 
could auto generate MemoryPolycy based on CacheGroup settings and have a 
"cache level" persistence settings.


We can use some kind of MemoryPolicyTemplate to add default values and 
even re-use existing MemoryPolicy if all settings are the same.



To extend on the idea of 2 different policies for memory and persistence,
can we have 2 completely different configuration classes?

  - MemoryPolicy
  - PersistentMemoryPolicy (extends MemoryPolicy?)

Every cache should be associated with either MemoryPolicy or
PersistentMemoryPolicy, but not both. By default, caches on startup are
associated with default MemoryPolicy. Users can always change it to some
PersistentMemoryPolicy, if persistence needs to be enabled.

If we agree on the above, do we really need a persistenceEnabled flag at
all?

D.

On Tue, Sep 12, 2017 at 2:57 AM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:


We surely can, but:
  * we should then have two configuration settings for default memory policy
size (one in-memory and one persisted)
  * a user still may configure multiple custom memory policies. In this
case, the requirement to have this flag the same in a memory policy is
still valid, so a user still can get exceptions.

2017-09-12 12:44 GMT+03:00 Vladimir Ozerov :


Alex,

Can we have two default memory policies - one for in-memory and another

one

for persistence cases?

On Tue, Sep 12, 2017 at 12:40 PM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:


This is possible, but then if two caches belong to the same memory

policy,

they must be both either persistence-enabled or persistence-disabled.

We

can add this validation, but I think this will lead to a greater

confusion

for a user.

2017-09-12 12:34 GMT+03:00 Pavel Tupitsyn :


Agree with Vladimir.

Currently we enable persistence cluster-wide by setting
IgniteConfiguration.persistentStoreConfiguration.
Ideally CacheConfiguration.persistenceEnabled should be the only

setting I

need to set.

Thanks,
Pavel

On Tue, Sep 12, 2017 at 12:28 PM, Vladimir Ozerov <

voze...@gridgain.com>

wrote:


As a user I would definitely prefer to control persistence through

flag

on

cache configuration. I do not even want to know what "memory

policy"

is.

E.g. CacheConfiguration.persistenceEnabled.

On Tue, Sep 12, 2017 at 12:24 PM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:


Igniters,

I am currently reviewing a change allowing to enable persistence

on a

per-memory-policy basis (thanks to K. Dudkov!) and have a

question

regarding the changes in configuration.

The suggested change is to add a flag "persistenceEnabled"

(defaults

to

true) to the memory policy configuration. To keep configuration
compatibility, the logic is as follows:

If PersistentStoreConfiguration is set, then only memory policies

with

persistenceEnabled=true flag will be persisted, which is

consistent

with

the current behavior. To disable persistence, persistenceEnabled

flag

should be explicitly set to false.

If PersistentStoreConfiguration is not set, then all caches are

stored

in-memory and persistenceEnabled is ignored.

While personally, I like this change, I would like to check if

there

are

any thoughts or objections to this approach.

--
Thanks,
AG

[jira] [Created] (IGNITE-6067) Refactor cache configuration initialization with proper defaults

[Konstantin Dudkov (JIRA)]

Konstantin Dudkov created IGNITE-6067:
-

 Summary: Refactor cache configuration initialization with proper 
defaults
 Key: IGNITE-6067
 URL: https://issues.apache.org/jira/browse/IGNITE-6067
 Project: Ignite
  Issue Type: Improvement
Reporter: Konstantin Dudkov
Assignee: Konstantin Dudkov
 Fix For: 2.2


Move cache configuration initialization from GridCacheProcessor#initialize to 
GridCacheUtils



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5964) test fail: TcpClientDiscoverySpiSelfTest (disconnectLatch timeout)

[Konstantin Dudkov (JIRA)]

Konstantin Dudkov created IGNITE-5964:
-

 Summary: test fail: TcpClientDiscoverySpiSelfTest (disconnectLatch 
timeout)
 Key: IGNITE-5964
 URL: https://issues.apache.org/jira/browse/IGNITE-5964
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Konstantin Dudkov
 Fix For: 2.2


flake tests: testReconnectAfterFailTopologyChanged, 
testReconnectAfterTopologyChanged

disconnectLatch timeout

{code:java}
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertTrue(Assert.java:31)
at junit.framework.TestCase.assertTrue(TestCase.java:201)
at 
org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.reconnectAfterFail(TcpClientDiscoverySpiSelfTest.java:1422)
at 
org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.testReconnectAfterFailTopologyChanged(TcpClientDiscoverySpiSelfTest.java:1331)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
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:2000)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
at java.lang.Thread.run(Thread.java:745)
{code}




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5454) Tree is being concurrently destroyed error

[Konstantin Dudkov (JIRA)]

Konstantin Dudkov created IGNITE-5454:
-

 Summary: Tree is being concurrently destroyed error
 Key: IGNITE-5454
 URL: https://issues.apache.org/jira/browse/IGNITE-5454
 Project: Ignite
  Issue Type: Bug
Reporter: Konstantin Dudkov
Assignee: Konstantin Dudkov


{code}
Caused by: java.lang.IllegalStateException: Tree is being concurrently 
destroyed: p-305##CacheData
at 
org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.checkDestroyed(BPlusTree.java:928)
at 
org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.find(BPlusTree.java:949)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.cursor(IgniteCacheOffheapManagerImpl.java:1328)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.cursor(IgniteCacheOffheapManagerImpl.java:1308)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.cursor(IgniteCacheOffheapManagerImpl.java:1302)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$6.onHasNext(IgniteCacheOffheapManagerImpl.java:619)
at 
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
at 
org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.clearCache(IgniteCacheOffheapManagerImpl.java:432)
at 
org.apache.ignite.internal.processors.cache.GridCacheClearAllRunnable.run(GridCacheClearAllRunnable.java:85)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.clearLocally(GridCacheAdapter.java:1056)
at 
org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.clearLocally(GridCacheProxyImpl.java:977)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter$GlobalClearAllJob.localExecute(GridCacheAdapter.java:5136)
{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5055) Optimize GridDhtPartitionTopologyImpl: do not store backup mappings for replicated cache

[Konstantin Dudkov (JIRA)]

Konstantin Dudkov created IGNITE-5055:
-

 Summary: Optimize GridDhtPartitionTopologyImpl: do not store 
backup mappings for replicated cache
 Key: IGNITE-5055
 URL: https://issues.apache.org/jira/browse/IGNITE-5055
 Project: Ignite
  Issue Type: Task
Reporter: Konstantin Dudkov
Assignee: Konstantin Dudkov






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5002) fix tests in master

[Konstantin Dudkov (JIRA)]

Konstantin Dudkov created IGNITE-5002:
-

 Summary: fix tests in master
 Key: IGNITE-5002
 URL: https://issues.apache.org/jira/browse/IGNITE-5002
 Project: Ignite
  Issue Type: Task
Reporter: Konstantin Dudkov
Assignee: Konstantin Dudkov






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-4982) GridCacheAbstractRemoveFailureTest fail

[Konstantin Dudkov (JIRA)]

Konstantin Dudkov created IGNITE-4982:
-

 Summary: GridCacheAbstractRemoveFailureTest fail
 Key: IGNITE-4982
 URL: https://issues.apache.org/jira/browse/IGNITE-4982
 Project: Ignite
  Issue Type: Bug
  Components: cache
Reporter: Konstantin Dudkov
Assignee: Konstantin Dudkov
 Fix For: 2.0






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-4404) GridCacheOffHeapMultiThreadedUpdateAbstractSelfTest long running test refactoring

[Konstantin Dudkov (JIRA)]

Konstantin Dudkov created IGNITE-4404:
-

 Summary: GridCacheOffHeapMultiThreadedUpdateAbstractSelfTest long 
running test refactoring
 Key: IGNITE-4404
 URL: https://issues.apache.org/jira/browse/IGNITE-4404
 Project: Ignite
  Issue Type: Test
Reporter: Konstantin Dudkov


in testTransform

final int THREADS = 5;
final int ITERATIONS_PER_THREAD = 10_000;



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-4403) IgniteCacheQueryMultiThreadedSelfTest long running test refactoring

[Konstantin Dudkov (JIRA)]

Konstantin Dudkov created IGNITE-4403:
-

 Summary: IgniteCacheQueryMultiThreadedSelfTest long running test 
refactoring
 Key: IGNITE-4403
 URL: https://issues.apache.org/jira/browse/IGNITE-4403
 Project: Ignite
  Issue Type: Test
Reporter: Konstantin Dudkov


multiple sleeps for 3



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-4400) GridAbstractCacheInterceptorRebalanceTest refactoring

[Konstantin Dudkov (JIRA)]

Konstantin Dudkov created IGNITE-4400:
-

 Summary: GridAbstractCacheInterceptorRebalanceTest refactoring
 Key: IGNITE-4400
 URL: https://issues.apache.org/jira/browse/IGNITE-4400
 Project: Ignite
  Issue Type: Test
Reporter: Konstantin Dudkov


now GridAbstractCacheInterceptorRebalanceTest is running for too long (with all 
subclassed tests it costs more than 8% of all tests time)

current settings are:
CNT = 10_000
TEST_ITERATIONS = 5

we should try to reduce test running time or parametrize it for fast/long 
versions



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)