Re: IgniteSemaphore and failoverSafe flag

[Vladisav Jelisavcic]

Hi everyone,

I agree with Val, he's got a point; recreating the lock doesn't seem
possible
(at least not the with the transactional cache lock/semaphore we have).
Is this re-create behavior really needed?

Best regards,
Vladisav



On Thu, Mar 16, 2017 at 8:34 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Guys,
>
> How does recreation of the lock helps? My understanding is that scenario is
> the following:
>
> 1. Client A creates and acquires a lock, and then starts to execute guarded
> logic.
> 2. Client B tries to acquire the same lock and parks to wait.
> 3. Before client A unlocks, all affinity nodes for the lock fail, lock
> disappears from the cache.
> 4. Client B fails with exception, recreates the lock, acquires it, and
> starts to execute guarded logic concurrently with client A.
>
> In my view this is wrong anyway, regardless of whether this happens
> silently or with an exception handled in user's code. Because this code
> doesn't have any way to know if client A still holds the lock or not.
>
> Am I missing something?
>
> -Val
>
> On Tue, Mar 14, 2017 at 10:14 AM, Dmitriy Setrakyan  >
> wrote:
>
> > On Tue, Mar 14, 2017 at 12:46 AM, Alexey Goncharuk <
> > alexey.goncha...@gmail.com> wrote:
> >
> > > >
> > > > Which user operation would result in exception? To my knowledge, user
> > may
> > > > already be holding the lock and not invoking any Ignite APIs, no?
> > > >
> > >
> > > Yes, this is exactly my point.
> > >
> > > Imagine that a node already holds a lock and another node is waiting
> for
> > > the lock. If all partition nodes leave the grid and the lock is
> > re-created,
> > > this second node will immediately acquire the lock and we will have two
> > > lock owners. I think in this case this second node (blocked on lock())
> > > should get an exception saying that the lock was lost (which is, by the
> > > way, the current behavior), and the first node should get an exception
> on
> > > unlock.
> > >
> >
> > Makes sense.
> >
>

Re: IgniteSemaphore and failoverSafe flag

[Valentin Kulichenko]

Guys,

How does recreation of the lock helps? My understanding is that scenario is
the following:

1. Client A creates and acquires a lock, and then starts to execute guarded
logic.
2. Client B tries to acquire the same lock and parks to wait.
3. Before client A unlocks, all affinity nodes for the lock fail, lock
disappears from the cache.
4. Client B fails with exception, recreates the lock, acquires it, and
starts to execute guarded logic concurrently with client A.

In my view this is wrong anyway, regardless of whether this happens
silently or with an exception handled in user's code. Because this code
doesn't have any way to know if client A still holds the lock or not.

Am I missing something?

-Val

On Tue, Mar 14, 2017 at 10:14 AM, Dmitriy Setrakyan 
wrote:

> On Tue, Mar 14, 2017 at 12:46 AM, Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
>
> > >
> > > Which user operation would result in exception? To my knowledge, user
> may
> > > already be holding the lock and not invoking any Ignite APIs, no?
> > >
> >
> > Yes, this is exactly my point.
> >
> > Imagine that a node already holds a lock and another node is waiting for
> > the lock. If all partition nodes leave the grid and the lock is
> re-created,
> > this second node will immediately acquire the lock and we will have two
> > lock owners. I think in this case this second node (blocked on lock())
> > should get an exception saying that the lock was lost (which is, by the
> > way, the current behavior), and the first node should get an exception on
> > unlock.
> >
>
> Makes sense.
>

Re: IGNITE-4536 metrics of new offheap storage

[Dmitriy Setrakyan]

As far as the percentage of the free page space, why do we need to provide
3 ranges: 0 -> 16, 16 -> 32, 32 -> 64, etc? Why not just provide average
free bytes percentage as one value?

Am I misunderstanding something?

On Thu, Mar 16, 2017 at 11:04 AM, Denis Magda  wrote:

