[jira] [Created] (IGNITE-3519) Web console: add ability to specify a node filter in start caches configuration

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-3519:
--

 Summary: Web console: add ability to specify a node filter in 
start caches configuration
 Key: IGNITE-3519
 URL: https://issues.apache.org/jira/browse/IGNITE-3519
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov
Assignee: Vasiliy Sisko






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

Rework "withAsync" in Apache 2.0

[Vladimir Ozerov]

Hi folks,

There was a discussion about not very good "withAsync()" API design [1]. As
we are approaching Ignite 2.0 it is a good time to rework it. My
considerations on how good API should look like and how should it be
implemented:

1) Sync and async must be *different interfaces*.
2) All async methods must return *futures*. No thread-locals.
3) Sync operations normally* should not* be implemented through async. This
is a long story - if we delegate to async, then we have to bother with
additional threads, associated back-pressure control and all that crap.
Sync call must be sync unless there is a very strong reason to go through
async path.
4) Last, but not least - we should re-design our futures to be more like
Java 8 *CompletableFuture*. It should be able to accept Executors to
continue computation, it should have lots of methods to deal with
continuations and joins, etc.. Ideally, it would be cool if could remove it
and use CompletableFuture, but it is clearly too early to drop Java 7
support. So we should at least try making our futures similar to
CompletableFuture.

I will create relevant tickets soon.

Thoughts?

[1]
http://apache-ignite-developers.2346864.n4.nabble.com/Net-separate-methods-for-async-operations-td3901.html

[jira] [Created] (IGNITE-3518) Examples fail to build, can't find resource: ignite-apache-license-gen

[Matt Stump (JIRA)]

Matt Stump created IGNITE-3518:
--

 Summary: Examples fail to build, can't find resource: 
ignite-apache-license-gen
 Key: IGNITE-3518
 URL: https://issues.apache.org/jira/browse/IGNITE-3518
 Project: Ignite
  Issue Type: Bug
  Components: build
Reporter: Matt Stump
Priority: Minor


The examples can't find the resource ignite-apache-license-gen. Looking at the 
repository, the last version present is {{1.5.0-SNAPSHOT}}. New resources 
should be published, or the build script should be modified to use the older 
version.

{code}
[ERROR] Failed to execute goal on project ignite-examples: Could not resolve 
dependencies for project org.apache.ignite:ignite-examples:jar:1.7.0-SNAPSHOT: 
Could not find artifact 
org.apache.ignite:ignite-apache-license-gen:jar:1.7.0-SNAPSHOT in 
apache.snapshots (http://repository.apache.org/snapshots) -> [Help 1]
{code}



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

[jira] [Created] (IGNITE-3517) Modify build instructions to increase PermGen

[Matt Stump (JIRA)]

Matt Stump created IGNITE-3517:
--

 Summary: Modify build instructions to increase PermGen
 Key: IGNITE-3517
 URL: https://issues.apache.org/jira/browse/IGNITE-3517
 Project: Ignite
  Issue Type: Bug
  Components: build, documentation
Reporter: Matt Stump
Priority: Minor


When building maven will OOM after exhausting PermGen. The getting started 
instructions page should be updated to increase PermGen size before building.

{{export MAVEN_OPTS="-Xmx2g -XX:MaxPermSize=1024m"}}

{{
Exception in thread "main" java.lang.OutOfMemoryError: PermGen space
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:401)
at 
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
at org.eclipse.sisu.inject.MildElements.iterator(MildElements.java:74)
at org.eclipse.sisu.inject.RankedBindings.remove(RankedBindings.java:68)
at 
org.eclipse.sisu.inject.InjectorBindings.unsubscribe(InjectorBindings.java:96)
at 
org.eclipse.sisu.inject.RankedBindings.remove(RankedBindings.java:117)
at 
org.eclipse.sisu.inject.DefaultBeanLocator.remove(DefaultBeanLocator.java:122)
at 
org.eclipse.sisu.inject.DefaultBeanLocator.remove(DefaultBeanLocator.java:156)
at 
org.eclipse.sisu.plexus.ClassRealmManager.realmDisposed(ClassRealmManager.java:156)
at 
org.codehaus.plexus.classworlds.ClassWorld.disposeRealm(ClassWorld.java:100)
at 
org.apache.maven.plugin.DefaultExtensionRealmCache.flush(DefaultExtensionRealmCache.java:150)
at 
org.apache.maven.plugin.DefaultExtensionRealmCache.dispose(DefaultExtensionRealmCache.java:167)
at 
org.eclipse.sisu.plexus.PlexusLifecycleManager.dispose(PlexusLifecycleManager.java:373)
at 
org.eclipse.sisu.plexus.PlexusLifecycleManager.unmanage(PlexusLifecycleManager.java:173)
at 
org.codehaus.plexus.DefaultPlexusContainer.dispose(DefaultPlexusContainer.java:590)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:313)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
}}



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

Re: IGNITE-2294 implementation details

[Sergi Vladykin]

I'd prefer to do MERGE operation last because in H2 it is not standard ANSI
SQL MERGE. Or may be not implement it at all, or may be contribute ANSI
correct version to H2, then implement it on Ignite. Need to investigate the
semantics deeper before making any decisions here.

Lets start with simple scenarios for INSERT and go through all the possible
cases and answer the questions:
- What will happen on key conflict in TX cache?
- What will happen on key conflict in Atomic cache?
- What will happen with the previous two if we use DataLoader?
- How to make these operations efficient (it will be simple enough to
implement them with separate put/putIfAbsent operations but probably we
will need some batching like putAllIfAbsent for efficiency)?

As for API, we still will need to have a single entry point for all SQL
queries/commands to allow any console work with it transparently. It would
be great if we will be able to come up with something consistent with this
idea on public API.

Sergi








On Wed, Jul 20, 2016 at 2:23 PM, Dmitriy Setrakyan 
wrote:

> Like the idea of merge and insert. I need more time to think about the API
> changes.
>
> Sergi, what do you think?
>
> Dmitriy
>
>
>
> On Jul 20, 2016, at 12:36 PM, Alexander Paschenko <
> alexander.a.pasche...@gmail.com> wrote:
>
> >> Thus, I suggest that we implement MERGE as a separate operation backed
> by putIfAbsent operation, while INSERT will be implemented via put.
> >
> > Sorry, of course I meant that MERGE has to be put-based, while INSERT
> > has to be putIfAbsent-based.
> >
> > 2016-07-20 12:30 GMT+03:00 Alexander Paschenko
> > :
> >> Hell Igniters,
> >>
> >> In this thread I would like to share and discuss some thoughts on DML
> >> operations' implementation, so let's start and keep it here. Everyone
> >> is of course welcome to share their suggestions.
> >>
> >> For starters, I was thinking about semantics of INSERT. In traditional
> >> RDBMSs, INSERT works only for records whose primary keys don't
> >> conflict with those of records that are already persistent - you can't
> >> try to insert the same key more than once because you'll get an error.
> >> However, semantics of cache put is obviously different - it does not
> >> have anything about duplicate keys, it just quietly updates values in
> >> case of keys' duplication. Still, cache has putIfAbsent operation that
> >> is closer to traditional notion of INSERT, and H2's SQL dialect has
> >> MERGE operation which corresponds to semantics of cache put. Thus, I
> >> suggest that we implement MERGE as a separate operation backed by
> >> putIfAbsent operation, while INSERT will be implemented via put.
> >>
> >> And one more, probably more important thing: I suggest that we create
> >> separate class Update and corresponding operation update() in
> >> IgniteCache. The reasons are as follows:
> >>
> >> - Query bears some flags that are clearly redundant for Update (page
> >> size, locality)
> >> - query() method in IgniteCache (one that accepts Query) and query()
> >> methods in GridQueryIndexing return iterators. So, if we strive to
> >> leave interfaces unchanged, we still will introduce some design
> >> ugliness like query methods returning empty iterators for certain
> >> queries, and/or query flags that indicate whether it's an update query
> >> or not, etc.
> >> - If some Queries are update queries, then continuous queries can't be
> >> based on them - more design-wise ugly checks and stuff like that.
> >> - I'm pretty sure there's more I don't know about.
> >>
> >> Comments and suggestions are welcome. Sergi Vladykin, Dmitry
> >> Setrakyan, your opinions are of particular interest, please advise.
> >>
> >> Regards,
> >> Alex
>

Re: Ignite monitoring

[Igor Rudyak]

Andrey,

Is Web Console you are talking about the same thing as GridGain Web Console
(http://ignite.apache.org/addons.html#web-console)? If yes it has
monitoring tab which allows to monitor some JVM and cache metrics (
https://console.gridgain.com/monitoring).

As for me, Visor command line tool doesn't look like good candidate for
monitoring. Monitoring tool should provide rather friendly UI with graphs,
tables and etc. to simplify monitoring of the system. While command line
tool like Visor is more about system administration/management.

Igor Rudyak


On Wed, Jul 20, 2016 at 2:46 AM, Andrey Novikov  wrote:

> Igor,
>
> Ignite does not have monitoring in Web Console, only Configuration and SQL.
> But command-line Visor in Ignite have some monitoring features and can be
> used  to add new.
>
> On Wed, Jul 20, 2016 at 1:19 AM, Igor Rudyak  wrote:
>
> > Are there any documentation regarding how to use Ignite web console? How
> to
> > add new metrics to monitor?
> >
> > On Mon, Jul 18, 2016 at 10:47 AM, Dmitriy Setrakyan <
> dsetrak...@apache.org
> > >
> > wrote:
> >
> > > On Mon, Jul 18, 2016 at 8:45 PM, Alexey Kuznetsov <
> > akuznet...@gridgain.com
> > > >
> > > wrote:
> > >
> > > > I think we should have some general API and we could call it from web
> > > > console and/or from other places.
> > > >
> > >
> > > Agree. The server side support should be sufficient to enable different
> > > monitoring connections, including command-line visor, web console, or
> JMX
> > > beans.
> > >
> > >
> > > > 18 Июл 2016 г. 20:18 пользователь "Dmitriy Setrakyan" <
> > > > dsetrak...@apache.org>
> > > > написал:
> > > >
> > > > > I think we can add this functionality to Ignite web console, no?
> > > > >
> > > > > On Mon, Jul 18, 2016 at 11:08 AM, Vladimir Ozerov <
> > > voze...@gridgain.com>
> > > > > wrote:
> > > > >
> > > > > > Igor,
> > > > > >
> > > > > > I think that built-in monitoring facility will add great value to
> > the
> > > > > > product. We have to deal with user performance issues pretty
> often,
> > > and
> > > > > it
> > > > > > is always a kind of pain to get to the bottom of the problem. We
> > have
> > > > to
> > > > > > ask users for configuration, logs, system config, etc, etc..
> > Instead,
> > > > it
> > > > > > would be great if we had a single big "switch". If user has
> > > performance
> > > > > > issue, he turns it on, then perform problematic operations, and
> > then
> > > > > dumps
> > > > > > all collected data. We can collect dozens of things:
> > > > > > 1) OS/JVM information
> > > > > > 2) Ignite configs, logs, etc..
> > > > > > 3) Performance data (CPU, RAM, IO)
> > > > > > 4) Metrics
> > > > > > 5) JMX data (both Ignite and JVM)
> > > > > > 6) Some internal tracing (SQL query plans, how long it takes
> > messages
> > > > to
> > > > > > pass between nodes, etc.)
> > > > > >
> > > > > > I think the most important part here is good infrastructure
> > > > (interfaces)
> > > > > > and API. So that we can start with something very simple, like
> > > > collecting
> > > > > > configs from all nodes, or starting/stopping shell commands, and
> > then
> > > > > > gradually add more and more tracing facilities.
> > > > > >
> > > > > > Thoughts?
> > > > > >
> > > > > > Vladimir.
> > > > > >
> > > > > >
> > > > > > On Thu, Jul 14, 2016 at 11:36 PM, Igor Rudyak  >
> > > > wrote:
> > > > > >
> > > > > > > Yakov, as for now I just have well structured scripts to setup
> > > > Ganglia
> > > > > > > agent on Ignite hosts to monitor system metrics like CPU, RAM,
> IO
> > > and
> > > > > etc
> > > > > > > (this scripts already included in Ignite 1.6).
> > > > > > >
> > > > > > > Also experimented with displaying JVM metrics by providing java
> > > agent
> > > > > and
> > > > > > > specifying MBeans to collect metrics from. But it's rather
> draft
> > > > > version.
> > > > > > > The second problem is, there are plenty of MBeans in Ignite - I
> > > just
> > > > > > don't
> > > > > > > know which to select from.
> > > > > > >
> > > > > > > Anyway, the original idea was to check with the community if it
> > > makes
> > > > > > sense
> > > > > > > to have such monitoring functionality out of the box.
> > > > > > >
> > > > > > > Igor Rudyak
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Thu, Jul 14, 2016 at 1:05 AM, Yakov Zhdanov <
> > > yzhda...@apache.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Igor, can you please share the changes to scripts you did to
> > > > support
> > > > > > > > monitoring? Can it be done by defining and exporting
> JAVA_OPTS
> > > env
> > > > > > > variable
> > > > > > > > and then launching ignite.sh?
> > > > > > > >
> > > > > > > > Thanks!
> > > > > > > >
> > > > > > > > --Yakov
> > > > > > > >
> > > > > > > > 2016-07-13 22:45 GMT+03:00 Igor Rudyak :
> > > > > > > >
> > > > > > > > > Hi guys,
> > > > > > > > >
> > > > > > > > > While experimenting with large Ignite clusters I found that
> > > lack
> > > > of
> > > > > > > > > monitoring is rather critical p

