WebConsole configuration wizard doesn't properly handle multiple RDBMS

Alex K, Andrey N, Imagine a use case when cache_A needs to persist data in database_A while cache_B has to be connected with database_B as a part of a single application. WebConsole allows importing a schema from both databases but: • in a final Spring XML configuration there will be

[jira] [Created] (IGNITE-5303) WebConsole configuration wizard doesn't properly handle multiple RDBMS

Denis Magda created IGNITE-5303: --- Summary: WebConsole configuration wizard doesn't properly handle multiple RDBMS Key: IGNITE-5303 URL: https://issues.apache.org/jira/browse/IGNITE-5303 Project: Ignite

Re: New blog post: ADO.NET Ignite Cache Store

Great, Pavel! You rock! Prachi, could you send the post to DZone and publish on Ignite’s page? — Denis > On May 26, 2017, at 10:06 AM, Pavel Tupitsyn wrote: > > Short writeup with example code, inspired by user questions: > > ADO.NET + Binary Mode

[RESULT][VOTE] Accept Contribution of Ignite Persistent Store

Igniters, Thanks to all for you for the participating in the VOTE: http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Accept-Contribution-of-Ignite-Persistent-Store-td17896.html

[RESULT][VOTE] Accept Contribution of Ignite Persistent Store

Igniters, Thanks to all for you for the participating in the VOTE: http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Accept-Contribution-of-Ignite-Persistent-Store-td17896.html The VOTE is closed with nine “+1” votes: - Semyon Boikov (binding) - Valentin Kulichenko (binding) - Sergi

Re: Persistent Store example fails with NPE

Well, merged the fix to the branch with the donation and closed the ticket: https://issues.apache.org/jira/browse/IGNITE-5295 — Denis > On May 26, 2017, at 1:25 PM, Denis Magda wrote: > > As I see from the AffinityFunction

Re: Unclear configuration parameters of Persistent Store

Alex G., > * PersistentStoreConfiguration.setWalHistorySize > * PersistentStoreConfiguration.setWalArchivePath I could figure out the goal of these two parameters below referring to the store architecture guide [1] and updated the Java docs. > PersistentStoreConfiguration.setLockWaitTime

Re: Persistent Store example fails with NPE

As I see from the AffinityFunction implementations, client nodes are not used there that implies there is no way to deploy replicated and partitioned caches there. — Denis > On May 26, 2017, at 12:19 PM, Dmitriy Setrakyan wrote: > > On Fri, May 26, 2017 at 12:17 PM,

Re: Persistent Store example fails with NPE

On Fri, May 26, 2017 at 12:17 PM, Denis Magda wrote: > Local and near caches can be configured on clients. But you can still > define replicated and partitioned ones in the clients’ configuration and > they will be simply ignored. I want us to do the same for the persistent >

Re: Persistent Store example fails with NPE

Local and near caches can be configured on clients. But you can still define replicated and partitioned ones in the clients’ configuration and they will be simply ignored. I want us to do the same for the persistent store (simply ignore it if it’s defined in a client’s configuration). Sounds

Re: Persistent Store example fails with NPE