> Sergey,
>
> Considering that the swap tier will no longer be supported in 2.0 all the
> methods that start with ‘getSwap…’ are no longer relevant and have to be
> removed from metrics. For instance, the swap functionality has already been
> wiped out from .NET:
> https://issues.apache.org/jira/browse/IGNITE-4736
>
> Next, I’m also confused with the metrics that include ‘Dht’ in its name.
> The on-heap tier we have in 1.x will be replaced with on-heap cache:
> https://issues.apache.org/jira/browse/IGNITE-4535 <
> https://issues.apache.org/jira/browse/IGNITE-4535>
> Does it me that ‘Dht’ methods are still relevant or they need to be
> replaced with something more meaningful? *Alex G.*, please chime in.
>
> Finally, personally I don’t like the API for these 3 methods
>
> >
> >public float getPagesPercentage_8_16_freeBytes();
> >public float getPagesPercentage_16_64_freeBytes();
> >public float getPagesPercentage_64_256_freeBytes();
>
> Wouldn’t it better to have a single method like this?
>
> public float[] getPagesFreeBytesPercentage();
>
> where
>
> float[0] - 0 to 16 free bytes.
> float[1] - 16 to 32 free bytes.
> float[2] - 32 to 64 free bytes.
> …..
> float[N] - page_size - 16 to page size free bytes.
>
> —
> Denis
>
> > On Mar 16, 2017, at 10:22 AM, Sergey Chugunov 
> wrote:
> >
> > Denis,
> >
> > Here is a version of CacheMetrics interface with all changes how I see
> them
> > (pretty long list :)).
> >
> > public interface CacheMetrics {
> >
> >   public long getCacheHits();
> >
> >   public float getCacheHitPercentage();
> >
> >   public long getCacheMisses();
> >
> >   public float getCacheMissPercentage();
> >
> >   public long getCacheGets();
> >
> >   public long getCachePuts();
> >
> >   public long getCacheRemovals();
> >
> >   public long getCacheEvictions();
> >
> >   public float getAverageGetTime();
> >
> >   public float getAveragePutTime();
> >
> >   public float getAverageRemoveTime();
> >
> >   public float getAverageTxCommitTime();
> >
> >   public float getAverageTxRollbackTime();
> >
> >   public long getCacheTxCommits();
> >
> >   public long getCacheTxRollbacks();
> >
> >   public String name();
> >
> >   public long getOverflowSize();
> >
> >   public long getOffHeapGets();
> >
> >   public long getOffHeapPuts();//removing as it duplicates cachePuts
> >
> >   public long getOffHeapRemovals();
> >
> >   public long getOffHeapEvictions();
> >
> >   public long getOffHeapHits();
> >
> >   public float getOffHeapHitPercentage();
> >
> >   public long getOffHeapMisses();//removing as it duplicates cacheMisses
> >
> >   public float getOffHeapMissPercentage();//removing as it duplicates
> > cacheMissPercentage
> >
> >   public long getOffHeapEntriesCount();
> >
> >   public long getOffHeapPrimaryEntriesCount();
> >
> >   public long getOffHeapBackupEntriesCount();
> >
> >   public long getOffHeapAllocatedSize();
> >
> >   public long getOffHeapMaxSize();
> >
> >   public long getSwapGets();
> >
> >   public long getSwapPuts();
> >
> >   public long getSwapRemovals();
> >
> >   public long getSwapHits();
> >
> >   public long getSwapMisses();
> >
> >   public long getSwapEntriesCount();
> >
> >   public long getSwapSize();
> >
> >   public float getSwapHitPercentage();
> >
> >   public float getSwapMissPercentage();
> >
> >   public int getSize();
> >
> >   public int getKeySize();
> >
> >   public boolean isEmpty();
> >
> >   public int getDhtEvictQueueCurrentSize();
> >
> >   public int getTxThreadMapSize();
> >
> >   public int getTxXidMapSize();
> >
> >   public int getTxCommitQueueSize();
> >
> >   public int getTxPrepareQueueSize();
> >
> >   public int getTxStartVersionCountsSize();
> >
> >   public int getTxCommittedVersionsSize();
> >
> >   public int getTxRolledbackVersionsSize();
> >
> >   public int getTxDhtThreadMapSize();
> >
> >   public int getTxDhtXidMapSize();
> >
> >   public int getTxDhtCommitQueueSize();
> >
> >   public int getTxDhtPrepareQueueSize();
> >
> >   public int getTxDhtStartVersionCountsSize();
> >
> >   public int getTxDhtCommittedVersionsSize();
> >
> >   public int getTxDhtRolledbackVersionsSize();
> >
> >   public boolean isWriteBehindEnabled();
> >
> >   public int getWriteBehindFlushSize();
> >
> >   public int getWriteBehindFlushThreadCount();
> >
> >   public long getWriteBehindFlushFrequency();
> >
> >   public int getWriteBehindStoreBatchSize();
> >
> >   public int getWriteBehindTotalCriticalOverflowCount();
> >
> >   public int getWriteBehindCriticalOverflowCount();
> >
> >   public int getWriteBehindErrorRetryCount();
> >
> >   public int getWriteBehindBufferSize();
> >
> >   public String getKeyType();
> >
> >   

Re: IGNITE-4536 metrics of new offheap storage

[Denis Magda]

Sergey,

Considering that the swap tier will no longer be supported in 2.0 all the 
methods that start with ‘getSwap…’ are no longer relevant and have to be 
removed from metrics. For instance, the swap functionality has already been 
wiped out from .NET:
https://issues.apache.org/jira/browse/IGNITE-4736

Next, I’m also confused with the metrics that include ‘Dht’ in its name. The 
on-heap tier we have in 1.x will be replaced with on-heap cache: 
https://issues.apache.org/jira/browse/IGNITE-4535 

Does it me that ‘Dht’ methods are still relevant or they need to be replaced 
with something more meaningful? *Alex G.*, please chime in.

Finally, personally I don’t like the API for these 3 methods

> 
>public float getPagesPercentage_8_16_freeBytes();
>public float getPagesPercentage_16_64_freeBytes();
>public float getPagesPercentage_64_256_freeBytes();

Wouldn’t it better to have a single method like this?

public float[] getPagesFreeBytesPercentage();

where 

float[0] - 0 to 16 free bytes.
float[1] - 16 to 32 free bytes.
float[2] - 32 to 64 free bytes.
…..
float[N] - page_size - 16 to page size free bytes.

—
Denis

> On Mar 16, 2017, at 10:22 AM, Sergey Chugunov  
> wrote:
> 
> Denis,
> 
> Here is a version of CacheMetrics interface with all changes how I see them
> (pretty long list :)).
> 
> public interface CacheMetrics {
> 
>   public long getCacheHits();
> 
>   public float getCacheHitPercentage();
> 
>   public long getCacheMisses();
> 
>   public float getCacheMissPercentage();
> 
>   public long getCacheGets();
> 
>   public long getCachePuts();
> 
>   public long getCacheRemovals();
> 
>   public long getCacheEvictions();
> 
>   public float getAverageGetTime();
> 
>   public float getAveragePutTime();
> 
>   public float getAverageRemoveTime();
> 
>   public float getAverageTxCommitTime();
> 
>   public float getAverageTxRollbackTime();
> 
>   public long getCacheTxCommits();
> 
>   public long getCacheTxRollbacks();
> 
>   public String name();
> 
>   public long getOverflowSize();
> 
>   public long getOffHeapGets();
> 
>   public long getOffHeapPuts();//removing as it duplicates cachePuts
> 
>   public long getOffHeapRemovals();
> 
>   public long getOffHeapEvictions();
> 
>   public long getOffHeapHits();
> 
>   public float getOffHeapHitPercentage();
> 
>   public long getOffHeapMisses();//removing as it duplicates cacheMisses
> 
>   public float getOffHeapMissPercentage();//removing as it duplicates
> cacheMissPercentage
> 
>   public long getOffHeapEntriesCount();
> 
>   public long getOffHeapPrimaryEntriesCount();
> 
>   public long getOffHeapBackupEntriesCount();
> 
>   public long getOffHeapAllocatedSize();
> 
>   public long getOffHeapMaxSize();
> 
>   public long getSwapGets();
> 
>   public long getSwapPuts();
> 
>   public long getSwapRemovals();
> 
>   public long getSwapHits();
> 
>   public long getSwapMisses();
> 
>   public long getSwapEntriesCount();
> 
>   public long getSwapSize();
> 
>   public float getSwapHitPercentage();
> 
>   public float getSwapMissPercentage();
> 
>   public int getSize();
> 
>   public int getKeySize();
> 
>   public boolean isEmpty();
> 
>   public int getDhtEvictQueueCurrentSize();
> 
>   public int getTxThreadMapSize();
> 
>   public int getTxXidMapSize();
> 
>   public int getTxCommitQueueSize();
> 
>   public int getTxPrepareQueueSize();
> 
>   public int getTxStartVersionCountsSize();
> 
>   public int getTxCommittedVersionsSize();
> 
>   public int getTxRolledbackVersionsSize();
> 
>   public int getTxDhtThreadMapSize();
> 
>   public int getTxDhtXidMapSize();
> 
>   public int getTxDhtCommitQueueSize();
> 
>   public int getTxDhtPrepareQueueSize();
> 
>   public int getTxDhtStartVersionCountsSize();
> 
>   public int getTxDhtCommittedVersionsSize();
> 
>   public int getTxDhtRolledbackVersionsSize();
> 
>   public boolean isWriteBehindEnabled();
> 
>   public int getWriteBehindFlushSize();
> 
>   public int getWriteBehindFlushThreadCount();
> 
>   public long getWriteBehindFlushFrequency();
> 
>   public int getWriteBehindStoreBatchSize();
> 
>   public int getWriteBehindTotalCriticalOverflowCount();
> 
>   public int getWriteBehindCriticalOverflowCount();
> 
>   public int getWriteBehindErrorRetryCount();
> 
>   public int getWriteBehindBufferSize();
> 
>   public String getKeyType();
> 
>   public String getValueType();
> 
>   public boolean isStoreByValue();
> 
>   public boolean isStatisticsEnabled();
> 
>   public boolean isManagementEnabled();
> 
>   public boolean isReadThrough();
> 
>   public boolean isWriteThrough();
> 
>   public long getTotalAllocatedPages();
> 
>   public long getTotalEvictedPages();
> 
> }
> 
> 
> Also I suggest to introduce new interface for MemoryPolicy metrics and make
> it available through *IgniteCacheDatabaseSharedManager*:
> 
> 
> public interface IgniteMemoryPolicyMetrics {
> 
>/**
> 
> * @return Memory 

Re: IGNITE-4536 metrics of new offheap storage

[Dmitriy Setrakyan]

Sergey, looks good. Can you also provide a list of metrics that you have
removed?

I think it's best to include this into the Jira ticket.

D.

On Thu, Mar 16, 2017 at 10:22 AM, Sergey Chugunov  wrote:

> Denis,
>
> Here is a version of CacheMetrics interface with all changes how I see them
> (pretty long list :)).
>
> public interface CacheMetrics {
>
>public long getCacheHits();
>
>public float getCacheHitPercentage();
>
>public long getCacheMisses();
>
>public float getCacheMissPercentage();
>
>public long getCacheGets();
>
>public long getCachePuts();
>
>public long getCacheRemovals();
>
>public long getCacheEvictions();
>
>public float getAverageGetTime();
>
>public float getAveragePutTime();
>
>public float getAverageRemoveTime();
>
>public float getAverageTxCommitTime();
>
>public float getAverageTxRollbackTime();
>
>public long getCacheTxCommits();
>
>public long getCacheTxRollbacks();
>
>public String name();
>
>public long getOverflowSize();
>
>public long getOffHeapGets();
>
>public long getOffHeapPuts();//removing as it duplicates cachePuts
>
>public long getOffHeapRemovals();
>
>public long getOffHeapEvictions();
>
>public long getOffHeapHits();
>
>public float getOffHeapHitPercentage();
>
>public long getOffHeapMisses();//removing as it duplicates cacheMisses
>
>public float getOffHeapMissPercentage();//removing as it duplicates
> cacheMissPercentage
>
>public long getOffHeapEntriesCount();
>
>public long getOffHeapPrimaryEntriesCount();
>
>public long getOffHeapBackupEntriesCount();
>
>public long getOffHeapAllocatedSize();
>
>public long getOffHeapMaxSize();
>
>public long getSwapGets();
>
>public long getSwapPuts();
>
>public long getSwapRemovals();
>
>public long getSwapHits();
>
>public long getSwapMisses();
>
>public long getSwapEntriesCount();
>
>public long getSwapSize();
>
>public float getSwapHitPercentage();
>
>public float getSwapMissPercentage();
>
>public int getSize();
>
>public int getKeySize();
>
>public boolean isEmpty();
>
>public int getDhtEvictQueueCurrentSize();
>
>public int getTxThreadMapSize();
>
>public int getTxXidMapSize();
>
>public int getTxCommitQueueSize();
>
>public int getTxPrepareQueueSize();
>
>public int getTxStartVersionCountsSize();
>
>public int getTxCommittedVersionsSize();
>
>public int getTxRolledbackVersionsSize();
>
>public int getTxDhtThreadMapSize();
>
>public int getTxDhtXidMapSize();
>
>public int getTxDhtCommitQueueSize();
>
>public int getTxDhtPrepareQueueSize();
>
>public int getTxDhtStartVersionCountsSize();
>
>public int getTxDhtCommittedVersionsSize();
>
>public int getTxDhtRolledbackVersionsSize();
>
>public boolean isWriteBehindEnabled();
>
>public int getWriteBehindFlushSize();
>
>public int getWriteBehindFlushThreadCount();
>
>public long getWriteBehindFlushFrequency();
>
>public int getWriteBehindStoreBatchSize();
>
>public int getWriteBehindTotalCriticalOverflowCount();
>
>public int getWriteBehindCriticalOverflowCount();
>
>public int getWriteBehindErrorRetryCount();
>
>public int getWriteBehindBufferSize();
>
>public String getKeyType();
>
>public String getValueType();
>
>public boolean isStoreByValue();
>
>public boolean isStatisticsEnabled();
>
>public boolean isManagementEnabled();
>
>public boolean isReadThrough();
>
>public boolean isWriteThrough();
>
>public long getTotalAllocatedPages();
>
>public long getTotalEvictedPages();
>
> }
>
>
> Also I suggest to introduce new interface for MemoryPolicy metrics and make
> it available through *IgniteCacheDatabaseSharedManager*:
>
>
> public interface IgniteMemoryPolicyMetrics {
>
> /**
>
>  * @return Memory policy name.
>
>  */
>
> public String getName();
>
>
> /**
>
>  * @return Total number of allocated pages.
>
>  */
>
> public long getTotalAllocatedPages();
>
>
> /**
>
>  * @return Amount (in bytes) of not yet allocated space in PageMemory.
>
>  */
>
> public long getAvailableSpace();
>
>
> /**
>
>  * @return Number of allocated pages per second within PageMemory.
>
>  */
>
> public float getAllocationRate();
>
>
> /**
>
>  * @return Number of evicted pages per second within PageMemory.
>
>  */
>
> public float getEvictionRate();
>
>
> /**
>
>  * Large entities bigger than page are split into fragments so each
> fragment can fit into a page.
>
>  *
>
>  * @return Percentage of pages fully occupied by large entities.
>
>  */
>
> public long getLargeEntriesPagesPercentage();
>
>
> //---FreeList-related metrics
>
>
> /**
>
>  * @return Free space to overall size ratio across all pages in
> FreeList.
>
>  */
>
> public float 

Re: Cluster name

[Dmitriy Setrakyan]

I am not sure I like naming clusters from an agent. It just sounds counter
intuitive for me. How about adding an optional IGNITE_CLUSTER_NAME env
property together with optional  -DCLUSTER_NAME system property and
reserved CLUSTER_NAME user attribute?

If user fails to provide any of the above, then we automatically assign the
timestamp of the first node or some UUID as a cluster name.

Thoughts?

D.

On Thu, Mar 16, 2017 at 5:01 AM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Alexey,
>
> Cluster doesn't know about the console, but web agent does, right? I think
> it should be his responsibility to assign the name. I.e. when starting the
> agent next to a particular cluster, user has to specify the name. If the
> console already has the cluster with this name, agent should not start with
> an exception suggesting to provide another name.
>
> Will this work?
>
> -Val
>
> On Thu, Mar 16, 2017 at 12:07 PM, Alexey Kuznetsov 
> wrote:
>
> > Dmitriy, Sergi and Val.
> >
> > Web Console will be connected to several clusters at once.
> > And clusters do not know about Web Console, because Web Console collect
> > info from cluster via our REST-HTTP module.
> > So, I can distinguish clusters only by collection of node IDs and give
> them
> > names like: "Cluster1, Clsuter2,"
> > But if cluster restarted Web Console will detect it as new cluster and
> give
> > next auto-generated name "ClusterN".
> >
> > So, I'm not insist on adding "ClusterName" to IgniteConfiguration, but
> > could you give me a way
> >  some how "mark" clusters to detect them even after full restart.
> >
> > May be setting some sort of environment variable (it will be added to
> node
> > attributes)?
> > So, if user need "Multi-cluster" support he should set different
> > CLUSTER_NAME environment variable for different clusters.
> >
> > Any other ideas are welcome.
> >
> > On Thu, Mar 16, 2017 at 5:57 PM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > Alexey,
> > >
> > > How does the workflow look like? How do you add a cluster to this
> > dropdown
> > > on the console? I think that assigning a name should be part of this
> > > process and should happen on the console itself.
> > >
> > > Adding yet another "name" to configuration will only confuse users even
> > > more.
> > >
> > > -Val
> > >
> > > On Thu, Mar 16, 2017 at 9:59 AM, Sergi Vladykin <
> > sergi.vlady...@gmail.com>
> > > wrote:
> > >
> > > > I don't like to add anything like this into Ignite config. It is a
> > > problem
> > > > of Web console how to name or rename different clusters for a user,
> but
> > > not
> > > > Ignite cluster itself.
> > > >
> > > > Sergi
> > > >
> > > > 2017-03-16 4:21 GMT+03:00 Dmitriy Setrakyan :
> > > >
> > > > > I am OK with having a cluster name, but I would like us to generate
> > one
> > > > > automatically, if users do not define one explicitly. How about
> > > > > "cluster_timestamp"?
> > > > >
> > > > > On Wed, Mar 15, 2017 at 5:38 PM, Alexey Kuznetsov <
> > > akuznet...@apache.org
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Igniters,
> > > > > >
> > > > > > I'm planning to start working on multi cluster support for Web
> > > Console
> > > > > > in order to be able to execute SQL queries on different clusters
> > just
> > > > by
> > > > > > selecting
> > > > > > target cluster from drop-down.
> > > > > >
> > > > > > But Ignite does not have any cluster wide name.
> > > > > >
> > > > > > So, how about to add to Ignite (may be 2.0) property "Cluster
> Name"
> > > to
> > > > > > Ignite configuration?
> > > > > >
> > > > > > Or as alternative way it could use "Mandatory User Defined
> > > Attribute".
> > > > > >
> > > > > > Node should be rejected to join cluster with different "Cluster
> > Name"
> > > > > >
> > > > > >
> > > > > > Thoughts?
> > > > > >
> > > > > > --
> > > > > > Alexey Kuznetsov
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Alexey Kuznetsov
> >
>

Re: IGNITE-4536 metrics of new offheap storage

[Sergey Chugunov]

Denis,

Here is a version of CacheMetrics interface with all changes how I see them
(pretty long list :)).