[GitHub] ignite pull request #876: IGNITE-3516

[kromulan]

GitHub user kromulan opened a pull request:

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

IGNITE-3516

H2 Indexing unregister cache does not call TableDescriptor's GridH2Table 
close and optionally GridLuceneIndex close, which causes OFFHEAP_TIERED cache 
to leak memory.

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

$ git pull https://github.com/kromulan/ignite IGNITE-3516

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

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


commit d608459d379aa81687ee5b8d280450ef5e359e1f
Author: Krome Plasma 
Date:   2016-07-20T13:52:26Z

IgniteH2Indexing unregisterCache resource cleanup.




---
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.
---

[jira] [Created] (IGNITE-3516) H2 Indexing unregisterCache method does not cleanup resources and causes memory leak with OFFHEAP_TIERED cache mode cache.

[Krome Plasma (JIRA)]

Krome Plasma created IGNITE-3516:


 Summary: H2 Indexing unregisterCache method does not cleanup 
resources and causes memory leak with OFFHEAP_TIERED cache mode cache.
 Key: IGNITE-3516
 URL: https://issues.apache.org/jira/browse/IGNITE-3516
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.6
Reporter: Krome Plasma
Assignee: Krome Plasma
Priority: Critical
 Fix For: 1.7


H2 Indexing unregister cache does not call TableDescriptor's GridH2Table close 
and optionally GridLuceneIndex close, which causes OFFHEAP_TIERED cache to leak 
memory.




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

Re: Converting TreeMap to BinaryObject causes ClassCastException (IGNITE-2852)

[NoTrueScotsman]

Hi Denis,

thanks for clarifying. I'll take a look around Jira instead.

Thanks
Jens

On Wed, Jul 20, 2016 at 1:45 PM, Denis Magda  wrote:
> Hi Jens,
>
> This is not the best candidate for the first contribution and presently I 
> don’t think that this feature should be supported at all.
>
> I would recommend you picking up one of the tickets with “newbie” filter.
> https://issues.apache.org/jira/issues/?filter=12338037 
> 
>
> Regards,
> Denis
>
>> On Jul 19, 2016, at 9:00 PM, NoTrueScotsman  
>> wrote:
>>
>> It happens when applying ignite.binary().toBinary(m) to a TreeMap> V> with a custom key K.
>>
>> I thought this would be a nice task to pick as a first (attempt of a)
>> contribution, however there is a ticket for this already assigned to
>> someone: https://issues.apache.org/jira/browse/IGNITE-2852
>>
>> I haven't seen much activity on it though. Would it be possible for me
>> to pick it?
>>
>> Thanks
>> Jens
>

Re: ReadWriteUpdateLock

[Yakov Zhdanov]

Vova, we discuss this without having any numbers. Any real-life use case?

--Yakov

2016-07-20 9:48 GMT+03:00 Vladimir Ozerov :

> I believe this could be a useful addition to Ignite. RWU-locks are not
> widely-spread in Java. But for example in .NET this is a base concurrency
> primitive. Of course users can handle "update" situations differently, e.g.
> "release read lock, then acquire write lock, then re-check condition, ...".
> But this is exactly where "update" semantics could free user from this
> burden. I think we will see some demand for this feature at least from .NET
> community.
>
> On the other hand, I fully agree with Yakov that "update" is a kind of
> corner case. Standard "read lock" and "write lock" are much more common. We
> should implement distributed RWlock first.
>
> For RWULock we can at least create a JIRA ticket for now. If someone from
> community would like to implement it - then why not?
>
> Vladimir.
>
> On Tue, Jul 19, 2016 at 1:56 PM, Yakov Zhdanov 
> wrote:
>
> > Hi Vlad!
> >
> > Thanks for bringing this up.
> >
> > I looked through concurrency-interest discussion, and I don't think we
> > should do this in Ignite. At least now. I am not sure if this will give
> any
> > advantage since only one thread can acquire UPDATE lock at the same time.
> > Btw, was there any benchmark published comparing UpdateLock  vs RWLock
> > implementations?
> >
> > I think that in many cases read then update scenarios can be handled with
> > some kind of volatile or atomic read and then acquiring the ordinary lock
> > or by CAS operation. For the rest of cases we already have RWLock.
> >
> > And one more point - nobody asked for it. So, I ask - Does anyone need it
> > in Ignite?
> >
> > Thanks!
> >
> > --Yakov
> >
> > 2016-07-18 22:55 GMT+03:00 Vladisav Jelisavcic :
> >
> > > Hi everyone,
> > >
> > > cross-posting from JIRA:
> > > I recently came across this post:
> > > http://codereview.stackexchange.com/a/31231
> > >
> > > Do you think ReadWriteUpdateLock is something we can put to good use
> here
> > > in Ignite?
> > >
> > > This kind of lock should be more efficient for read-before-write
> > patterns.
> > >
> > > Best regards,
> > > Vladisav
> > >
> >
>

[GitHub] ignite pull request #875: IGNITE-3515

[kromulan]

GitHub user kromulan opened a pull request:

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

IGNITE-3515

Null check for sync object added to IgniteSemaphore implementation stop 
method.

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

$ git pull https://github.com/kromulan/ignite IGNITE-3515

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

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


commit b72e5788e735f8ed34add648638450ba3f51bbca
Author: Krome Plasma 
Date:   2016-07-20T12:41:26Z

IgniteSemaphore implementation stop method null check




---
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.
---

[jira] [Created] (IGNITE-3515) NullPointerException when stopping IgniteSemaphore and no method has been called previously to initialize semaphore with initializeSemaphore().

[Krome Plasma (JIRA)]

Krome Plasma created IGNITE-3515:


 Summary: NullPointerException when stopping IgniteSemaphore and no 
method has been called previously to initialize semaphore with 
initializeSemaphore().
 Key: IGNITE-3515
 URL: https://issues.apache.org/jira/browse/IGNITE-3515
 Project: Ignite
  Issue Type: Bug
  Components: data structures
Affects Versions: 1.6
Reporter: Krome Plasma
 Fix For: 1.7


IgniteSemaphore stop() method does not check if internal synchronization object 
'sync' is null hence null pointer exception is thrown.



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

[GitHub] ignite pull request #874: IGNITE-1433 .NET: Add Java stack trace to IgniteEx...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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.
---

[jira] [Created] (IGNITE-3514) CPP: JVM crash on some "Failed to start SPI" exception.

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-3514:
---

 Summary: CPP: JVM crash on some "Failed to start SPI" exception.
 Key: IGNITE-3514
 URL: https://issues.apache.org/jira/browse/IGNITE-3514
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 1.6
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 1.7