On Fri, May 26, 2017 at 11:59 AM, Denis Magda wrote: > Exactly, you can specify caches in the configuration of both clients and > servers BUT the caches will be deployed on the servers only. > This is why it’s absolutely fine to use a single configuration (with > caches

Re: Reason for disabling @QuerySqlField and @AffinityKeyMapped annotations on methods

On Fri, May 26, 2017 at 12:01 PM, Vladimir Ozerov wrote: > I even think that we should remove Marshaller interface at all in future > major release and use only binary. Too many things just work without > BinaryMarshaller. We cannot afford non-binary Marshallers any more. >

Re: Reason for disabling @QuerySqlField and @AffinityKeyMapped annotations on methods

I even think that we should remove Marshaller interface at all in future major release and use only binary. Too many things just work without BinaryMarshaller. We cannot afford non-binary Marshallers any more. пт, 26 мая 2017 г. в 21:49, Dmitriy Setrakyan : > On Fri, May

Re: Persistent Store example fails with NPE

Exactly, you can specify caches in the configuration of both clients and servers BUT the caches will be deployed on the servers only. This is why it’s absolutely fine to use a single configuration (with caches defined) for all your cluster nodes because Ignite can automatically figure out what

Re: Reason for disabling @QuerySqlField and @AffinityKeyMapped annotations on methods

On Fri, May 26, 2017 at 8:29 AM, Igor Rudyak wrote: > If binary objects is the only option starting from Ignite 2.0 than it makes > sense. > > If we still support regular java objects, than it looks a bit confusing to > disallowing such annotations. Especially if they don't

Re: Persistent Store example fails with NPE

I tend to use a single XML configuration for all my cluster nodes (servers and clients). Presently, I forced to create and maintain at least 2. This is the first concern. The second concern is if persistence store has no effect for the client node why not simply ignore it and not make the user

Re: Persistent Store example fails with NPE

On Fri, May 26, 2017 at 11:29 AM, Denis Magda wrote: > > Can we just fix the exception > > message to clearly state that client mode requires all explicit > > configuration for such and such functionality? > > I don’t like this. It will require me as a user: > > * have a

Re: Persistent Store example fails with NPE

> Can we just fix the exception > message to clearly state that client mode requires all explicit > configuration for such and such functionality? I don’t like this. It will require me as a user: * have a separate configuration for clients ALL the times. * initialize the memory bean explicitly

Re: AffinityKeyMapper

On Fri, May 26, 2017 at 8:48 AM, Sergi Vladykin wrote: > Guys, > > As I see we did not drop AffinityKeyMapper for 2.0. > > May be lets at least deprecate it? > I think we must. Any objections?

Re: Persistent Store example fails with NPE

I don't like ignoring any configuration, but I do agree that enabling persistence on the client side seems odd. Can we just fix the exception message to clearly state that client mode requires all explicit configuration for such and such functionality? D. On Fri, May 26, 2017 at 10:34 AM, Sergey

Re: Persistent Store example fails with NPE

Denis, Thanks for quick reply, I made a change and tested it with your example, everything looks fine. Pull request is open and available at [1] [1] https://github.com/apache/ignite/pull/2016 On Fri, May 26, 2017 at 8:25 PM, Denis Magda wrote: > > I would suggest on the

Re: Persistent Store example fails with NPE

> I would suggest on the first iteration to simply ignore persistence > configuration on client nodes. > If client node finds persistence configuration on startup it will printout > warning message to log and proceed without persistence. +1 for this. Otherwise, it looks like a dirty hack when I

[GitHub] ignite pull request #2016: persistence configuration should be ignored on cl...

GitHub user sergey-chugunov-1985 opened a pull request: https://github.com/apache/ignite/pull/2016 persistence configuration should be ignored on client nodes You can merge this pull request into a Git repository by running: $ git pull

New blog post: ADO.NET Ignite Cache Store

Short writeup with example code, inspired by user questions: ADO.NET + Binary Mode Cache Store https://ptupitsyn.github.io/Ado-Net-Cache-Store/

Re: Persistent Store example fails with NPE

Moreover, enabling persistence on client node is very risky and may lead to many tricky cases. I would suggest on the first iteration to simply ignore persistence configuration on client nodes. If client node finds persistence configuration on startup it will printout warning message to log and

Re: Persistent Store example fails with NPE

Denis, I see from example that you're trying to start a client node with persistence configuration specified and you're saying that Ignite must provide default MemoryConfiguration. But that contradicts with decision we all agreed on in the discussion[1]: if user wants to do something unusual on

Re: Persistent Store example fails with NPE

Sergey, The issue vanishes as soon as I add the following to the configuration: My point is that we just need to create a MemoryConfiguration implicitly if it’s not defined (no any warnings or extra messages). It’s a responsibility of our platform to generate a default

AffinityKeyMapper

Guys, As I see we did not drop AffinityKeyMapper for 2.0. May be lets at least deprecate it? Sergi

Re: Persistent Store example fails with NPE

Hi Denis, What is the expected behavior in that case? Bug doesn't suggest any. >From my point of view it would be better to throw an exception on startup with meaningful message than to silently create a default MemoryConfiguration under the cover. Thanks, Sergey. On Fri, May 26, 2017 at 4:00

Re: Reason for disabling @QuerySqlField and @AffinityKeyMapped annotations on methods

If binary objects is the only option starting from Ignite 2.0 than it makes sense. If we still support regular java objects, than it looks a bit confusing to disallowing such annotations. Especially if they don't break anything. Igor On May 26, 2017 12:55 AM, "Vladimir Ozerov"

[GitHub] ignite pull request #2015: IGNITE-5087

GitHub user NSAmelchev opened a pull request: https://github.com/apache/ignite/pull/2015 IGNITE-5087 Fix Enum comparison fails after marshal-unmarshal with BinaryMarshaller. You can merge this pull request into a Git repository by running: $ git pull

[jira] [Created] (IGNITE-5302) Empty LOST partition may be used as OWNING after resetting lost partitions

Sergey Chugunov created IGNITE-5302: --- Summary: Empty LOST partition may be used as OWNING after resetting lost partitions Key: IGNITE-5302 URL: https://issues.apache.org/jira/browse/IGNITE-5302

[jira] [Created] (IGNITE-5301) JVM crushes on H2TreeIndex destroy

Igor Seliverstov created IGNITE-5301: Summary: JVM crushes on H2TreeIndex destroy Key: IGNITE-5301 URL: https://issues.apache.org/jira/browse/IGNITE-5301 Project: Ignite Issue Type: Bug

[jira] [Created] (IGNITE-5300) .NET: LINQ RemoveAll examples

Pavel Tupitsyn created IGNITE-5300: -- Summary: .NET: LINQ RemoveAll examples Key: IGNITE-5300 URL: https://issues.apache.org/jira/browse/IGNITE-5300 Project: Ignite Issue Type: Improvement

Re: Ignite 2.0 TeamCity Run configurations

Igniters, I've found one more suite without tests: "Ignite Cache Failover Multi JVM" (org.apache.ignite.testsuites.IgniteCacheFailoverMJTestSuite). Currently has paused triggers, but anyway started from Ignite 2.0 snapshot dependecies. Is it required? Alex (al.psc) do you know? it is required in

[GitHub] ignite pull request #1678: Ignite 1925

Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/1678 --- 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

[jira] [Created] (IGNITE-5299) Don't set IgniteLock as broken if lock is failoverSafe

Evgenii Zhuravlev created IGNITE-5299: - Summary: Don't set IgniteLock as broken if lock is failoverSafe Key: IGNITE-5299 URL: https://issues.apache.org/jira/browse/IGNITE-5299 Project: Ignite

Re: IgfsPerBlockLruEvictionPolicy does not work as expected any more, what shall we do with it?

Denis, many thanks for the info. Phrase in docs "on-heap caching is for scenarios when you do a lot of cache reads on server nodes that *work with cache entries in the binary form* or invoke cache entries' deserialization." may be contains a mistake: should it say "*work with cache entries in

Re: Ignite 2.0 TeamCity Run configurations

Thank you! I've commited removal of both suites to PR https://github.com/apache/ignite/pull/2014 пт, 26 мая 2017 г. в 14:53, Vladimir Ozerov : > No, we should remote this suite. > > On Fri, May 26, 2017 at 2:48 PM, Semyon Boikov > wrote: > > > What

Re: Ignite 2.0 TeamCity Run configurations

No, we should remote this suite. On Fri, May 26, 2017 at 2:48 PM, Semyon Boikov wrote: > What about 'Ignite H2 Indexing' suite', it does not execute any test? > > On Fri, May 26, 2017 at 2:18 PM, Dmitry Pavlov > wrote: > > > Hi Semen, > > > > > > >

Re: Ignite 2.0 TeamCity Run configurations

What about 'Ignite H2 Indexing' suite', it does not execute any test? On Fri, May 26, 2017 at 2:18 PM, Dmitry Pavlov wrote: > Hi Semen, > > > > Thank you for this fix. It is correct to replace to IgniteCacheTestSuite4 > in new 2.0 run configurations as we don’t have

[GitHub] ignite pull request #1968: Ignite 4575 binary enum for test purposes

Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/1968 --- 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

[GitHub] ignite pull request #1721: Ignite 4477 Fix IgniteFuture.listen() and IgniteF...

Github user dkarachentsev closed the pull request at: https://github.com/apache/ignite/pull/1721 --- 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

Re: Ignite 2.0 TeamCity Run configurations

I just found that 'Ignite Cache 4' was not executed on TeamCity since it has from suite name in configuration, I fixed it to use IgniteCacheTestSuite4, is it correct? Aslo why we need both IgniteBinaryObjectsCacheTestSuite3 and IgniteCacheTestSuite3? And why IgniteBinaryBasicTestSuite is not

[GitHub] ignite pull request #2013: IGNITE-5259 Minor serialization fix

GitHub user dkarachentsev opened a pull request: https://github.com/apache/ignite/pull/2013 IGNITE-5259 Minor serialization fix (cherry picked from commit b2040b7) You can merge this pull request into a Git repository by running: $ git pull

Re: DiscoverySpi#setDataExchange returns concrete implementation

Hi Nick! Good catch. Please go ahead and submit a patch. --Yakov 2017-05-26 13:09 GMT+03:00 Николай Ижиков : > Hello, guys. > > public interface DiscoverySpi extends IgniteSpi { > > TcpDiscoverySpi setDataExchange(DiscoverySpiDataExchange var1); > >

DiscoverySpi#setDataExchange returns concrete implementation

Hello, guys. public interface DiscoverySpi extends IgniteSpi { TcpDiscoverySpi setDataExchange(DiscoverySpiDataExchange var1); TcpDiscoverySpi setMetricsProvider(DiscoveryMetricsProvider var1); ... } Two methods of DiscoverySpi returns concrete implementation. I think we should

[jira] [Created] (IGNITE-5298) .NET: DML update via LINQ

Pavel Tupitsyn created IGNITE-5298: -- Summary: .NET: DML update via LINQ Key: IGNITE-5298 URL: https://issues.apache.org/jira/browse/IGNITE-5298 Project: Ignite Issue Type: New Feature

[GitHub] ignite pull request #2009: IGNITE-4904 .NET: DML Delete via LINQ

Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/2009 --- 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

[GitHub] ignite pull request #2011: GNITE-5038 BinaryMarshaller might need to use con...

GitHub user vldpyatkov opened a pull request: https://github.com/apache/ignite/pull/2011 GNITE-5038 BinaryMarshaller might need to use context class loader for deserialization IGNITE-5038 BinaryMarshaller might need to use context class loader for deserialization You can merge