public interface CacheMetrics {

   public long getCacheHits();

   public float getCacheHitPercentage();

   public long getCacheMisses();

   public float getCacheMissPercentage();

   public long getCacheGets();

   public long getCachePuts();

   public long getCacheRemovals();

   public long getCacheEvictions();

   public float getAverageGetTime();

   public float getAveragePutTime();

   public float getAverageRemoveTime();

   public float getAverageTxCommitTime();

   public float getAverageTxRollbackTime();

   public long getCacheTxCommits();

   public long getCacheTxRollbacks();

   public String name();

   public long getOverflowSize();

   public long getOffHeapGets();

   public long getOffHeapPuts();//removing as it duplicates cachePuts

   public long getOffHeapRemovals();

   public long getOffHeapEvictions();

   public long getOffHeapHits();

   public float getOffHeapHitPercentage();

   public long getOffHeapMisses();//removing as it duplicates cacheMisses

   public float getOffHeapMissPercentage();//removing as it duplicates
cacheMissPercentage

   public long getOffHeapEntriesCount();

   public long getOffHeapPrimaryEntriesCount();

   public long getOffHeapBackupEntriesCount();

   public long getOffHeapAllocatedSize();

   public long getOffHeapMaxSize();

   public long getSwapGets();

   public long getSwapPuts();

   public long getSwapRemovals();

   public long getSwapHits();

   public long getSwapMisses();

   public long getSwapEntriesCount();

   public long getSwapSize();

   public float getSwapHitPercentage();

   public float getSwapMissPercentage();

   public int getSize();

   public int getKeySize();

   public boolean isEmpty();

   public int getDhtEvictQueueCurrentSize();

   public int getTxThreadMapSize();

   public int getTxXidMapSize();

   public int getTxCommitQueueSize();

   public int getTxPrepareQueueSize();

   public int getTxStartVersionCountsSize();

   public int getTxCommittedVersionsSize();

   public int getTxRolledbackVersionsSize();

   public int getTxDhtThreadMapSize();

   public int getTxDhtXidMapSize();

   public int getTxDhtCommitQueueSize();

   public int getTxDhtPrepareQueueSize();

   public int getTxDhtStartVersionCountsSize();

   public int getTxDhtCommittedVersionsSize();

   public int getTxDhtRolledbackVersionsSize();

   public boolean isWriteBehindEnabled();

   public int getWriteBehindFlushSize();

   public int getWriteBehindFlushThreadCount();

   public long getWriteBehindFlushFrequency();

   public int getWriteBehindStoreBatchSize();

   public int getWriteBehindTotalCriticalOverflowCount();

   public int getWriteBehindCriticalOverflowCount();

   public int getWriteBehindErrorRetryCount();

   public int getWriteBehindBufferSize();

   public String getKeyType();

   public String getValueType();

   public boolean isStoreByValue();

   public boolean isStatisticsEnabled();

   public boolean isManagementEnabled();

   public boolean isReadThrough();

   public boolean isWriteThrough();

   public long getTotalAllocatedPages();

   public long getTotalEvictedPages();

}


Also I suggest to introduce new interface for MemoryPolicy metrics and make
it available through *IgniteCacheDatabaseSharedManager*:


public interface IgniteMemoryPolicyMetrics {

/**

 * @return Memory policy name.

 */

public String getName();


/**

 * @return Total number of allocated pages.

 */

public long getTotalAllocatedPages();


/**

 * @return Amount (in bytes) of not yet allocated space in PageMemory.

 */

public long getAvailableSpace();


/**

 * @return Number of allocated pages per second within PageMemory.

 */

public float getAllocationRate();


/**

 * @return Number of evicted pages per second within PageMemory.

 */

public float getEvictionRate();


/**

 * Large entities bigger than page are split into fragments so each
fragment can fit into a page.

 *

 * @return Percentage of pages fully occupied by large entities.

 */

public long getLargeEntriesPagesPercentage();


//---FreeList-related metrics


/**

 * @return Free space to overall size ratio across all pages in
FreeList.

 */

public float getPagesFillFactor();


/**

 * @return Percentage of pages in FreeList with free space >= 8 and <
16 bytes

 */

public float getPagesPercentage_8_16_freeBytes();


/**

 * @return Percentage of pages in FreeList with free space >= 16 and <
64 bytes

 */

public float getPagesPercentage_16_64_freeBytes();


/**

 * @return Percentage of pages in FreeList with free space >= 64 and <
256 bytes

 */

public float getPagesPercentage_64_256_freeBytes();

}

In my mind last three methods provide some kind of hist to give an insight
about memory 

Re: New Blogs: What's new in Ignite.NET 1.9 and Ignite Kubernetes deployment on Azure

[Denis Magda]

A couple of more blogs got published.