On invalid {{discoverySpi}} configuration JVM may crash (i.e. specify negative 
{{socketTimeout}}). This is probably caused by the attempted call on some 
platform callback which is null in C++.

{noformat}
Failed to start manager: GridManagerAdapter [enabled=true, 
name=o.a.i.i.managers.discovery.GridDiscoveryManager]
class org.apache.ignite.IgniteCheckedException: Failed to start SPI: 
TcpDiscoverySpi [addrRslvr=null, sockTimeout=-300, ackTimeout=5000, 
reconCnt=10, maxAckTimeout=60, forceSrvMode=false, 
clientReconnectDisabled=false]
at 
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:270)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:681)
at 
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1571)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:901)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1739)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1589)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:549)
at 
org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
at 
org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:76)
Caused by: class org.apache.ignite.spi.IgniteSpiException: SPI parameter failed 
condition check: sockTimeout > 0
at 
org.apache.ignite.spi.IgniteSpiAdapter.assertParameter(IgniteSpiAdapter.java:344)
at 
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1757)
at 
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:267)
... 9 more
[15:17:45,584][SEVERE][main][IgniteKernal%grid-0] Got exception while starting 
(will rollback startup routine).
class org.apache.ignite.IgniteCheckedException: Failed to start manager: 
GridManagerAdapter [enabled=true, 
name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
at 
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1576)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:901)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1739)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1589)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:549)
at 
org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
at 
org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:76)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start SPI: 
TcpDiscoverySpi [addrRslvr=null, sockTimeout=-300, ackTimeout=5000, 
reconCnt=10, maxAckTimeout=60, forceSrvMode=false, 
clientReconnectDisabled=false]
at 
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:270)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:681)
at 
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1571)
... 7 more
Caused by: class org.apache.ignite.spi.IgniteSpiException: SPI parameter failed 
condition check: sockTimeout > 0
at 
org.apache.ignite.spi.IgniteSpiAdapter.assertParameter(IgniteSpiAdapter.java:344)
at 
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1757)
at 
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:267)
... 9 more
[15:17:45,594][SEVERE][main][IgniteKernal%grid-0] Failed to stop component 
(ignoring): GridManagerAdapter [enabled=true, 
name=o.a.i.i.managers.discovery.GridDiscoveryManager]
java.lang.NullPointerException
at 
org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing.clear(TcpDiscoveryNodesRing.java:400)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStop0(ServerImpl.java:458)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStop(ServerImpl.java:359)
at 
org.apache.ignite.spi

Re: Converting TreeMap to BinaryObject causes ClassCastException (IGNITE-2852)

[Denis Magda]

Hi Jens,

This is not the best candidate for the first contribution and presently I don’t 
think that this feature should be supported at all.

I would recommend you picking up one of the tickets with “newbie” filter.
https://issues.apache.org/jira/issues/?filter=12338037 


Regards,
Denis

> On Jul 19, 2016, at 9:00 PM, NoTrueScotsman  
> wrote:
> 
> It happens when applying ignite.binary().toBinary(m) to a TreeMap V> with a custom key K.
> 
> I thought this would be a nice task to pick as a first (attempt of a)
> contribution, however there is a ticket for this already assigned to
> someone: https://issues.apache.org/jira/browse/IGNITE-2852
> 
> I haven't seen much activity on it though. Would it be possible for me
> to pick it?
> 
> Thanks
> Jens

Re: Ignite 2.0 tasks/roadmap

[Dmitriy Setrakyan]

I am allowed to flip-flop on my opinions every now and then :)


> On Jul 20, 2016, at 11:06 AM, Pavel Tupitsyn  wrote:
> 
> Dmitriy, you have agreed with me in the old thread, and now you don't?
> Binarylizable (current) is longer than Binarizable (proposed).
> 
> On Wed, Jul 20, 2016 at 10:24 AM, Dmitriy Setrakyan > wrote:
> 
>> 
>> 
>> 
>>> On Jul 20, 2016, at 9:17 AM, Pavel Tupitsyn 
>> wrote:
>>> 
>>> How about renaming Binarylizable interface?
>>> 
>>> 
>> http://apache-ignite-developers.2346864.n4.nabble.com/Naming-Binarylizable-td4592.html
>> 
>> Pavel, I would not rename. The name you are suggesting is very hard to
>> pronounce.
>> 
>>> 
>>> On Sat, Jul 16, 2016 at 10:25 AM, Sergi Vladykin <
>> sergi.vlady...@gmail.com>
>>> wrote:
>>> 
 Alexey K.,
 
 No problem, here it is
>> https://issues.apache.org/jira/browse/IGNITE-3488
 
 Sergi
 
 On Sat, Jul 16, 2016 at 2:00 AM, Valentin Kulichenko <
 valentin.kuliche...@gmail.com> wrote:
 
> Folks,
> 
> I created one more ticket related to SQL:
> https://issues.apache.org/jira/browse/IGNITE-3487. It's a usability
 issue
