Re: IgniteCache.loadCache improvement proposal

As far as I can understand Alex was trying to avoid the scenario when user needs to bring 1Tb dataset to each node of 50 nodes cluster and then discard 49/50 of data loaded. For me this seems to be a very good catch. However, I agree with Val that this may be implemented apart from store and user

[GitHub] ignite pull request #1233: Ignite 3075 2

GitHub user kdudkov opened a pull request: https://github.com/apache/ignite/pull/1233 Ignite 3075 2 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-3075-2 Alternatively you can review and apply

[GitHub] ignite pull request #1232: Ignite 3074 2

GitHub user kdudkov opened a pull request: https://github.com/apache/ignite/pull/1232 Ignite 3074 2 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-3074-2 Alternatively you can review and apply

Re: IgniteCache.loadCache improvement proposal

Hi all, I think the discussion goes a wrong direction. Certainly it's not a big deal to implement some custom user logic to load the data into caches. But Ignite framework gives the user some reusable code build on top of the basic system. So the main question is: Why developers let the user to

[jira] [Created] (IGNITE-4223) Joining node should fetch affinity for all caches using single message

Semen Boikov created IGNITE-4223: Summary: Joining node should fetch affinity for all caches using single message Key: IGNITE-4223 URL: https://issues.apache.org/jira/browse/IGNITE-4223 Project:

Re: IgniteCache.loadCache improvement proposal

Hi Alex, >>> Let's give the user the reusable code which is convenient, reliable and fast. Convenience - this is why I asked for example on how API can look like and how users are going to use it. Vladimir. On Tue, Nov 15, 2016 at 11:18 AM, Alexandr Kuramshin wrote: > Hi

Re: IGNITE-3066 Set of Redis commands that can be easily implemented via existing REST commands

Roman, I reviewed your code and added comments in JIRA. May we will try to use Upsource (http://reviews.ignite.apache.org/) for code review? On Tue, Nov 15, 2016 at 1:22 PM, Roman Shtykh wrote: > Alexey, > Thank you for your thorough reviews! I fixed the issues. >

[jira] [Created] (IGNITE-4224) Resolve JdbcQueryTask compatibility issues

Alexander Paschenko created IGNITE-4224: --- Summary: Resolve JdbcQueryTask compatibility issues Key: IGNITE-4224 URL: https://issues.apache.org/jira/browse/IGNITE-4224 Project: Ignite

[GitHub] ignite pull request #1230: IGNITE-4134 .NET: Add CacheConfiguration.ExpiryPo...

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

Re: Apache Ignite 1.8 Release

Denis, I can merge PDO-related changes into 1.8 but without DML they will break tests and even compilation so I don't see any sense in doing that before DML is merged. After DML is ready and merged I'll need some time to merge my changes and check that everything works as intended. The code

[jira] [Created] (IGNITE-4226) Redis SET command should handle expirations

Roman Shtykh created IGNITE-4226: Summary: Redis SET command should handle expirations Key: IGNITE-4226 URL: https://issues.apache.org/jira/browse/IGNITE-4226 Project: Ignite Issue Type:

Re: IgniteCache.loadCache improvement proposal

Hi Vladimir, I don't offer any changes in API. Usage scenario is the same as it was described in https://apacheignite.readme.io/docs/persistent-store#section-loadcache- The preload cache logic invokes IgniteCache.loadCache() with some additional arguments, depending on a CacheStore

[GitHub] ignite pull request #1234: IGNITE-4125 .NET: MultiTieredCacheExample added

GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/1234 IGNITE-4125 .NET: MultiTieredCacheExample added You can merge this pull request into a Git repository by running: $ git pull https://github.com/ptupitsyn/ignite ignite-4125 Alternatively

Re: IgniteCache.loadCache improvement proposal

On Tue, Nov 15, 2016 at 9:07 AM, Yakov Zhdanov wrote: > As far as I can understand Alex was trying to avoid the scenario when user > needs to bring 1Tb dataset to each node of 50 nodes cluster and then > discard 49/50 of data loaded. For me this seems to be a very good

Re: Apache Ignite 1.8 Release

Denis, [1] depends on [2], and [2](.NET: CacheEntryProcessor binary mode) is not a simple thing. We won't be able to do that for 1.8. Other than that, I'll try to fit as many of them as I can. But I can't answer your question since I don't see any date yet. By the way, you were going to help with

[GitHub] ignite pull request #1217: IGNITE-4120: Deadlock Detection Example

Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/1217 --- 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-4225) DataStreamer can hang on changing topology

Anton Vinogradov created IGNITE-4225: Summary: DataStreamer can hang on changing topology Key: IGNITE-4225 URL: https://issues.apache.org/jira/browse/IGNITE-4225 Project: Ignite Issue