* Continous queries in Ignite C++ by Igor - 
https://isapego.github.io/Continuous-Queries-in-Apache-Ignite-CPP-1-9/#disqus_thread
 

* Modern Application Design With In-Memory Data Fabric by Shamim - 
https://dzone.com/articles/modern-application-design-with-in-memory-data-fabr 


Enjoy.

Denis

> On Mar 15, 2017, at 6:03 PM, Denis Magda  wrote:
> 
> Igniters,
> 
> Let me share with the latest blog post about Apache Ignite you might be 
> interested to look at.
> 
> * What’s new in Apache Ignite.NET  1.9 by Pavel: 
> https://ptupitsyn.github.io/Whats-New-In-Ignite-Net-1-9/
> 
> * Deploying Ignite in Kubernetes in Microsof Azure by me: 
> https://www.gridgain.com/resources/blog/deploying-apache-ignite-kubernetes-microsoft-azure
>  
> 
> 
> Soon the post will be added to Ignite’s blog feed:
> https://ignite.apache.org/blogs.html 
> 
> If you blog about Ignite please let me know and we will promote your job over 
> the feed, twitter and other channels.
> 
> —
> Denis

Re: Timestamp and Time types in SQL queries

[Sergi Vladykin]

Fix C++ :)

Sergi

2017-03-16 18:36 GMT+03:00 Igor Sapego :

> Well, I wrote tests and they are failing. So what is the solution here?
> Can it be fixed somewhere in Ignite or is it not possible without edits in
> H2?
>
> Best Regards,
> Igor
>
> On Thu, Mar 16, 2017 at 6:31 PM, Sergi Vladykin 
> wrote:
>
> > This happens because H2 does not work with these classes directly and we
> do
> > some conversions to SQL types, then from H2 JDBC API we get what H2 gives
> > us. The resulting types can be different. I guess you have to just write
> > tests for all these types and cover all these cases in C++ code.
> >
> > Sergi
> >
> > 2017-03-16 18:14 GMT+03:00 Igor Sapego :
> >
> > > Hi guys,
> > >
> > > I'm working on java.sql.Time type support for ODBC [1], and I'm facing
> > > following behaviour:
> > >
> > > Lets suppose I perform an SQL query from C++ on field of java.sql.Time
> > > type:
> > >
> > > SELECT dateField from SomeType
> > >
> > > Nothing special here. The problem is in C++ I get value of type Date
> > > instead of Time. The similar behaviour can be observed for the
> > > java.sql.Date type (returned as Timestamp in binary protocol). I have
> not
> > > investigated issue yet but I suppose it has to do something with
> > > java.sql.Time and java.sql.Timestamp both being a subclasses of the
> > > java.util.Date.
> > >
> > > So the question is, is this an expected behaviour or is it a bug?
> > >
> > > [1] - https://issues.apache.org/jira/browse/IGNITE-4691
> > >
> >
>

[GitHub] ignite pull request #1630: IGNITE-4795

[SomeFire]

GitHub user SomeFire opened a pull request:

https://github.com/apache/ignite/pull/1630

IGNITE-4795

IGNITE-4795 TransactionException marker created.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/SomeFire/ignite master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/1630.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 #1630


commit 630f6db753e1fee024209cd122b7f3aae991cee4
Author: Дмитрий Рябов 
Date:   2017-03-06T12:53:27Z

Merge pull request #2 from apache/master

update

commit 009c3943fab8483cf72f4408595140be14e2410b
Author: Dmitrii Ryabov 
Date:   2017-03-07T12:50:51Z

TransactionException created and nested by concrete exceptions.

commit f006e1f202da292b1d29f09dc9fbee33f826dda3
Author: Dmitrii Ryabov 
Date:   2017-03-10T12:14:37Z

TransactionException created and nested by concrete exceptions.

commit 61a6a8e37775280a66ae28348f417f5874cb5373
Author: Dmitrii Ryabov 
Date:   2017-03-10T12:16:38Z

TransactionCheckedException created and nested by 
IgniteTx...CheckedException.
Some IgniteCheckedException throws changed to TCE throws.

commit 1be332720846c2ec8ebe7bfca13c9d1fb63ff1d3
Author: Dmitrii Ryabov 
Date:   2017-03-14T14:31:16Z

Added note about visibility of changes inside transaction.

commit a771d755cc807a62832ae3a97918aca5c980ce35
Author: Дмитрий Рябов 
Date:   2017-03-16T15:55:35Z

IGNITE-4795

IGNITE-4795 TransactionExceptions.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: ignite-4823 - ready for review (SpringCache#putIfAbsent - wrong implementation)

[Valentin Kulichenko]

Vyacheslav,

I will review and merge in nearest time.

-Val

On Thu, Mar 16, 2017 at 8:08 AM, Vyacheslav Daradur 
wrote:

> Hello everyone.
>
> Please review changes: *https://issues.apache.org/jira/browse/IGNITE-4823
> *
>
> I found this when I worked on an another issue.
>
> If I'm not mistaken it's wrong implementation.
>
> --
> Best Regards, Vyacheslav
>

Re: Timestamp and Time types in SQL queries

[Igor Sapego]

Well, I wrote tests and they are failing. So what is the solution here?
Can it be fixed somewhere in Ignite or is it not possible without edits in
H2?

Best Regards,
Igor

On Thu, Mar 16, 2017 at 6:31 PM, Sergi Vladykin 
wrote:

> This happens because H2 does not work with these classes directly and we do
> some conversions to SQL types, then from H2 JDBC API we get what H2 gives
> us. The resulting types can be different. I guess you have to just write
> tests for all these types and cover all these cases in C++ code.
>
> Sergi
>
> 2017-03-16 18:14 GMT+03:00 Igor Sapego :
>
> > Hi guys,
> >
> > I'm working on java.sql.Time type support for ODBC [1], and I'm facing
> > following behaviour:
> >
> > Lets suppose I perform an SQL query from C++ on field of java.sql.Time
> > type:
> >
> > SELECT dateField from SomeType
> >
> > Nothing special here. The problem is in C++ I get value of type Date
> > instead of Time. The similar behaviour can be observed for the
> > java.sql.Date type (returned as Timestamp in binary protocol). I have not
> > investigated issue yet but I suppose it has to do something with
> > java.sql.Time and java.sql.Timestamp both being a subclasses of the
> > java.util.Date.
> >
> > So the question is, is this an expected behaviour or is it a bug?
> >
> > [1] - https://issues.apache.org/jira/browse/IGNITE-4691
> >
>

Re: Timestamp and Time types in SQL queries

[Sergi Vladykin]

This happens because H2 does not work with these classes directly and we do
some conversions to SQL types, then from H2 JDBC API we get what H2 gives
us. The resulting types can be different. I guess you have to just write
tests for all these types and cover all these cases in C++ code.

Sergi

2017-03-16 18:14 GMT+03:00 Igor Sapego :

> Hi guys,
>
> I'm working on java.sql.Time type support for ODBC [1], and I'm facing
> following behaviour:
>
> Lets suppose I perform an SQL query from C++ on field of java.sql.Time
> type:
>
> SELECT dateField from SomeType
>
> Nothing special here. The problem is in C++ I get value of type Date
> instead of Time. The similar behaviour can be observed for the
> java.sql.Date type (returned as Timestamp in binary protocol). I have not
> investigated issue yet but I suppose it has to do something with
> java.sql.Time and java.sql.Timestamp both being a subclasses of the
> java.util.Date.
>
> So the question is, is this an expected behaviour or is it a bug?
>
> [1] - https://issues.apache.org/jira/browse/IGNITE-4691
>

Timestamp and Time types in SQL queries

[Igor Sapego]

Hi guys,

I'm working on java.sql.Time type support for ODBC [1], and I'm facing
following behaviour:

Lets suppose I perform an SQL query from C++ on field of java.sql.Time type:

SELECT dateField from SomeType

Nothing special here. The problem is in C++ I get value of type Date
instead of Time. The similar behaviour can be observed for the
java.sql.Date type (returned as Timestamp in binary protocol). I have not
investigated issue yet but I suppose it has to do something with
java.sql.Time and java.sql.Timestamp both being a subclasses of the
java.util.Date.

So the question is, is this an expected behaviour or is it a bug?

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

[GitHub] ignite pull request #1629: IGNITE-3429: org.hibernate.cache.spi.CacheKey not...

[AMashenkov]

GitHub user AMashenkov opened a pull request:

https://github.com/apache/ignite/pull/1629

IGNITE-3429: org.hibernate.cache.spi.CacheKey not properly serialized by 
binary marshaller 



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-3429

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/1629.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 #1629


commit 630da94351e71b418b7b605eeec66ab67c1b4884
Author: AMRepo 
Date:   2017-02-09T15:21:18Z

Implemented




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: distributed transaction of non-single coordinator

[Sergi Vladykin]

The problem "How to run millions of entities, and millions of operations on
a single Pentium3" is out of scope here. Do the math, plan capacity
reasonably.

Sergi

2017-03-16 15:54 GMT+03:00 ALEKSEY KUZNETSOV :

> hmm, If we have millions of entities, and millions of operations, would not
> this approache lead to memory overflow and perfomance degradation
>
> чт, 16 мар. 2017 г. в 15:42, Sergi Vladykin :
>
> > 1. Actually you have to check versions on all the values you have read
> > during the tx.
> >
> > For example if we have [k1 => v1, k2 => v2] and do:
> >
> > put(k1, get(k2) + 5)
> >
> > We have to remember the version for k2. This logic can be relatively
> easily
> > encapsulated in a framework atop of Ignite. You need to implement one to
> > make all this stuff usable.
> >
> > 2. I suggest to avoid any locking here, because you easily will end up
> with
> > deadlocks. If you do not have too frequent updates for your keys,
> > optimistic approach will work just fine.
> >
> > Theoretically in the Committer Service you can start a thread for the
> > lifetime of the whole distributed transaction, take a lock on the key
> using
> > IgniteCache.lock(K key) before executing any Services, wait for all the
> > services to complete, execute optimistic commit in the same thread while
> > keeping this lock and then release it. Notice that all the Ignite
> > transactions inside of all Services must be optimistic here to be able to
> > read this locked key.
> >
> > But again I do not recommend you using this approach until you have a
> > reliable deadlock avoidance scheme.
> >
> > Sergi
> >
> >
> >
> >
> >
> >
> >
> > 2017-03-16 12:53 GMT+03:00 ALEKSEY KUZNETSOV :
> >
> > > Yeah, now i got it.
> > > There are some doubts on this approach
> > > 1) During optimistic commit phase, when you assure no one altered the
> > > original values, you must check versions of other dependent keys. How
> > could
> > > we obtain those keys(in an automative manner, of course) ?
> > > 2) How could we lock a key before some Service A introduce changes? So
> no
> > > other service is allowed to change this key-value?(sort of pessimistic
> > > blocking)
> > > May be you know some implementations of such approach ?
> > >
> > > ср, 15 мар. 2017 г. в 17:54, ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com
> > >:
> > >
> > > >  Thank you very much for help.  I will answer later.
> > > >
> > > > ср, 15 мар. 2017 г. в 17:39, Sergi Vladykin <
> sergi.vlady...@gmail.com
> > >:
> > > >
> > > > All the services do not update key in place, but only generate new
> keys
> > > > augmented by otx and store the updated value in the same cache +
> > remember
> > > > the keys and versions participating in the transaction in some
> separate
> > > > atomic cache.
> > > >
> > > > Follow this sequence of changes applied to cache contents by each
> > > Service:
> > > >
> > > > Initial cache contents:
> > > > [k1 => v1]
> > > > [k2 => v2]
> > > > [k3 => v3]
> > > >
> > > > Cache contents after Service A:
> > > > [k1 => v1]
> > > > [k2 => v2]
> > > > [k3 => v3]
> > > > [k1x => v1a]
> > > > [k2x => v2a]
> > > >
> > > >  + [x => (k1 -> ver1, k2 -> ver2)] in some separate atomic
> > cache
> > > >
> > > > Cache contents after Service B:
> > > > [k1 => v1]
> > > > [k2 => v2]
> > > > [k3 => v3]
> > > > [k1x => v1a]
> > > > [k2x => v2ab]
> > > > [k3x => v3b]
> > > >
> > > > + [x => (k1 -> ver1, k2 -> ver2, k3 -> ver3)] in some
> separate
> > > > atomic cache
> > > >
> > > > Finally the Committer Service takes this map of updated keys and
> their
> > > > versions from some separate atomic cache, starts Ignite transaction
> and
> > > > replaces all the values for k* keys to values taken from k*x keys.
> The
> > > > successful result must be the following:
> > > >
> > > > [k1 => v1a]
> > > > [k2 => v2ab]
> > > > [k3 => v3b]
> > > > [k1x => v1a]
> > > > [k2x => v2ab]
> > > > [k3x => v3b]
> > > >
> > > > + [x => (k1 -> ver1, k2 -> ver2, k3 -> ver3)] in some
> separate
> > > > atomic cache
> > > >
> > > > But Committer Service also has to check that no one updated the
> > original
> > > > values before us, because otherwise we can not give any
> serializability
> > > > guarantee for these distributed transactions. Here we may need to
> check
> > > not
> > > > only versions of the updated keys, but also versions of any other
> keys
> > > end
> > > > result depends on.
> > > >
> > > > After that Committer Service has to do a cleanup (may be outside of
> the
> > > > committing tx) to come to the following final state:
> > > >
> > > > [k1 => v1a]
> > > > [k2 => v2ab]
> > > > [k3 => v3b]
> > > >
> > > > 