> that pops up on user forum every now and then. Since it's a
>> compatibility
> breaking changed, it looks like a good candidate for 2.0.
> 
> -Val
> 
> On Fri, Jul 15, 2016 at 11:56 AM, Alexey Kuznetsov <
> akuznet...@gridgain.com>
> wrote:
> 
>> Sergi, that was my idea to drop nulls but I have limited access to
> internet
>> (I'm on vacation) could you create issue in JIRA?
>> 
>> Thanks.
>> 
>> Alexey Kuznetsov
>> 
>> 15 Июл 2016 г. 15:17 пользователь "Sergi Vladykin" <
>> sergi.vlady...@gmail.com>
>> написал:
>> 
>> Huge +1 for dropping support for null in all names, not only for cache
>> names. Do we have ticket for this one?
>> 
>> Sergi
>> 
>> On Fri, Jul 15, 2016 at 2:00 PM, Andrey Velichko <
>> andrey4...@gmail.com
> 
>> wrote:
>> 
>>> 
>>> 15.07.2016 0:31, Dmitriy Setrakyan пишет:
>>> 
 On Fri, Jul 15, 2016 at 12:26 AM, AndreyVel
>> wrote:
 
 Good feature may be Aggregated cache - analog materialized view in
> DBMS
> Aggregated cache is great for performance (KPI, analytecal
 reports).
> 
> Do you mean a copy of the aggregated data in another cache? What
>> happens
 when the data in the original caches is updated?
 
 
 
>>> Yes, aggregated data can be store in another cache,
>>> embedded aggregating cache can be updated sync/async. Aggregating
 from
>> the
>>> box has better performance then creating custom event listeners.
>>> 
>>> If cache entry updated/deleted aggregate listener can get 2 values
 old
>> and
>>> new.
>>> 
>> 
> 
 
>> 

Re: IGNITE-2294 implementation details

[Dmitriy Setrakyan]

Like the idea of merge and insert. I need more time to think about the API 
changes.

Sergi, what do you think?

Dmitriy



On Jul 20, 2016, at 12:36 PM, Alexander Paschenko 
 wrote:

>> Thus, I suggest that we implement MERGE as a separate operation backed by 
>> putIfAbsent operation, while INSERT will be implemented via put.
> 
> Sorry, of course I meant that MERGE has to be put-based, while INSERT
> has to be putIfAbsent-based.
> 
> 2016-07-20 12:30 GMT+03:00 Alexander Paschenko
> :
>> Hell Igniters,
>> 
>> In this thread I would like to share and discuss some thoughts on DML
>> operations' implementation, so let's start and keep it here. Everyone
>> is of course welcome to share their suggestions.
>> 
>> For starters, I was thinking about semantics of INSERT. In traditional
>> RDBMSs, INSERT works only for records whose primary keys don't
>> conflict with those of records that are already persistent - you can't
>> try to insert the same key more than once because you'll get an error.
>> However, semantics of cache put is obviously different - it does not
>> have anything about duplicate keys, it just quietly updates values in
>> case of keys' duplication. Still, cache has putIfAbsent operation that
>> is closer to traditional notion of INSERT, and H2's SQL dialect has
>> MERGE operation which corresponds to semantics of cache put. Thus, I
>> suggest that we implement MERGE as a separate operation backed by
>> putIfAbsent operation, while INSERT will be implemented via put.
>> 
>> And one more, probably more important thing: I suggest that we create
>> separate class Update and corresponding operation update() in
>> IgniteCache. The reasons are as follows:
>> 
>> - Query bears some flags that are clearly redundant for Update (page
>> size, locality)
>> - query() method in IgniteCache (one that accepts Query) and query()
>> methods in GridQueryIndexing return iterators. So, if we strive to
>> leave interfaces unchanged, we still will introduce some design
>> ugliness like query methods returning empty iterators for certain
>> queries, and/or query flags that indicate whether it's an update query
>> or not, etc.
>> - If some Queries are update queries, then continuous queries can't be
>> based on them - more design-wise ugly checks and stuff like that.
>> - I'm pretty sure there's more I don't know about.
>> 
>> Comments and suggestions are welcome. Sergi Vladykin, Dmitry
>> Setrakyan, your opinions are of particular interest, please advise.
>> 
>> Regards,
>> Alex

[GitHub] ignite pull request #874: IGNITE-1433 .NET: Add Java stack trace to IgniteEx...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-1433 .NET: Add Java stack trace to IgniteException



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

$ git pull https://github.com/ptupitsyn/ignite ignite-1433

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

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


commit f8dc82c94de96f382db6ff20790ef08b5330353d
Author: Pavel Tupitsyn 
Date:   2015-12-03T15:12:32Z

IGNITE-1433 .Net: Add GridException.JavaStackTrace

commit fc6a14fbd6d0d9700f01f2e3e0c39fb840d335b2
Author: Pavel Tupitsyn 
Date:   2015-12-04T10:55:44Z

wip propagation

commit d7e359f62c9477ddb439d39572b275a4fdef623e
Author: Pavel Tupitsyn 
Date:   2015-12-04T11:17:19Z

wip

commit 06bf93a2f6908f3d7d3a80543cb98b84186088eb
Author: Pavel Tupitsyn 
Date:   2015-12-04T11:21:59Z

C#/cpp done

commit 832bdeb3c79fdc56216ee6ee3cd9c56c0ce85dff
Author: Pavel Tupitsyn 
Date:   2015-12-04T11:25:46Z

Merge remote-tracking branch 'remotes/upstream/ignite-1.5' into ignite-1433

commit 8a4e7bd055e8f31cc8a568f403d8229c0d8c9cce
Author: Pavel Tupitsyn 
Date:   2015-12-04T12:18:10Z

fixing typos

commit 9faaabb10bac538b86cc721bae31dd8d08411d75
Author: Pavel Tupitsyn 
Date:   2015-12-04T12:21:10Z

Fixing typos

commit 3271d5c1cc676d23662f9f313f9ccf3096a3377f
Author: Pavel Tupitsyn 
Date:   2015-12-04T12:41:12Z

fixing typos

commit 3be4b9134f86cdc1dc495b6ca3aaace5079c2a10
Author: Pavel Tupitsyn 
Date:   2015-12-04T13:09:01Z

wip tests

commit 76c39356ad111d9dc732847ec999b0f78ab2f6b7
Author: Pavel Tupitsyn 
Date:   2015-12-04T13:19:57Z

cleanup

commit 442fcc2f8ac12bb499152e7eeefa353a19e6e25c
Author: Pavel Tupitsyn 
Date:   2015-12-04T13:22:12Z

fix tabs/spaces

commit 599d71178b3355e8ded8e9307b849e4b6c3d540a
Author: Pavel Tupitsyn 
Date:   2015-12-04T13:39:25Z

All done

commit ee9d861a2f392d87e1c59f20e679728ebd59868a
Author: Pavel Tupitsyn 
Date:   2015-12-04T14:03:57Z

cleanup

commit 795501652c8c175511e735fd20d73cc1447ade6d
Author: Pavel Tupitsyn 
Date:   2015-12-09T15:02:38Z

Merge remote-tracking branch 'remotes/upstream/ignite-1.5' into ignite-1433

commit 935056723fa6eee5a803720f6b1625524e82cf2f
Author: Pavel Tupitsyn 
Date:   2015-12-09T15:09:06Z

wip

commit 48d10f735bcb713f0454dc0efb7c89f65fbe35ad
Author: Pavel Tupitsyn 
Date:   2015-12-09T15:40:29Z

Merge remote-tracking branch 'remotes/upstream/ignite-1.5' into ignite-1433

commit bf1659f4d6c274af5b39b55fba3e66d4fa9bc7fb
Author: Pavel Tupitsyn 
Date:   2015-12-09T15:44:09Z

wip

commit 8768df41553c9a0882bdad433a75f058eada9cdd
Author: Pavel Tupitsyn 
Date:   2015-12-09T15:45:19Z

wip

commit 53a08cd525ebdfe51d293b58a2ced992060ea8a1
Author: Pavel Tupitsyn 
Date:   2015-12-09T15:58:19Z

Fix npe in CPP

commit f08095d4a73d899520ee7dbc5f1390630d6e3b1d
Author: Pavel Tupitsyn 
Date:   2016-03-03T06:58:19Z

Merge remote-tracking branch 'remotes/upstream/master' into ignite-1433

Conflicts:
modules/platforms/dotnet/Apache.Ignite.Core/Impl/Binary/BinaryUtils.cs
modules/platforms/dotnet/Apache.Ignite.Core/Impl/Cache/CacheImpl.cs

modules/platforms/dotnet/Apache.Ignite.Core/Impl/Compute/ComputeTaskHolder.cs
modules/platforms/dotnet/Apache.Ignite.Core/Impl/ExceptionUtils.cs

modules/platforms/dotnet/Apache.Ignite.Core/Impl/Unmanaged/UnmanagedCallbacks.cs

commit 8b07940a43470624964d3418f2206883bf039890
Author: Pavel Tupitsyn 
Date:   2016-03-03T09:58:43Z

Fix merge

commit 9def15b4043dfb914db148415d939e6064c8a241
Author: Pavel Tupitsyn 
Date:   2016-03-03T10:06:30Z

Merge remote-tracking branch 'remotes/upstream/master' into ignite-1433

commit a213aea30402b5eddea3ad7fe18d8b3b196c499c
Author: Pavel Tupitsyn 
Date:   2016-03-03T10:18:14Z

wip

commit 9f66feb185274fba2d9f63c3fa1e7f293d6139c2
Author: Pavel Tupitsyn 
Date:   2016-03-03T10:18:59Z

wip

commit 8d725364aa9fc04b7983f338e9d30e9bf9567826
Author: Pavel Tupitsyn 
Date:   2016-03-03T10:30:15Z

wip

commit 641c745cd5e472cb5f8df54a6fca4a7b5647a053
Author: Pavel Tupitsyn 
Date:   2016-03-03T10:32:16Z

wip

commit 569f708512772bdfef76ffb124b673177bb9be7a
Author: Pavel Tupitsyn 
Date:   2016-03-03T10:36:50Z

wip

commit 7c256159c5fb67c60c98a322a37182c2d436b111
Author: Pavel Tupitsyn 
Date:   2016-03-03T10:39:17Z

wip

commit 55beef2eef967d59ead6c11d9679af72de2f07ba
Author: Pavel Tupitsyn 
Date:   2016-03-03T10:47:10Z

wip cleanup ctors

commit eb472113e66fcf7b262ecfb3de57487f5f3cfd37
Author: Pavel Tupitsyn 
Date:   2016-03-03T10:51:01Z

Reorder args




---
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

[GitHub] ignite pull request #294: IGNITE-1433 .Net: Add IgniteException.JavaStackTra...

[ptupitsyn]

Github user ptupitsyn closed the pull request at:

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


---
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.
---

[jira] [Created] (IGNITE-3513) Cleanup worker is placed in the Thread's waiting queue using Thread.sleep method

[Denis Magda (JIRA)]

Denis Magda created IGNITE-3513:
---

 Summary: Cleanup worker is placed in the Thread's waiting queue 
using Thread.sleep method
 Key: IGNITE-3513
 URL: https://issues.apache.org/jira/browse/IGNITE-3513
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.6
Reporter: Denis Magda
Assignee: Semen Boikov
 Fix For: 1.7


There is a bug in current implementation of 
{{GridCacheTtlManager#CleanupWorker}}.

Refer to the implementation's code snippet and the details below.

{code}
EntryWrapper first = pendingEntries.firstx();

 if (first != null) {
   long waitTime = first.expireTime - U.currentTimeMillis();

   if (waitTime > 0)
  U.sleep(waitTime);
 }
{code}

1. Put first item with TTL = 1 hour. CleanupWorker will go to sleep for 1 hour.

2. Put second item with TTL = 1 minute. Since 
CleanupWorker's thread sleeps now, second item will not be expired at the time.

NOTE: This scenario is easily to reproducible if first and second items are put 
into cache asynchronously. If try to put them in same thread one-by-one 
expiration may work fine.




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

[jira] [Created] (IGNITE-3512) .NET: IBinaryObject.ToBuilder loses type name

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-3512:
--

 Summary: .NET: IBinaryObject.ToBuilder loses type name
 Key: IGNITE-3512
 URL: https://issues.apache.org/jira/browse/IGNITE-3512
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 1.5.0.final
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 1.7


Steps to reproduce:
* Create a builder for a string type name, set field, put to cache
* On another node, read this object, call ToBuilder, call Build

Type name is not propagated with metadata, which leads to assertion error (with 
-ea) or "Two binary types have duplicate type ID [typeId=949122880, 
typeName1=Security, typeName2=null]]" error.

Unit test:
{code}
[Test]
public void Test()
{
using (var grid1 = Ignition.Start(TestUtils.GetTestConfiguration()))
using (var grid2 = Ignition.Start(new 
IgniteConfiguration(TestUtils.GetTestConfiguration(false)) {GridName = 
"grid2"}))
{
var cache1 = grid1.CreateCache("cache").WithKeepBinary();
var obj1 = 
grid1.GetBinary().GetBuilder("myType").SetField("myField", "val").Build();
cache1[1] = obj1;

var cache2 = grid2.GetCache("cache").WithKeepBinary();
var obj2 = cache2[1];
var val = obj2.GetField("myField");
var obj2Ex = 
grid2.GetBinary().GetBuilder(obj2).SetField("myField", val + 
"_modified").Build();

cache2[2] = obj2Ex;
}
}
{code}



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

Re: Ignite monitoring

[Andrey Novikov]

Igor,

Ignite does not have monitoring in Web Console, only Configuration and SQL.
But command-line Visor in Ignite have some monitoring features and can be
used  to add new.

On Wed, Jul 20, 2016 at 1:19 AM, Igor Rudyak  wrote:

> Are there any documentation regarding how to use Ignite web console? How to
> add new metrics to monitor?
>
> On Mon, Jul 18, 2016 at 10:47 AM, Dmitriy Setrakyan  >
> wrote:
>
> > On Mon, Jul 18, 2016 at 8:45 PM, Alexey Kuznetsov <
> akuznet...@gridgain.com
> > >
> > wrote:
> >
> > > I think we should have some general API and we could call it from web
> > > console and/or from other places.
> > >
> >
> > Agree. The server side support should be sufficient to enable different
> > monitoring connections, including command-line visor, web console, or JMX
> > beans.
> >
> >
> > > 18 Июл 2016 г. 20:18 пользователь "Dmitriy Setrakyan" <
> > > dsetrak...@apache.org>
> > > написал:
> > >
> > > > I think we can add this functionality to Ignite web console, no?
> > > >
> > > > On Mon, Jul 18, 2016 at 11:08 AM, Vladimir Ozerov <
> > voze...@gridgain.com>
> > > > wrote:
> > > >
> > > > > Igor,
> > > > >
> > > > > I think that built-in monitoring facility will add great value to
> the
> > > > > product. We have to deal with user performance issues pretty often,
> > and
> > > > it
> > > > > is always a kind of pain to get to the bottom of the problem. We
> have
> > > to
> > > > > ask users for configuration, logs, system config, etc, etc..
> Instead,
> > > it
> > > > > would be great if we had a single big "switch". If user has
> > performance
> > > > > issue, he turns it on, then perform problematic operations, and
> then
> > > > dumps
> > > > > all collected data. We can collect dozens of things:
> > > > > 1) OS/JVM information
> > > > > 2) Ignite configs, logs, etc..
> > > > > 3) Performance data (CPU, RAM, IO)
> > > > > 4) Metrics
> > > > > 5) JMX data (both Ignite and JVM)
> > > > > 6) Some internal tracing (SQL query plans, how long it takes
> messages
> > > to
> > > > > pass between nodes, etc.)
> > > > >
> > > > > I think the most important part here is good infrastructure
> > > (interfaces)
> > > > > and API. So that we can start with something very simple, like
> > > collecting
> > > > > configs from all nodes, or starting/stopping shell commands, and
> then
> > > > > gradually add more and more tracing facilities.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > Vladimir.
> > > > >
> > > > >
> > > > > On Thu, Jul 14, 2016 at 11:36 PM, Igor Rudyak 
> > > wrote:
> > > > >
> > > > > > Yakov, as for now I just have well structured scripts to setup
> > > Ganglia
> > > > > > agent on Ignite hosts to monitor system metrics like CPU, RAM, IO
> > and
> > > > etc
> > > > > > (this scripts already included in Ignite 1.6).
> > > > > >
> > > > > > Also experimented with displaying JVM metrics by providing java
> > agent
> > > > and
> > > > > > specifying MBeans to collect metrics from. But it's rather draft
> > > > version.
> > > > > > The second problem is, there are plenty of MBeans in Ignite - I
> > just
> > > > > don't
> > > > > > know which to select from.
> > > > > >
> > > > > > Anyway, the original idea was to check with the community if it
> > makes
> > > > > sense
> > > > > > to have such monitoring functionality out of the box.
> > > > > >
> > > > > > Igor Rudyak
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, Jul 14, 2016 at 1:05 AM, Yakov Zhdanov <
> > yzhda...@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > > Igor, can you please share the changes to scripts you did to
> > > support
> > > > > > > monitoring? Can it be done by defining and exporting JAVA_OPTS
> > env
> > > > > > variable
> > > > > > > and then launching ignite.sh?
> > > > > > >
> > > > > > > Thanks!
> > > > > > >
> > > > > > > --Yakov
> > > > > > >
> > > > > > > 2016-07-13 22:45 GMT+03:00 Igor Rudyak :
> > > > > > >
> > > > > > > > Hi guys,
> > > > > > > >
> > > > > > > > While experimenting with large Ignite clusters I found that
> > lack
> > > of
> > > > > > > > monitoring is rather critical problem. I know that Ignite
> > > provides
> > > > > > number
> > > > > > > > of JMX MBeans to monitor custom metrics in addition to host
> > > system
> > > > > > > metrics
> > > > > > > > (CPU, IO, RAM, ). The problem is, there are no out of the
> > box
> > > > > > > solution
> > > > > > > > to monitor all this.
> > > > > > > >
> > > > > > > > Thus you have to manually setup some kind of monitoring tool
> > like
> > > > > > > Graphite,
> > > > > > > > Grafana, Ganglia and etc. Which involves setting up
> monitoring
> > > > agents
> > > > > > on
> > > > > > > > all the nodes, uploading JMX agent on all the nodes,
> selecting
> > > > > > > appropriate
> > > > > > > > metrics from the plenty of JMX MBeans and preparing config
> > files,
> > > > > > tuning
> > > > > > > > Ignite shell scripts to include "java agent" in java launch
> > > > command.
> > > > > > Lots
> > > > > > > > of work and pain, each time y

