Re: NodeJS thin client: full API

Alexey, Presently, Ignite hosts all the docs in readme.io without exception. It means that once your contribution is accepted by the community the Node.JS docs should be placed on readme.io. You're right saying that we're planning to migrate from readme.io to another documentation engine that

Re: NodeJS thin client: full API

Not yet. Need a help with that. -Alexey 11.05.2018 10:58, Dmitriy Setrakyan пишет: This is great! Finally a native NodeJS client for Ignite. Alexey, in addition to the functional tests, were you able to perform any load tests? D. On Fri, May 11, 2018 at 12:07 AM, Alexey Kosenchuk <

Re: NodeJS thin client: full API

This is great! Finally a native NodeJS client for Ignite. Alexey, in addition to the functional tests, were you able to perform any load tests? D. On Fri, May 11, 2018 at 12:07 AM, Alexey Kosenchuk < alexey.kosenc...@nobitlost.com> wrote: > Folks, > > The next version is ready - > in the pull

[GitHub] ignite pull request #3738: patch

Github user voipp closed the pull request at: https://github.com/apache/ignite/pull/3738 ---

[jira] [Created] (IGNITE-8470) NPE when starting LOCAL cache on a client with no data regions

Stanislav Lukyanov created IGNITE-8470: -- Summary: NPE when starting LOCAL cache on a client with no data regions Key: IGNITE-8470 URL: https://issues.apache.org/jira/browse/IGNITE-8470 Project:

REMINDER: Apache EU Roadshow 2018 schedule announced!

Hello Apache Supporters and Enthusiasts This is a reminder that the schedule for the Apache EU Roadshow 2018 in Berlin has been announced. http://apachecon.com/euroadshow18/schedule.html Please note that we will not be running an ApacheCon in Europe this year which means that this Apache EU

Re: NodeJS thin client: full API

On Fri, May 11, 2018 at 9:14 AM, Alexey Kosenchuk < alexey.kosenc...@nobitlost.com> wrote: > Not yet. Need a help with that. > I think we definitely need a load test before we merge to master. Can anyone in the community assist Alexey?

Re: Disable WAL for several cache groups within one exchange

Ivan, WAL disable for multiple caches was not implemented in the first place for a reason. We striven to maintain API consistency, "IgniteCluster.disableWal(cacheName)" maps exactly to "ALTER TABLE tableName NOLOGGING" command. There is no SQL equivalent for multiple caches. WAL disable for

[jira] [Created] (IGNITE-8473) Add option to enable/disable WAL for several caches with single command

Ivan Rakov created IGNITE-8473: -- Summary: Add option to enable/disable WAL for several caches with single command Key: IGNITE-8473 URL: https://issues.apache.org/jira/browse/IGNITE-8473 Project: Ignite

Re: Disable WAL for several cache groups within one exchange

It would be six methods in total (3 for enabling, 3 for disabling). What about accepting null in *enableWAL(String... caches)* as wildcard? Best Regards, Ivan Rakov On 11.05.2018 17:52, Andrey Mashenkov wrote: Ivan, Huge +1 for this improvement. I think we can have 2 overloaded method

Re: async operation is not fair async

Vladimir, Should we create the new cache adapter or rework GridCacheAdapter? On Fri, May 11, 2018 at 5:52 PM, Vladimir Ozerov wrote: > +1 > > This would also be helpful for transactional SQL as it would allow to hide > network latency. But there is a problem - deadlocks.

Re: Disable WAL for several cache groups within one exchange

Ivan, This proven to be too hard to understand. It is better to have a lot small methods with clear and compact semantics. Also arrays are harder to manage than collections, users typically prefer the latest. Also we need to think on what would be a result of this operation. Current methods with

Re: async operation is not fair async

Ivan, My suggestion "withFairAsync()". What do you think? On Fri, May 11, 2018 at 6:23 PM, Ivan Rakov wrote: > I think, the best option from API side is to add decorating > withExplicitAsync() method. > We already have withKeepBinary, withExpiryPolicy and so on. > > Best