[jira] [Created] (IGNITE-4832) Service is deployed on client when service configuration is provided on startup

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-4832:
---

 Summary: Service is deployed on client when service configuration 
is provided on startup
 Key: IGNITE-4832
 URL: https://issues.apache.org/jira/browse/IGNITE-4832
 Project: Ignite
  Issue Type: Bug
  Components: managed services
Affects Versions: 1.9
Reporter: Valentin Kulichenko
 Fix For: 2.0


In case service configuration is provided on startup (i.e. as a part of 
{{IgniteConfiguration}}), the service can be deployed on the client node which 
is incorrect. Client nodes should be filtered out by default, like it's done in 
{{IgniteServices.deployXXX(..)}} methods.

Test reproducing the behavior is attached.



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

Re: Remove CacheAtomicWriteOrderMode.CLOCK mode.

[Kozlov Maxim]

Hi igniters, 

GridDhtAtomicCache class isFastMap method always returns false now. 
Do you think you need to remove it? 


> 14 марта 2017 г., в 14:30, Andrey Gura  написал(а):
> 
> I've added comments about IgniteConfiguration to JIRA ticket.
> 
> On Tue, Mar 14, 2017 at 2:06 PM, Alexey Kuznetsov
>  wrote:
>> Maxim,
>> 
>> I managed to review Web Console part in your PR.
>> Looks good for me.
>> 
>> But it seems that you also should delete following properties on
>> IgniteConfiguration
>>  getClockSyncFrequency();
>>  getClockSyncSamples();
>> 
>> Once you delete them - you should also delete them on WebConsole also.
>> 
>> P.S. do not forget to merge master to you PR.
>> 
>> 
>> On Tue, Mar 14, 2017 at 10:35 AM, Alexey Kuznetsov 
>> wrote:
>> 
>>> Maxim,
>>> 
>>> Could you merge master to your PR?
>>> I failed to review Web Console files due to conflicts.
>>> 
>>> Thanks.
>>> 
>>> On Fri, Mar 10, 2017 at 3:06 PM, Kozlov Maxim 
>>> wrote:
>>> 
 Andrey, Alexey, please review
 PR - https://github.com/apache/ignite/pull/1521 <
 https://github.com/apache/ignite/pull/1521>
 tests - http://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite
 Tests_RunAll_IgniteTests=pull%2F1521%2Fhead=buildTypeStatusDiv
 
 
> 7 марта 2017 г., в 14:15, Andrey Gura  написал(а):
> 
> Maxim,
> 
> all GridClockSyncProcessor related code should be remove (objects,
> messages, etc)
> 
> On Tue, Mar 7, 2017 at 12:23 PM, Kozlov Maxim 
 wrote:
>> Andrey, or better remove GridTimeSyncProcessorSelfTest class?
>> 
>>> 7 марта 2017 г., в 12:21, Kozlov Maxim 
 написал(а):
>>> 
>>> Andrey, in GridTimeSyncProcessorSelfTest class methods:
 testTimeSync() and testTimeSyncChangeCoordinator() also removed?
>>> 
>>> 
 6 марта 2017 г., в 18:42, Andrey Gura  написал(а):
 
 Maxim,
 
 About SER_VER_COMPARATOR. You can use code branch that executes when
 times are equal:
 
 int nodeOrder1 = ver1.nodeOrder();
 int nodeOrder2 = ver2.nodeOrder();
 
 if (nodeOrder1 == nodeOrder2) {
 long order1 = ver1.order();
 long order2 = ver2.order();
 
 assert order1 != order2;
 
 return order1 > order2 ? 1 : -1;
 }
 else
 return nodeOrder1 > nodeOrder2 ? 1 : -1;
 
 On Mon, Mar 6, 2017 at 6:32 PM, Alexey Goncharuk
  wrote:
> Maxim,
> 
> Global time comparison is only needed for CLOCK mode, so you should
 modify
> the code as if ignoreTime is always true.
> 
> 2017-03-06 18:13 GMT+03:00 Kozlov Maxim :
> 
>> ok,
>> in GridCacheAtomicVersionComparator class, method
>> compare(GridCacheVersion one, GridCacheVersion other, boolean
 ignoreTime)