Re: IGNITE-2294 implementation details

[Alexander Paschenko]

> Thus, I suggest that we implement MERGE as a separate operation backed by 
> putIfAbsent operation, while INSERT will be implemented via put.

Sorry, of course I meant that MERGE has to be put-based, while INSERT
has to be putIfAbsent-based.

2016-07-20 12:30 GMT+03:00 Alexander Paschenko
:
> Hell Igniters,
>
> In this thread I would like to share and discuss some thoughts on DML
> operations' implementation, so let's start and keep it here. Everyone
> is of course welcome to share their suggestions.
>
> For starters, I was thinking about semantics of INSERT. In traditional
> RDBMSs, INSERT works only for records whose primary keys don't
> conflict with those of records that are already persistent - you can't
> try to insert the same key more than once because you'll get an error.
> However, semantics of cache put is obviously different - it does not
> have anything about duplicate keys, it just quietly updates values in
> case of keys' duplication. Still, cache has putIfAbsent operation that
> is closer to traditional notion of INSERT, and H2's SQL dialect has
> MERGE operation which corresponds to semantics of cache put. Thus, I
> suggest that we implement MERGE as a separate operation backed by
> putIfAbsent operation, while INSERT will be implemented via put.
>
> And one more, probably more important thing: I suggest that we create
> separate class Update and corresponding operation update() in
> IgniteCache. The reasons are as follows:
>
> - Query bears some flags that are clearly redundant for Update (page
> size, locality)
> - query() method in IgniteCache (one that accepts Query) and query()
> methods in GridQueryIndexing return iterators. So, if we strive to
> leave interfaces unchanged, we still will introduce some design
> ugliness like query methods returning empty iterators for certain
> queries, and/or query flags that indicate whether it's an update query
> or not, etc.
> - If some Queries are update queries, then continuous queries can't be
> based on them - more design-wise ugly checks and stuff like that.
> - I'm pretty sure there's more I don't know about.
>
> Comments and suggestions are welcome. Sergi Vladykin, Dmitry
> Setrakyan, your opinions are of particular interest, please advise.
>
> Regards,
> Alex