Re: async operation is not fair async

Agree. "fair" is more descriptive. Best Regards, Ivan Rakov On 11.05.2018 18:30, Dmitriy Govorukhin wrote: Ivan, My suggestion "withFairAsync()". What do you think? On Fri, May 11, 2018 at 6:23 PM, Ivan Rakov wrote: I think, the best option from API side is to add

Re: Disable WAL for several cache groups within one exchange

Agree about collections. Regarding return type: it's a tricky question. Maybe author of this feature may help. Anton V., in which case enableWal/disableWal can return false? Best Regards, Ivan Rakov On 11.05.2018 18:19, Vladimir Ozerov wrote: Ivan, This proven to be too hard to understand.

[GitHub] ignite pull request #3789: IGNITE-7999 Enhance performance of the thin JDBC ...

Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/3789 ---

Re: Disable WAL for several cache groups within one exchange

Vladimir, I fully agree. We don't expose groups to public API (except for cache configuration), so we shouldn't start doing it here. Ignite issue for this improvement: https://issues.apache.org/jira/browse/IGNITE-8473 Best Regards, Ivan Rakov On 11.05.2018 17:49, Vladimir Ozerov wrote:

[jira] [Created] (IGNITE-8474) WalStateNodeLeaveExchangeTask prevents merge exchanges on leaving many nodes

Sergey Chugunov created IGNITE-8474: --- Summary: WalStateNodeLeaveExchangeTask prevents merge exchanges on leaving many nodes Key: IGNITE-8474 URL: https://issues.apache.org/jira/browse/IGNITE-8474

Re: async operation is not fair async

I think, the best option from API side is to add decorating withExplicitAsync() method. We already have withKeepBinary, withExpiryPolicy and so on. Best Regards, Ivan Rakov On 11.05.2018 18:18, Dmitriy Govorukhin wrote: Vladimir, Should we create the new cache adapter or rework

[GitHub] ignite pull request #3982: IGNITE-8464 removed file format after archive

GitHub user akalash opened a pull request: https://github.com/apache/ignite/pull/3982 IGNITE-8464 removed file format after archive You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8464

[GitHub] ignite pull request #3231: ignite-5874: Store TTL expire times in B+ tree on...

Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/3231 ---

Re: async operation is not fair async

+1 This would also be helpful for transactional SQL as it would allow to hide network latency. But there is a problem - deadlocks. We need to inform user that this mode should be used with great care. On Fri, May 11, 2018 at 5:21 PM, Dmitriy Govorukhin < dmitriy.govoruk...@gmail.com> wrote: >

Re: Disable WAL for several cache groups within one exchange

Ivan, Huge +1 for this improvement. I think we can have 2 overloaded method enableWal() with no args to enable WAL for all caches and enableWAL(String... caches) for one or multiple caches. (and same for disable wal) On Fri, May 11, 2018 at 5:25 PM, Dmitriy Govorukhin <

Disable WAL for several cache groups within one exchange

Igniters, API method for disabling WAL in IgniteCluster accepts only one cache name. Every call triggers exchange and checkpoints cluster-wide - it takes plenty of time to disable/enable WAL for multiple caches. I think, we should add option to disable/enable WAL for several caches with

Re: Disable WAL for several cache groups within one exchange

Ivan, Agree, if we have the batch method for cache create, we should have the ability to enable/disable WAL in the batch too. On Fri, May 11, 2018 at 5:17 PM, Ivan Rakov wrote: > Igniters, > > API method for disabling WAL in IgniteCluster accepts only one cache name. >

[jira] [Created] (IGNITE-8471) Apache ignite for .NET has security vulnerabilities

Harendra Rai created IGNITE-8471: Summary: Apache ignite for .NET has security vulnerabilities Key: IGNITE-8471 URL: https://issues.apache.org/jira/browse/IGNITE-8471 Project: Ignite Issue

async operation is not fair async

Hi Igniters, I have a question. Why our async operation in not really async? GridCacheAdapter.syncOp has awaitLastFut(); this call wait last async operation completed. This means all async operation in one thread will be executed one by one but not in parallel. Async operation is not async.