>> if (globalTime == otherGlobalTime || ignoreTime) {  // => if
 (ignoreTime) {
>> .
>> }
>> else
>> return globalTime > otherGlobalTime ? 1 : -1;   // => return -1;
>> 
>> and,
>> GridCacheMvcc class,
>> SER_VER_COMPARATOR is comparator by globalTime var. His remove and
 remove
>> compareSerializableVersion?
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> 6 марта 2017 г., в 16:51, Andrey Gura 
 написал(а):
>>> 
>>> Maxim,
>>> 
>>> updateTime() method should be removed.
>>> 
>>> On Mon, Mar 6, 2017 at 12:12 PM, Kozlov Maxim <
 dreamx@gmail.com>
>> wrote:
 In CacheEntryImplEx class use ver.globalTime() in
 
 @Override public long updateTime() {
 return ver.globalTime();
 }
 
 Than is better to replace this variable?
 
 
> 3 марта 2017 г., в 19:19, Andrey Gura 
 написал(а):
> 
> Maxim,
> 
> I think the next implementation will be good enough:
> 
> public IgniteUuid asGridUuid() {
> return new IgniteUuid(new UUID(nodeOrderDrId, topVer), order);
> }
> 
> 
> Serialization/deserialization of GridCacheVersion.globalTime
 field
> should be removed.
> 
> On Fri, Mar 3, 2017 at 5:57 PM, Kozlov Maxim <
 dreamx@gmail.com>
>> wrote:
>> Alexey,
>> 
>> public 

[jira] [Created] (IGNITE-4831) Add an option to disable MBeans

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-4831:
---

 Summary: Add an option to disable MBeans
 Key: IGNITE-4831
 URL: https://issues.apache.org/jira/browse/IGNITE-4831
 Project: Ignite
  Issue Type: Improvement
  Components: general
Affects Versions: 1.8
Reporter: Valentin Kulichenko


There are multiple MBeans registered by Ignite and there is no way to avoid 
their registration (in case they're not allowed for security reasons for 
example). We should have a system property that will disable MBeans.

In addition, if MBean registration throws a {{RuntimeException}}, this 
exception is not properly handled. For example, if it happens during cache 
creation, {{createCache}} method hangs forever.



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

[GitHub] ignite pull request #1516: IGNITE-3429: org.hibernate.cache.spi.CacheKey not...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/1516


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: distributed transaction of non-single coordinator

[ALEKSEY KUZNETSOV]

hmm, If we have millions of entities, and millions of operations, would not
this approache lead to memory overflow and perfomance degradation

чт, 16 мар. 2017 г. в 15:42, Sergi Vladykin :

> 1. Actually you have to check versions on all the values you have read
> during the tx.
>
> For example if we have [k1 => v1, k2 => v2] and do:
>
> put(k1, get(k2) + 5)
>
> We have to remember the version for k2. This logic can be relatively easily
> encapsulated in a framework atop of Ignite. You need to implement one to
> make all this stuff usable.
>
> 2. I suggest to avoid any locking here, because you easily will end up with
> deadlocks. If you do not have too frequent updates for your keys,
> optimistic approach will work just fine.
>
> Theoretically in the Committer Service you can start a thread for the
> lifetime of the whole distributed transaction, take a lock on the key using
> IgniteCache.lock(K key) before executing any Services, wait for all the
> services to complete, execute optimistic commit in the same thread while
> keeping this lock and then release it. Notice that all the Ignite
> transactions inside of all Services must be optimistic here to be able to
> read this locked key.
>
> But again I do not recommend you using this approach until you have a
> reliable deadlock avoidance scheme.
>
> Sergi
>
>
>
>
>
>
>
> 2017-03-16 12:53 GMT+03:00 ALEKSEY KUZNETSOV :
>
> > Yeah, now i got it.
> > There are some doubts on this approach
> > 1) During optimistic commit phase, when you assure no one altered the
> > original values, you must check versions of other dependent keys. How
> could
> > we obtain those keys(in an automative manner, of course) ?
> > 2) How could we lock a key before some Service A introduce changes? So no
> > other service is allowed to change this key-value?(sort of pessimistic
> > blocking)
> > May be you know some implementations of such approach ?
> >
> > ср, 15 мар. 2017 г. в 17:54, ALEKSEY KUZNETSOV  >:
> >
> > >  Thank you very much for help.  I will answer later.
> > >
> > > ср, 15 мар. 2017 г. в 17:39, Sergi Vladykin  >:
> > >
> > > All the services do not update key in place, but only generate new keys
> > > augmented by otx and store the updated value in the same cache +
> remember
> > > the keys and versions participating in the transaction in some separate
> > > atomic cache.
> > >
> > > Follow this sequence of changes applied to cache contents by each
> > Service:
> > >
> > > Initial cache contents:
> > > [k1 => v1]
> > > [k2 => v2]
> > > [k3 => v3]
> > >
> > > Cache contents after Service A:
> > > [k1 => v1]
> > > [k2 => v2]
> > > [k3 => v3]
> > > [k1x => v1a]
> > > [k2x => v2a]
> > >
> > >  + [x => (k1 -> ver1, k2 -> ver2)] in some separate atomic
> cache
> > >
> > > Cache contents after Service B:
> > > [k1 => v1]
> > > [k2 => v2]
> > > [k3 => v3]
> > > [k1x => v1a]
> > > [k2x => v2ab]
> > > [k3x => v3b]
> > >
> > > + [x => (k1 -> ver1, k2 -> ver2, k3 -> ver3)] in some separate
> > > atomic cache
> > >
> > > Finally the Committer Service takes this map of updated keys and their
> > > versions from some separate atomic cache, starts Ignite transaction and
> > > replaces all the values for k* keys to values taken from k*x keys. The
> > > successful result must be the following:
> > >
> > > [k1 => v1a]
> > > [k2 => v2ab]
> > > [k3 => v3b]
> > > [k1x => v1a]
> > > [k2x => v2ab]
> > > [k3x => v3b]
> > >
> > > + [x => (k1 -> ver1, k2 -> ver2, k3 -> ver3)] in some separate
> > > atomic cache
> > >
> > > But Committer Service also has to check that no one updated the
> original
> > > values before us, because otherwise we can not give any serializability
> > > guarantee for these distributed transactions. Here we may need to check
> > not
> > > only versions of the updated keys, but also versions of any other keys
> > end
> > > result depends on.
> > >
> > > After that Committer Service has to do a cleanup (may be outside of the
> > > committing tx) to come to the following final state:
> > >
> > > [k1 => v1a]
> > > [k2 => v2ab]
> > > [k3 => v3b]
> > >
> > > Makes sense?
> > >
> > > Sergi
> > >
> > >
> > > 2017-03-15 16:54 GMT+03:00 ALEKSEY KUZNETSOV  >:
> > >
> > > >- what do u mean by saying "
> > > > *in a single transaction checks value versions for all the old values
> > > > and replaces them with calculated new ones *"? Every time you
> > change
> > > >value(in some service), you store it to *some special atomic
> cache*
> > ,
> > > so
> > > >when all services ceased working, Service commiter got a values
> with
> > > the
> > > 

Re: Cluster name

[Valentin Kulichenko]

Alexey,

Cluster doesn't know about the console, but web agent does, right? I think
it should be his responsibility to assign the name. I.e. when starting the
agent next to a particular cluster, user has to specify the name. If the
console already has the cluster with this name, agent should not start with
an exception suggesting to provide another name.

Will this work?

-Val

On Thu, Mar 16, 2017 at 12:07 PM, Alexey Kuznetsov 
wrote:

> Dmitriy, Sergi and Val.
>
> Web Console will be connected to several clusters at once.
> And clusters do not know about Web Console, because Web Console collect
> info from cluster via our REST-HTTP module.
> So, I can distinguish clusters only by collection of node IDs and give them
> names like: "Cluster1, Clsuter2,"
> But if cluster restarted Web Console will detect it as new cluster and give
> next auto-generated name "ClusterN".
>
> So, I'm not insist on adding "ClusterName" to IgniteConfiguration, but
> could you give me a way
>  some how "mark" clusters to detect them even after full restart.
>
> May be setting some sort of environment variable (it will be added to node
> attributes)?
> So, if user need "Multi-cluster" support he should set different
> CLUSTER_NAME environment variable for different clusters.
>
> Any other ideas are welcome.
>
> On Thu, Mar 16, 2017 at 5:57 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Alexey,
> >
> > How does the workflow look like? How do you add a cluster to this
> dropdown
> > on the console? I think that assigning a name should be part of this
> > process and should happen on the console itself.
> >
> > Adding yet another "name" to configuration will only confuse users even
> > more.
> >
> > -Val
> >
> > On Thu, Mar 16, 2017 at 9:59 AM, Sergi Vladykin <
> sergi.vlady...@gmail.com>
> > wrote:
> >
> > > I don't like to add anything like this into Ignite config. It is a
> > problem
> > > of Web console how to name or rename different clusters for a user, but
> > not
> > > Ignite cluster itself.
> > >
> > > Sergi
> > >
> > > 2017-03-16 4:21 GMT+03:00 Dmitriy Setrakyan :
> > >
> > > > I am OK with having a cluster name, but I would like us to generate
> one
> > > > automatically, if users do not define one explicitly. How about
> > > > "cluster_timestamp"?
> > > >
> > > > On Wed, Mar 15, 2017 at 5:38 PM, Alexey Kuznetsov <
> > akuznet...@apache.org
> > > >
> > > > wrote:
> > > >
> > > > > Igniters,
> > > > >
> > > > > I'm planning to start working on multi cluster support for Web
> > Console
> > > > > in order to be able to execute SQL queries on different clusters
> just
> > > by
> > > > > selecting
> > > > > target cluster from drop-down.
> > > > >
> > > > > But Ignite does not have any cluster wide name.
> > > > >
> > > > > So, how about to add to Ignite (may be 2.0) property "Cluster Name"
> > to
> > > > > Ignite configuration?
> > > > >
> > > > > Or as alternative way it could use "Mandatory User Defined
> > Attribute".
> > > > >
> > > > > Node should be rejected to join cluster with different "Cluster
> Name"
> > > > >
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > --
> > > > > Alexey Kuznetsov
> > > > >
> > > >
> > >
> >
>
>
>
> --
> Alexey Kuznetsov
>

Re: PR IGNITE-1094 Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization

[ALEKSEY KUZNETSOV]

It still unclear , how could i notify coordinator that cache creation failed

чт, 9 мар. 2017 г. в 17:46, Yakov Zhdanov :

Alexey, you should understand how caches startup and partition map exchange