Re: IgniteCache.loadCache improvement proposal

Hi, All! I think we do not need to chage API at all. public void loadCache(@Nullable IgniteBiPredicate p, @Nullable Object... args) throws CacheException; We could pass any args to loadCache(); So we could create class IgniteCacheLoadDescriptor { some fields that will describe how to

[GitHub] ignite pull request #1236: IGNITE-4137 .NET: Atomic examples added

GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/1236 IGNITE-4137 .NET: Atomic examples added You can merge this pull request into a Git repository by running: $ git pull https://github.com/ptupitsyn/ignite ignite-4137 Alternatively you can

Re: Service proxy API changes

I would still add a timeout there. In my view, it makes sense to have such option. Currently user thread can block indefinitely or loop in while(true) forever. -Val On Tue, Nov 15, 2016 at 7:10 AM, Dmitriy Karachentsev < dkarachent...@gridgain.com> wrote: > Perfect, thanks! > > On Tue, Nov 15,

[GitHub] ignite pull request #1235: IGNITE-4175: SQL: JdbcResultSet class wasNull() m...

GitHub user AMashenkov opened a pull request: https://github.com/apache/ignite/pull/1235 IGNITE-4175: SQL: JdbcResultSet class wasNull() method should return true on NULL fields You can merge this pull request into a Git repository by running: $ git pull

Re: Service proxy API changes

To avoid log pollution we usually use LT class (alias for GridLogThrottle). Please check if it can help you. On Tue, Nov 15, 2016 at 5:48 PM, Dmitriy Karachentsev < dkarachent...@gridgain.com> wrote: > Vladimir, thanks for your reply! > > What you suggest definitely makes sense and it looks more

[jira] [Created] (IGNITE-4228) Missing documentation on CacheJdbcPojoStore

Alexander created IGNITE-4228: - Summary: Missing documentation on CacheJdbcPojoStore Key: IGNITE-4228 URL: https://issues.apache.org/jira/browse/IGNITE-4228 Project: Ignite Issue Type: Wish

Re: Service proxy API changes

Perfect, thanks! On Tue, Nov 15, 2016 at 5:56 PM, Vladimir Ozerov wrote: > To avoid log pollution we usually use LT class (alias for GridLogThrottle). > Please check if it can help you. > > On Tue, Nov 15, 2016 at 5:48 PM, Dmitriy Karachentsev < >

[GitHub] ignite pull request #1237: IGNITE-4227: Implemented SQLError.

GitHub user isapego opened a pull request: https://github.com/apache/ignite/pull/1237 IGNITE-4227: Implemented SQLError. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-4227 Alternatively you can

[jira] [Created] (IGNITE-4229) Loading configuration from XML into Console for further editing

Alexander created IGNITE-4229: - Summary: Loading configuration from XML into Console for further editing Key: IGNITE-4229 URL: https://issues.apache.org/jira/browse/IGNITE-4229 Project: Ignite

[GitHub] ignite pull request #1216: IGNITE-4175: SQL: JdbcResultSet class wasNull() m...

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

Re: Service proxy API changes

Vladimir, thanks for your reply! What you suggest definitely makes sense and it looks more reasonable solution. But there remains other thing. The second issue, that this solution solves, is prevent log pollution with GridServiceNotFoundException. The reason why it happens is because

Re: IgniteCache.loadCache improvement proposal

It sounds like Aleksandr is basically proposing to support automatic persistence [1] for loading through data streamer and we really don't have this. However, I think I have more generic solution in mind. What if we add one more IgniteCache.loadCache overload like this: loadCache(@Nullable

Re: Apache Ignite 1.8 Release

Pavel, Got you thanks. I’ve reviewed all the tickets that were waiting for my review. Please have a look at minor comments. — Denis > On Nov 15, 2016, at 12:31 AM, Pavel Tupitsyn wrote: > > Denis, [1] depends on [2], and [2](.NET: CacheEntryProcessor binary mode) is >

Re: IgniteCache.loadCache improvement proposal

How would your proposal resolve the main point Aleksandr is trying to convey that is extensive network utilization? As I see the loadCache method still will be triggered on every and as before all the nodes will pre-load all the data set from a database. That was Aleksandr’s reasonable

Re: Code Review Tool Proposal: Upsource

Pavel, Makes sense to me. Let’s start the voting process then adding the link to this discussion to the voting thread. I would wait no less than 5 days giving a chance to everyone to share his/her opinion. — Denis > On Nov 14, 2016, at 11:16 AM, Pavel Tupitsyn wrote: >

Re: IgniteCache.loadCache improvement proposal

You can use localLoadCache method for this (it should be overloaded as well of course). Basically, if you provide closure based on IgniteDataStreamer and call localLoadCache on one of the nodes (client or server), it's the same approach as described in [1], but with the possibility to reuse

Re: Service proxy API changes

Dmitry, I absolutely agree with this and I'm not saying that timeout solves any of these problems. However, it provides a bit of safety for such cases (client continues working instead of hanging forever) and also allows not too wait for the service too long which can be also useful sometimes

Re: IgniteCache.loadCache improvement proposal

Denis, The loading will be most likely initiated by the application anyway, even if you call localLoadCache on one of the server nodes. I.e. the flow is the following: 1. Client sends a closure to a server node (e.g. oldest or random). 2. The closure calls localLoadCache method. 3. If

Re: Apache Ignite 1.8 Release

Folks, As DML is the main feature for now, I propose to create *ignite-1.8 *branch when DML is ready. If nobody minds I will do that as soon as DML is merged and start vote when the rest minor things are cleared. Also I would like to remind that we still have a lot of tickets assigned on 1.8

[jira] [Created] (IGNITE-4230) Create documentation for the integration with Tableau

Denis Magda created IGNITE-4230: --- Summary: Create documentation for the integration with Tableau Key: IGNITE-4230 URL: https://issues.apache.org/jira/browse/IGNITE-4230 Project: Ignite Issue

Re: Connecting to Ignite from Tableau

Created the ticket for this task https://issues.apache.org/jira/browse/IGNITE-4230 Igor, it will be nice if you prepare a draft of the page at some point of time. — Denis > On Nov 8, 2016, at 7:40 PM, Dmitriy Setrakyan

Re: IgniteCache.loadCache improvement proposal

Val, Then I would create a blog post on how to use the new API proposed by you to accomplish the scenario described by Alexandr. Are you willing to write the post once the API is implemented? Alexandr, do you think the API proposed by Val will resolve your case when it’s used as listed below?

[GitHub] ignite pull request #1225: IGNITE-4198: Kafka Connect sink option to transfo...

Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/1225 --- 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 #1197: IGNITE-3191 BinaryObjectBuilder: binary schema id...

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

Re: Request for review IGNITE-4198

Hi Roman, Reviewed. One minor comment from my side in the ticket. Vladimir. On Tue, Nov 15, 2016 at 5:30 AM, Roman Shtykh wrote: > Hi Vladimir, > Thanks a lot for the review!I pushed the changes. Please let me know if it > is good to merge now. > -Roman > > > On

[jira] [Created] (IGNITE-4227) ODBC: Implement SQLError function

Igor Sapego created IGNITE-4227: --- Summary: ODBC: Implement SQLError function Key: IGNITE-4227 URL: https://issues.apache.org/jira/browse/IGNITE-4227 Project: Ignite Issue Type: Task

Re: Service proxy API changes

Also we implemented the same thing for platforms some time ago. In short, job result processing was implemented as follows (pseudocode): // Execute. Object res; try { res = job.run(); } catch (Exception e) { res = e } // Serialize result. try { SERIALIZE(res); } catch (Exception e)

Service proxy API changes

Hi Igniters! I'd like to modify our public API and add IgniteServices.serviceProxy() method with timeout argument as part of the task https://issues.apache.org/jira/browse/IGNITE-3862 In short, without timeout, in case of serialization error, or so, service acquirement may hang and infinitely

Re: Service proxy API changes

Dmitriy, Shouldn't we report serialization problem properly instead? We already had a problem when node hanged during job execution in case it was impossible to deserialize the job on receiver side. It was resolved properly - we caught exception on receiver side and reported it back sender side.

Re: IGNITE-3066 Set of Redis commands that can be easily implemented via existing REST commands

Andrey, Sure, but I couldn't sign up -- "Cannot complete request due to license limitations."Let's use github for now. Thank you for your review! -Roman On Tuesday, November 15, 2016 6:12 PM, Andrey Novikov wrote: Roman, I reviewed your code and added comments

Re: Apache Ignite 1.8 Release

Igor, It makes sense to wait for me while everything gets merged into 1.8 then. Please let me know over this discussion when the overall merge happens. — Denis > On Nov 15, 2016, at 1:45 AM, Igor Sapego wrote: > > Denis, > > I can merge PDO-related changes into 1.8 but

Re: Service proxy API changes

Valentin, as I understand, this situation is abnormal, and if user thread hangs on getting service proxy, it's worth to check logs for failure instead of making workaround. On 15.11.2016 19:47, Valentin Kulichenko wrote: I would still add a timeout there. In my view, it makes sense to have