[jira] [Created] (IGNITE-8472) Apache ignite for .NET has security vulnerabilities

Harendra Rai created IGNITE-8472: Summary: Apache ignite for .NET has security vulnerabilities Key: IGNITE-8472 URL: https://issues.apache.org/jira/browse/IGNITE-8472 Project: Ignite Issue

Re: async operation is not fair async

Dmitriy S, If it will be in the internal package, and only for internal usage, are you agree with changes? пт, 11 мая 2018 г., 21:12 Dmitriy Setrakyan : > On Fri, May 11, 2018 at 6:49 PM, Dmitriy Govorukhin < > dmitriy.govoruk...@gmail.com> wrote: > > > Dmitriy S, > > > >

Re: async operation is not fair async

On Fri, May 11, 2018 at 7:46 PM, Dmitriy Govorukhin < dmitriy.govoruk...@gmail.com> wrote: > I will edit IGNITE-8475, and remove all part that belong to the public api. > Is it acceptable for you? > Everything is acceptable, as long as the public API is safe :)

Re: async operation is not fair async

Dmitriy S, It is not broke existing code, because for use this ability you must use decorator "withFairSycn()". What about the argument of Vladimir? On Fri, May 11, 2018 at 8:41 PM, Dmitriy Setrakyan wrote: > On Fri, May 11, 2018 at 6:38 PM, Dmitriy Govorukhin < >

Ignite v2.6 release dates

Igniters, Is the schedule for v2.6 finalized already? If I want a feature/component I'm working on to get into the release, when should it be (code/feature) frozen? Thanks. p.

Re: async operation is not fair async

On Fri, May 11, 2018 at 6:49 PM, Dmitriy Govorukhin < dmitriy.govoruk...@gmail.com> wrote: > Dmitriy S, > > It is not broke existing code, because for use this ability you must use > decorator "withFairSycn()". > > What about the argument of Vladimir? > Here is Vladimir's quote: *This would

Re: Ignite v2.6 release dates

Pavel, The scope has not been discussed or defined for 2.6 yet. Usually, we do this right after releasing a version that is in progress. As a rule of thumb, Ignite is released once in 3 months. So, if Ignite 2.5 is released in May, then 2.6 will be projected towards the end of August. -- Denis

Re: Ignite v2.6 release dates

Right, it depends on the community. I'm just sharing how the process works in general. -- Denis On Fri, May 11, 2018 at 11:27 AM, Dmitry Pavlov wrote: > Hi Pavel, > > Denis, please correct me if I'm wrong, > > Recently we have removed baseline topology usability fixes

[GitHub] ignite pull request #3985: IGNITE-8320 Corrupted indexes fix

GitHub user Jokser opened a pull request: https://github.com/apache/ignite/pull/3985 IGNITE-8320 Corrupted indexes fix You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8320-reproduce Alternatively

[GitHub] ignite pull request #3986: IGNITE-8469: release memory in case initializatio...

GitHub user Mmuzaf opened a pull request: https://github.com/apache/ignite/pull/3986 IGNITE-8469: release memory in case initialization multi times You can merge this pull request into a Git repository by running: $ git pull https://github.com/Mmuzaf/ignite ignite-8469

Re: async operation is not fair async

On Fri, May 11, 2018 at 7:23 PM, Dmitriy Govorukhin < dmitriy.govoruk...@gmail.com> wrote: > Dmitriy S, > > If it will be in the internal package, and only for internal usage, are you > agree with changes? > Yes, but please be careful not to create deadlocks for ourselves. Can you please close

Re: NodeJS thin client: full API

Hi Igor, all types from the protocol v.2.4 are supported for both read and write. See [1] for the mappings and explanation. The idea is to minimize additional non-standard and/or 3rd-party JavaScript Objects for that. Timestamp and Enum require additional classes - no better options were

[GitHub] ignite pull request #3983: IGNITE-7999: for 2.4