work. I would suggest you start couple of nodes in single VM and simply do
step-by-step debug in your IDE.

I don't think you will need to introduce any new message, but I think you
will have to add info to GridDhtPartitionsSingleMessage and
GridDhtPartitionsFullMessage. These messages are being sent via
communication as you described.

Thanks!

--Yakov

-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: Unused argument in DirectMessageWriter

[ALEKSEY KUZNETSOV]

watch him, he is gonna remove all the messages he doesn't like :)

чт, 16 мар. 2017 г. в 14:56, Valentin Kulichenko <
valentin.kuliche...@gmail.com>:

> Hi,
>
> These classes are part of plugin framework. Even though 'name' argument is
> not used by Ignite implementations, it can be used by others. Therefore it
> should not be removed.
>
> -Val
>
> On Thu, Mar 16, 2017 at 10:36 AM, Александр Меньшиков <
> sharple...@gmail.com>
> wrote:
>
> > Hello, everyone!
> >
> > I found some strange thing. In 'MessageWriter' there are a lot of methods
> > like 'write*(String name, * val)'. But in implementation
> > 'DirectMessageWriter' argument 'name' isn't used in these methods. And
> > there aren't other 'MessageWriter' implementations.
> >
> > Maybe we can remove 'name' from interface and implementation?
> >
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: distributed transaction of non-single coordinator

[Sergi Vladykin]

1. Actually you have to check versions on all the values you have read
during the tx.

For example if we have [k1 => v1, k2 => v2] and do:

put(k1, get(k2) + 5)

We have to remember the version for k2. This logic can be relatively easily
encapsulated in a framework atop of Ignite. You need to implement one to
make all this stuff usable.

2. I suggest to avoid any locking here, because you easily will end up with
deadlocks. If you do not have too frequent updates for your keys,
optimistic approach will work just fine.

Theoretically in the Committer Service you can start a thread for the
lifetime of the whole distributed transaction, take a lock on the key using
IgniteCache.lock(K key) before executing any Services, wait for all the
services to complete, execute optimistic commit in the same thread while
keeping this lock and then release it. Notice that all the Ignite
transactions inside of all Services must be optimistic here to be able to
read this locked key.

But again I do not recommend you using this approach until you have a
reliable deadlock avoidance scheme.

Sergi







2017-03-16 12:53 GMT+03:00 ALEKSEY KUZNETSOV :

> Yeah, now i got it.
> There are some doubts on this approach
> 1) During optimistic commit phase, when you assure no one altered the
> original values, you must check versions of other dependent keys. How could
> we obtain those keys(in an automative manner, of course) ?
> 2) How could we lock a key before some Service A introduce changes? So no
> other service is allowed to change this key-value?(sort of pessimistic
> blocking)
> May be you know some implementations of such approach ?
>
> ср, 15 мар. 2017 г. в 17:54, ALEKSEY KUZNETSOV :
>
> >  Thank you very much for help.  I will answer later.
> >
> > ср, 15 мар. 2017 г. в 17:39, Sergi Vladykin :
> >
> > All the services do not update key in place, but only generate new keys
> > augmented by otx and store the updated value in the same cache + remember
> > the keys and versions participating in the transaction in some separate
> > atomic cache.
> >
> > Follow this sequence of changes applied to cache contents by each
> Service:
> >
> > Initial cache contents:
> > [k1 => v1]
> > [k2 => v2]
> > [k3 => v3]
> >
> > Cache contents after Service A:
> > [k1 => v1]
> > [k2 => v2]
> > [k3 => v3]
> > [k1x => v1a]
> > [k2x => v2a]
> >
> >  + [x => (k1 -> ver1, k2 -> ver2)] in some separate atomic cache
> >
> > Cache contents after Service B:
> > [k1 => v1]
> > [k2 => v2]
> > [k3 => v3]
> > [k1x => v1a]
> > [k2x => v2ab]
> > [k3x => v3b]
> >
> > + [x => (k1 -> ver1, k2 -> ver2, k3 -> ver3)] in some separate
> > atomic cache
> >
> > Finally the Committer Service takes this map of updated keys and their
> > versions from some separate atomic cache, starts Ignite transaction and
> > replaces all the values for k* keys to values taken from k*x keys. The
> > successful result must be the following:
> >
> > [k1 => v1a]
> > [k2 => v2ab]
> > [k3 => v3b]
> > [k1x => v1a]
> > [k2x => v2ab]
> > [k3x => v3b]
> >
> > + [x => (k1 -> ver1, k2 -> ver2, k3 -> ver3)] in some separate
> > atomic cache
> >
> > But Committer Service also has to check that no one updated the original
> > values before us, because otherwise we can not give any serializability
> > guarantee for these distributed transactions. Here we may need to check
> not
> > only versions of the updated keys, but also versions of any other keys
> end
> > result depends on.
> >
> > After that Committer Service has to do a cleanup (may be outside of the
> > committing tx) to come to the following final state:
> >
> > [k1 => v1a]
> > [k2 => v2ab]
> > [k3 => v3b]
> >
> > Makes sense?
> >
> > Sergi
> >
> >
> > 2017-03-15 16:54 GMT+03:00 ALEKSEY KUZNETSOV :
> >
> > >- what do u mean by saying "
> > > *in a single transaction checks value versions for all the old values
> > > and replaces them with calculated new ones *"? Every time you
> change
> > >value(in some service), you store it to *some special atomic cache*
> ,
> > so
> > >when all services ceased working, Service commiter got a values with
> > the
> > >last versions.
> > >- After "*does cleanup of temporary keys and values*" Service
> commiter
> > >persists them into permanent store, isn't it ?
> > >- I cant grasp your though, you say "*in case of version mismatch or
> > TX
> > >timeout just rollbacks*". But what versions would it match?
> > >
> > >
> > > ср, 15 мар. 2017 г. в 15:34, Sergi Vladykin  >:
> > >
> > > > Ok, here is what you actually need to implement at the application

Re: Usability Issue: Web Console doesn't give an option to add a primary key to object fields list

[Alexey Kuznetsov]

Dima & Denis,

See: https://issues.apache.org/jira/browse/IGNITE-3487
and
http://apache-ignite-developers.2346864.n4.nabble.com/DML-data-streaming-td14385.html

On Thu, Mar 16, 2017 at 8:18 AM, Dmitriy Setrakyan 
wrote:

> On Wed, Mar 15, 2017 at 5:42 PM, Alexey Kuznetsov  >
> wrote:
>
> > Dmitriy,
> >
> > I'm not "disagree" :). I'm "surprised" :)
> > AFAIK our DML uses "_key" as a MUST, i.e. "insert into T (_key, )
> > values (...)"
> >
> >
> To my knowledge, users should never even know about the existence of the
> _key field. Vladimir, can you please clarify?
>



-- 
Alexey Kuznetsov

Re: Unused argument in DirectMessageWriter

[Valentin Kulichenko]

Hi,

These classes are part of plugin framework. Even though 'name' argument is
not used by Ignite implementations, it can be used by others. Therefore it
should not be removed.

-Val

On Thu, Mar 16, 2017 at 10:36 AM, Александр Меньшиков 
wrote:

> Hello, everyone!
>
> I found some strange thing. In 'MessageWriter' there are a lot of methods
> like 'write*(String name, * val)'. But in implementation
> 'DirectMessageWriter' argument 'name' isn't used in these methods. And
> there aren't other 'MessageWriter' implementations.
>
> Maybe we can remove 'name' from interface and implementation?
>

Re: Cluster name

[Alexey Kuznetsov]

Dmitriy, Sergi and Val.

Web Console will be connected to several clusters at once.
And clusters do not know about Web Console, because Web Console collect
info from cluster via our REST-HTTP module.
So, I can distinguish clusters only by collection of node IDs and give them
names like: "Cluster1, Clsuter2,"
But if cluster restarted Web Console will detect it as new cluster and give
next auto-generated name "ClusterN".

So, I'm not insist on adding "ClusterName" to IgniteConfiguration, but
could you give me a way
 some how "mark" clusters to detect them even after full restart.

May be setting some sort of environment variable (it will be added to node
attributes)?
So, if user need "Multi-cluster" support he should set different
CLUSTER_NAME environment variable for different clusters.

Any other ideas are welcome.

On Thu, Mar 16, 2017 at 5:57 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Alexey,
>
> How does the workflow look like? How do you add a cluster to this dropdown
> on the console? I think that assigning a name should be part of this
> process and should happen on the console itself.
>
> Adding yet another "name" to configuration will only confuse users even
> more.
>
> -Val
>
> On Thu, Mar 16, 2017 at 9:59 AM, Sergi Vladykin 
> wrote:
>
> > I don't like to add anything like this into Ignite config. It is a
> problem
> > of Web console how to name or rename different clusters for a user, but
> not
> > Ignite cluster itself.
> >
> > Sergi
> >
> > 2017-03-16 4:21 GMT+03:00 Dmitriy Setrakyan :
> >
> > > I am OK with having a cluster name, but I would like us to generate one
> > > automatically, if users do not define one explicitly. How about
> > > "cluster_timestamp"?
> > >
> > > On Wed, Mar 15, 2017 at 5:38 PM, Alexey Kuznetsov <
> akuznet...@apache.org
> > >
> > > wrote:
> > >
> > > > Igniters,
> > > >
> > > > I'm planning to start working on multi cluster support for Web
> Console
> > > > in order to be able to execute SQL queries on different clusters just
> > by
> > > > selecting
> > > > target cluster from drop-down.
> > > >
> > > > But Ignite does not have any cluster wide name.
> > > >
> > > > So, how about to add to Ignite (may be 2.0) property "Cluster Name"
> to
> > > > Ignite configuration?
> > > >
> > > > Or as alternative way it could use "Mandatory User Defined
> Attribute".
> > > >
> > > > Node should be rejected to join cluster with different "Cluster Name"
> > > >
> > > >
> > > > Thoughts?
> > > >
> > > > --
> > > > Alexey Kuznetsov
> > > >
> > >
> >
>