IGNITE-2294 implementation details

[Alexander Paschenko]

Hell Igniters,

In this thread I would like to share and discuss some thoughts on DML
operations' implementation, so let's start and keep it here. Everyone
is of course welcome to share their suggestions.

For starters, I was thinking about semantics of INSERT. In traditional
RDBMSs, INSERT works only for records whose primary keys don't
conflict with those of records that are already persistent - you can't
try to insert the same key more than once because you'll get an error.
However, semantics of cache put is obviously different - it does not
have anything about duplicate keys, it just quietly updates values in
case of keys' duplication. Still, cache has putIfAbsent operation that
is closer to traditional notion of INSERT, and H2's SQL dialect has
MERGE operation which corresponds to semantics of cache put. Thus, I
suggest that we implement MERGE as a separate operation backed by
putIfAbsent operation, while INSERT will be implemented via put.

And one more, probably more important thing: I suggest that we create
separate class Update and corresponding operation update() in
IgniteCache. The reasons are as follows:

- Query bears some flags that are clearly redundant for Update (page
size, locality)
- query() method in IgniteCache (one that accepts Query) and query()
methods in GridQueryIndexing return iterators. So, if we strive to
leave interfaces unchanged, we still will introduce some design
ugliness like query methods returning empty iterators for certain
queries, and/or query flags that indicate whether it's an update query
or not, etc.
- If some Queries are update queries, then continuous queries can't be
based on them - more design-wise ugly checks and stuff like that.
- I'm pretty sure there's more I don't know about.