GitHub user tledkov-gridgain opened a pull request: https://github.com/apache/ignite/pull/3983 IGNITE-7999: for 2.4 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-7999-2.4-next Alternatively you

Re: async operation is not fair async

Igniters, I created the issue. IGNITE-8475 Any comments are welcome. On Fri, May 11, 2018 at 6:32 PM, Ivan Rakov wrote: > Agree. "fair" is more descriptive. > > Best Regards, > Ivan Rakov > > > On 11.05.2018 18:30,

Re: async operation is not fair async

Guys, I am not sure I like this approach, especially for this code: f1=cache.getAsync(key1); f2=cache.getAsync(key2); You cannot complete f2 before f1. If you do, the code is unusable and it is impossible to predict anything. If you need to get 2 elements asynchronously, use getAllAsync()

Re: async operation is not fair async

On Fri, May 11, 2018 at 6:38 PM, Dmitriy Govorukhin < dmitriy.govoruk...@gmail.com> wrote: > Dmitriy S, > > Why method named as "async" but does not work as async? This is misleading. > > getAllAsync() is a special case. Not always you can use getAllAsync() > instead > of multiple getAsync(). >

Re: async operation is not fair async

IMO you can complete async operations one before another if these operations are related to independent data. It is strange why Ignite users are not confused by current API. So I support Dmitriy's G. suggestion. пт, 11 мая 2018 г. в 20:24, Dmitriy Setrakyan : > Guys, > >

[GitHub] ignite pull request #3984: IGNITE-8471 Dependencies upgraded

GitHub user agura opened a pull request: https://github.com/apache/ignite/pull/3984 IGNITE-8471 Dependencies upgraded You can merge this pull request into a Git repository by running: $ git pull https://github.com/agura/incubator-ignite ignite-8471 Alternatively you can

Re: NodeJS thin client: full API

Alexey, I've checked out the code. Looks good to me. Great job! What about data types support? I can see Timestamp. Are you planning to implement other types, e.g. Decimal, Guid? Best Regards, Igor On Fri, May 11, 2018 at 11:43 AM, Dmitriy Setrakyan wrote: > On Fri,

[jira] [Created] (IGNITE-8475) Create new IgniteCache decorator with fair async methonds

Dmitriy Govorukhin created IGNITE-8475: -- Summary: Create new IgniteCache decorator with fair async methonds Key: IGNITE-8475 URL: https://issues.apache.org/jira/browse/IGNITE-8475 Project: Ignite

Re: async operation is not fair async

Dmitriy S, Why method named as "async" but does not work as async? This is misleading. getAllAsync() is a special case. Not always you can use getAllAsync() instead of multiple getAsync(). In this topic, I wanna discuss problem not only for the GET operation but also all async operation behavior

Re: async operation is not fair async

On Fri, May 11, 2018 at 6:29 PM, Dmitry Pavlov wrote: > IMO you can complete async operations one before another if these > operations are related to independent data. > > It is strange why Ignite users are not confused by current API. So I > support Dmitriy's G.

Re: NodeJS thin client: full API

Alexey, Amazing progress and the overall state of the contribution! I'll try to install and play with the client in the nearest days. As for now, please consider the following suggestions. Please do the following changes: - Let's rename SqlDataProcessingExample.js to just SqlExample.js and

Re: NodeJS thin client: full API

Denis, > As for the docs, are you ready to bring them to readme.io? Just let me know > and I'll be happy to arrange an account for you and discuss the structure. I remember some discussion regarding moving the docs from readme.io to GitHub pages in 2.6. No? In any case, in my opinion, a

Re: async operation is not fair async

Guys, To build a great product we should be open minded and look to the future, not to the past. Dima raised very valid point - why async is not async? Current programming culture and demanding performance requirements pushes users towards reactive-style programming. I do not want my thread to

Re: async operation is not fair async

Vladimir, In general I agree, but I do get greatly *close-minded* (pun intended) whenever users' code that worked for the past several years all of a sudden gets deadlocked after an upgrade. Making this feature optional is even worse and more confusing. In this case the best action is no action