-- 
Alexey Kuznetsov

Re: Cluster name

[Valentin Kulichenko]

Alexey,

How does the workflow look like? How do you add a cluster to this dropdown
on the console? I think that assigning a name should be part of this
process and should happen on the console itself.

Adding yet another "name" to configuration will only confuse users even
more.

-Val

On Thu, Mar 16, 2017 at 9:59 AM, Sergi Vladykin 
wrote:

> I don't like to add anything like this into Ignite config. It is a problem
> of Web console how to name or rename different clusters for a user, but not
> Ignite cluster itself.
>
> Sergi
>
> 2017-03-16 4:21 GMT+03:00 Dmitriy Setrakyan :
>
> > I am OK with having a cluster name, but I would like us to generate one
> > automatically, if users do not define one explicitly. How about
> > "cluster_timestamp"?
> >
> > On Wed, Mar 15, 2017 at 5:38 PM, Alexey Kuznetsov  >
> > wrote:
> >
> > > Igniters,
> > >
> > > I'm planning to start working on multi cluster support for Web Console
> > > in order to be able to execute SQL queries on different clusters just
> by
> > > selecting
> > > target cluster from drop-down.
> > >
> > > But Ignite does not have any cluster wide name.
> > >
> > > So, how about to add to Ignite (may be 2.0) property "Cluster Name" to
> > > Ignite configuration?
> > >
> > > Or as alternative way it could use "Mandatory User Defined Attribute".
> > >
> > > Node should be rejected to join cluster with different "Cluster Name"
> > >
> > >
> > > Thoughts?
> > >
> > > --
> > > Alexey Kuznetsov
> > >
> >
>

Re: distributed transaction of non-single coordinator

[ALEKSEY KUZNETSOV]

Yeah, now i got it.
There are some doubts on this approach
1) During optimistic commit phase, when you assure no one altered the
original values, you must check versions of other dependent keys. How could
we obtain those keys(in an automative manner, of course) ?
2) How could we lock a key before some Service A introduce changes? So no
other service is allowed to change this key-value?(sort of pessimistic
blocking)
May be you know some implementations of such approach ?

ср, 15 мар. 2017 г. в 17:54, ALEKSEY KUZNETSOV :

>  Thank you very much for help.  I will answer later.
>
> ср, 15 мар. 2017 г. в 17:39, Sergi Vladykin :
>
> All the services do not update key in place, but only generate new keys
> augmented by otx and store the updated value in the same cache + remember
> the keys and versions participating in the transaction in some separate
> atomic cache.
>
> Follow this sequence of changes applied to cache contents by each Service:
>
> Initial cache contents:
> [k1 => v1]
> [k2 => v2]
> [k3 => v3]
>
> Cache contents after Service A:
> [k1 => v1]
> [k2 => v2]
> [k3 => v3]
> [k1x => v1a]
> [k2x => v2a]
>
>  + [x => (k1 -> ver1, k2 -> ver2)] in some separate atomic cache
>
> Cache contents after Service B:
> [k1 => v1]
> [k2 => v2]
> [k3 => v3]
> [k1x => v1a]
> [k2x => v2ab]
> [k3x => v3b]
>
> + [x => (k1 -> ver1, k2 -> ver2, k3 -> ver3)] in some separate
> atomic cache
>
> Finally the Committer Service takes this map of updated keys and their
> versions from some separate atomic cache, starts Ignite transaction and
> replaces all the values for k* keys to values taken from k*x keys. The
> successful result must be the following:
>
> [k1 => v1a]
> [k2 => v2ab]
> [k3 => v3b]
> [k1x => v1a]
> [k2x => v2ab]
> [k3x => v3b]
>
> + [x => (k1 -> ver1, k2 -> ver2, k3 -> ver3)] in some separate
> atomic cache
>
> But Committer Service also has to check that no one updated the original
> values before us, because otherwise we can not give any serializability
> guarantee for these distributed transactions. Here we may need to check not
> only versions of the updated keys, but also versions of any other keys end
> result depends on.
>
> After that Committer Service has to do a cleanup (may be outside of the
> committing tx) to come to the following final state:
>
> [k1 => v1a]
> [k2 => v2ab]
> [k3 => v3b]
>
> Makes sense?
>
> Sergi
>
>
> 2017-03-15 16:54 GMT+03:00 ALEKSEY KUZNETSOV :
>
> >- what do u mean by saying "
> > *in a single transaction checks value versions for all the old values
> > and replaces them with calculated new ones *"? Every time you change
> >value(in some service), you store it to *some special atomic cache* ,
> so
> >when all services ceased working, Service commiter got a values with
> the
> >last versions.
> >- After "*does cleanup of temporary keys and values*" Service commiter
> >persists them into permanent store, isn't it ?
> >- I cant grasp your though, you say "*in case of version mismatch or
> TX
> >timeout just rollbacks*". But what versions would it match?
> >
> >
> > ср, 15 мар. 2017 г. в 15:34, Sergi Vladykin :
> >
> > > Ok, here is what you actually need to implement at the application
> level.
> > >
> > > Lets say we have to call 2 services in the following order:
> > >  - Service A: wants to update keys [k1 => v1,   k2 => v2]  to  [k1 =>
> > v1a,
> > >   k2 => v2a]
> > >  - Service B: wants to update keys [k2 => v2a, k3 => v3]  to  [k2 =>
> > v2ab,
> > > k3 => v3b]
> > >
> > > The change
> > > from [ k1 => v1,   k2 => v2, k3 => v3   ]
> > > to [ k1 => v1a, k2 => v2ab, k3 => v3b ]
> > > must happen in a single transaction.
> > >
> > >
> > > Optimistic protocol to solve this:
> > >
> > > Each cache key must have a field `otx`, which is a unique orchestrator
> TX
> > > identifier - it must be a parameter passed to all the services. If
> `otx`
> > is
> > > set to some value it means that it is an intermediate key and is
> visible
> > > only inside of some transaction, for the finalized key `otx` must be
> > null -
> > > it means the key is committed and visible for everyone.
> > >
> > > Each cache value must have a field `ver` which is a version of that
> > value.
> > >
> > > For both fields (`otx` and `ver`) the safest way is to use UUID.
> > >
> > > Workflow is the following:
> > >
> > > Orchestrator starts the distributed transaction with `otx` = x and
> passes
> > > this parameter to all the services.
> > >
> > > Service A:
> > >  - does some computations
> > >  - stores [k1x => v1a, k2x => v2a]  with TTL = Za
> > >   where

Unused argument in DirectMessageWriter

[Александр Меньшиков]

Hello, everyone!

I found some strange thing. In 'MessageWriter' there are a lot of methods
like 'write*(String name, * val)'. But in implementation
'DirectMessageWriter' argument 'name' isn't used in these methods. And
there aren't other 'MessageWriter' implementations.

Maybe we can remove 'name' from interface and implementation?

Re: Cluster name

[Sergi Vladykin]

I don't like to add anything like this into Ignite config. It is a problem
of Web console how to name or rename different clusters for a user, but not
Ignite cluster itself.

Sergi

2017-03-16 4:21 GMT+03:00 Dmitriy Setrakyan :

> I am OK with having a cluster name, but I would like us to generate one
> automatically, if users do not define one explicitly. How about
> "cluster_timestamp"?
>
> On Wed, Mar 15, 2017 at 5:38 PM, Alexey Kuznetsov 
> wrote:
>
> > Igniters,
> >
> > I'm planning to start working on multi cluster support for Web Console
> > in order to be able to execute SQL queries on different clusters just by
> > selecting
> > target cluster from drop-down.
> >
> > But Ignite does not have any cluster wide name.
> >
> > So, how about to add to Ignite (may be 2.0) property "Cluster Name" to
> > Ignite configuration?
> >
> > Or as alternative way it could use "Mandatory User Defined Attribute".
> >
> > Node should be rejected to join cluster with different "Cluster Name"
> >
> >
> > Thoughts?
> >
> > --
> > Alexey Kuznetsov
> >
>

[GitHub] ignite pull request #1625: IGNITE-4712 (tests fix)

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/1625


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

ignite-3682 - GridFunc: move all inner anonymous classes to separate top-level classes.

[Vyacheslav Daradur]

Hello everyone.

I have some questions about the issue
https://issues.apache.org/jira/browse/IGNITE-3682

1) Can I do some minor refactoring of GridFunc class within this task? (to
remove unused methods and code duplicates)
Or just to extract anonymous classes?

2) Should @Depricated be added to GridFunc and F classes?

-- 
Best Regards, Vyacheslav

ignite-4823 - ready for review (SpringCache#putIfAbsent - wrong implementation)

[Vyacheslav Daradur]

Hello everyone.

Please review changes: *https://issues.apache.org/jira/browse/IGNITE-4823
*

I found this when I worked on an another issue.

If I'm not mistaken it's wrong implementation.

--
Best Regards, Vyacheslav