Comments and suggestions are welcome. Sergi Vladykin, Dmitry
Setrakyan, your opinions are of particular interest, please advise.

Regards,
Alex

Re: Ignite 2.0 tasks/roadmap

[Pavel Tupitsyn]

Dmitriy, you have agreed with me in the old thread, and now you don't?
Binarylizable (current) is longer than Binarizable (proposed).

On Wed, Jul 20, 2016 at 10:24 AM, Dmitriy Setrakyan  wrote:

>
>
>
> > On Jul 20, 2016, at 9:17 AM, Pavel Tupitsyn 
> wrote:
> >
> > How about renaming Binarylizable interface?
> >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Naming-Binarylizable-td4592.html
>
> Pavel, I would not rename. The name you are suggesting is very hard to
> pronounce.
>
> >
> > On Sat, Jul 16, 2016 at 10:25 AM, Sergi Vladykin <
> sergi.vlady...@gmail.com>
> > wrote:
> >
> >> Alexey K.,
> >>
> >> No problem, here it is
> https://issues.apache.org/jira/browse/IGNITE-3488
> >>
> >> Sergi
> >>
> >> On Sat, Jul 16, 2016 at 2:00 AM, Valentin Kulichenko <
> >> valentin.kuliche...@gmail.com> wrote:
> >>
> >>> Folks,
> >>>
> >>> I created one more ticket related to SQL:
> >>> https://issues.apache.org/jira/browse/IGNITE-3487. It's a usability
> >> issue
> >>> that pops up on user forum every now and then. Since it's a
> compatibility
> >>> breaking changed, it looks like a good candidate for 2.0.
> >>>
> >>> -Val
> >>>
> >>> On Fri, Jul 15, 2016 at 11:56 AM, Alexey Kuznetsov <
> >>> akuznet...@gridgain.com>
> >>> wrote:
> >>>
>  Sergi, that was my idea to drop nulls but I have limited access to
> >>> internet
>  (I'm on vacation) could you create issue in JIRA?
> 
>  Thanks.
> 
>  Alexey Kuznetsov
> 
>  15 Июл 2016 г. 15:17 пользователь "Sergi Vladykin" <
>  sergi.vlady...@gmail.com>
>  написал:
> 
>  Huge +1 for dropping support for null in all names, not only for cache
>  names. Do we have ticket for this one?
> 
>  Sergi
> 
>  On Fri, Jul 15, 2016 at 2:00 PM, Andrey Velichko <
> andrey4...@gmail.com
> >>>
>  wrote:
> 
> >
> > 15.07.2016 0:31, Dmitriy Setrakyan пишет:
> >
> >> On Fri, Jul 15, 2016 at 12:26 AM, AndreyVel
>  wrote:
> >>
> >> Good feature may be Aggregated cache - analog materialized view in
> >>> DBMS
> >>> Aggregated cache is great for performance (KPI, analytecal
> >> reports).
> >>>
> >>> Do you mean a copy of the aggregated data in another cache? What
>  happens
> >> when the data in the original caches is updated?
> >>
> >>
> >>
> > Yes, aggregated data can be store in another cache,
> > embedded aggregating cache can be updated sync/async. Aggregating
> >> from
>  the
> > box has better performance then creating custom event listeners.
> >
> > If cache entry updated/deleted aggregate listener can get 2 values
> >> old
>  and
> > new.
> >
> 
> >>>
> >>
>

Re: Ignite 2.0 tasks/roadmap

[Dmitriy Setrakyan]

> On Jul 20, 2016, at 9:17 AM, Pavel Tupitsyn  wrote:
> 
> How about renaming Binarylizable interface?
> 
> http://apache-ignite-developers.2346864.n4.nabble.com/Naming-Binarylizable-td4592.html

Pavel, I would not rename. The name you are suggesting is very hard to 
pronounce.

> 
> On Sat, Jul 16, 2016 at 10:25 AM, Sergi Vladykin 
> wrote:
> 
>> Alexey K.,
>> 
>> No problem, here it is https://issues.apache.org/jira/browse/IGNITE-3488
>> 
>> Sergi
>> 
>> On Sat, Jul 16, 2016 at 2:00 AM, Valentin Kulichenko <
>> valentin.kuliche...@gmail.com> wrote:
>> 
>>> Folks,
>>> 
>>> I created one more ticket related to SQL:
>>> https://issues.apache.org/jira/browse/IGNITE-3487. It's a usability
>> issue
>>> that pops up on user forum every now and then. Since it's a compatibility
>>> breaking changed, it looks like a good candidate for 2.0.
>>> 
>>> -Val
>>> 
>>> On Fri, Jul 15, 2016 at 11:56 AM, Alexey Kuznetsov <
>>> akuznet...@gridgain.com>
>>> wrote:
>>> 
 Sergi, that was my idea to drop nulls but I have limited access to
>>> internet
 (I'm on vacation) could you create issue in JIRA?
 
 Thanks.
 
 Alexey Kuznetsov
 
 15 Июл 2016 г. 15:17 пользователь "Sergi Vladykin" <
 sergi.vlady...@gmail.com>
 написал:
 
 Huge +1 for dropping support for null in all names, not only for cache
 names. Do we have ticket for this one?
 
 Sergi
 
 On Fri, Jul 15, 2016 at 2:00 PM, Andrey Velichko >> 
 wrote:
 
> 
> 15.07.2016 0:31, Dmitriy Setrakyan пишет:
> 
>> On Fri, Jul 15, 2016 at 12:26 AM, AndreyVel
 wrote:
>> 
>> Good feature may be Aggregated cache - analog materialized view in
>>> DBMS
>>> Aggregated cache is great for performance (KPI, analytecal
>> reports).
>>> 
>>> Do you mean a copy of the aggregated data in another cache? What
 happens
>> when the data in the original caches is updated?
>> 
>> 
>> 
> Yes, aggregated data can be store in another cache,
> embedded aggregating cache can be updated sync/async. Aggregating
>> from
 the
> box has better performance then creating custom event listeners.
> 
> If cache entry updated/deleted aggregate listener can get 2 values
>> old
 and
> new.
> 
 
>>> 
>>