Re: Sort nodes in the ring in order to minimize the number of reconnections

>Then, as I understand it, a lot of reconnection in the ring cannot create even temporary but major problems for performance. And in general this optimization will change practically nothing. Or am I missing some things? I am afraid I did not understand this at all. Please elaborate. I did not su

Re: Make async API great again

Vladimir, I commented in https://issues.apache.org/jira/browse/IGNITE-4480 and https://issues.apache.org/jira/browse/IGNITE-4479 and https://issues.apache.org/jira/browse/IGNITE-4476 I agree that current approach for async API is not good at all and needs to be fixed. As far as callback semantics

Re: Sort nodes in the ring in order to minimize the number of reconnections

>> For example, ordering on latency: - nodes on one host = 1 - nodes in one rack-blade = 2 - nodes in one server-rack = 3 - nodes in one physical cluster = 4 - nodes in one subnet = 5 - etc. Maybe it'll be better to use some metrics from ClusterMetrics interface. The algorithm of ordering can be

Re: Interesting statistics for our tests

Agree with Vladimir's suggestions. Great analysis! --Yakov 2016-12-17 11:36 GMT+03:00 Vladimir Ozerov : > Dima, > I do not think we really need more hardware for now. 40 min test will not > run faster if we add more agents. We have a problem with tests quality, not > quantity. > > Rohit, > Yes,

Re: Striped pool configuration

3. if this is cache message and its target partition is determined it goes to particular stripe (put requests, lock requests, etc) If partition is not determined cache message goes to random stripe (update response, prepare request, commit request, etc) - btw this needs to be fixed and we need to

Re: Striped pool configuration

>In my view, we should hide most of such configuration intricacies from users, and select an appropriate thread pool for each task ourselves. Will this be possible? We already do this. We take decision internally on where to route the request. SoE, my answers below. >How did the striped pool sho

Re: Striped pool configuration

>In this case users will not be able to perform synchronous cache operations from compute tasks, right? why? you are still free to do this. --Yakov

Fwd: Striped pool configuration

do you agree with the point that we need to keep pub and sys pool together with striped pool for now? --Yakov

Fwd: Striped pool configuration

Denis, there was no discussion on dev list. Do not worry, Son of the Earth, you are all right :) I thought I would send letter a bit later when I finish the full scope of optimizations I have in plan. Currently, I use striped pool only for cache messages that are targeted to some defined partition

Re: [VOTE] Apche Ignite PMC Chair Election

Denis Magda

[jira] [Created] (IGNITE-4411) Deadlock with striped pool

Yakov Zhdanov created IGNITE-4411: - Summary: Deadlock with striped pool Key: IGNITE-4411 URL: https://issues.apache.org/jira/browse/IGNITE-4411 Project: Ignite Issue Type: Bug

Re: Grid hang on compute

>> Is there any way we can detect this and prevent from happening? Or perhaps >> start rejecting jobs if they can potentially block the system? I dont think it is possible to detect or rejection will help. --Yakov

Re: [VOTE] Apache Ignite 1.8.0 RC1

+1 (binding) --Yakov 2016-12-05 22:22 GMT+07:00 Vladimir Ozerov : > Hello, > > We have uploaded the 1.8.0 release candidate to > *https://dist.apache.org/repos/dist/dev/ignite/1.8.0-rc1/ > * > > Tag name is > 1.8.0-rc1 > > This release in

[jira] [Created] (IGNITE-4393) Need to remove code putting cache operations to sequence

Yakov Zhdanov created IGNITE-4393: - Summary: Need to remove code putting cache operations to sequence Key: IGNITE-4393 URL: https://issues.apache.org/jira/browse/IGNITE-4393 Project: Ignite

Re: Grid hang on compute

Proper solution here is to have communication backpressure per policy - SYSTEM or PUBLIC, but not single point as it is now. I think we can achieve this having two queues per communication session or (which looks a bit easier to implement) to have separate connections. As a workaround you can incr

Re: What branch to use for Apache Ignite 2.0 development?

> Master must be periodically merged to 2.0. Looks simple enough, no? This may not be always possible and may require to re-implement some features. However, I vote for this approach until it causes problems. Once we start to spend more time on merging, master should become 2.0 development branch

Re: Major release 2.0 and compilation

Agree with Vladimir that we should use flexible approach and should avoid any possible harm here, but cleaning out most of deprecations is the way to go, IMO. There are about 90 occurrences of "deprecated" in the project and most of them are not very hard to remove. Moreover, we have, for example,

[jira] [Created] (IGNITE-4375) Ignite should stop on some events and Exception types

Yakov Zhdanov created IGNITE-4375: - Summary: Ignite should stop on some events and Exception types Key: IGNITE-4375 URL: https://issues.apache.org/jira/browse/IGNITE-4375 Project: Ignite

[jira] [Created] (IGNITE-4374) Ignite should validate JVM and OS configuration and output warning in log

Yakov Zhdanov created IGNITE-4374: - Summary: Ignite should validate JVM and OS configuration and output warning in log Key: IGNITE-4374 URL: https://issues.apache.org/jira/browse/IGNITE-4374 Project

Ignite should validate OS and JVM settings

Hello Igniters! I currently see a lot of issues with Ignite deployments where problems are caused with improper JVM or OS setup, e.g. OS user has too small open files limit, Ignite's JVM has very small max direct memory size resulting to OOME in some cases. I suggest to add some validation to Ign

[jira] [Created] (IGNITE-4371) Neat TX finish request processing may fall into sync wait of dht finish response

Yakov Zhdanov created IGNITE-4371: - Summary: Neat TX finish request processing may fall into sync wait of dht finish response Key: IGNITE-4371 URL: https://issues.apache.org/jira/browse/IGNITE-4371

[jira] [Created] (IGNITE-4366) deadlock in continuous queries

Yakov Zhdanov created IGNITE-4366: - Summary: deadlock in continuous queries Key: IGNITE-4366 URL: https://issues.apache.org/jira/browse/IGNITE-4366 Project: Ignite Issue Type: Bug

[jira] [Created] (IGNITE-4365) Data grid in deadlock on stop

Yakov Zhdanov created IGNITE-4365: - Summary: Data grid in deadlock on stop Key: IGNITE-4365 URL: https://issues.apache.org/jira/browse/IGNITE-4365 Project: Ignite Issue Type: Bug

[jira] [Created] (IGNITE-4267) Need to revisit JTA functionality

Yakov Zhdanov created IGNITE-4267: - Summary: Need to revisit JTA functionality Key: IGNITE-4267 URL: https://issues.apache.org/jira/browse/IGNITE-4267 Project: Ignite Issue Type: Task

[jira] [Created] (IGNITE-4266) GridSessionCancelSiblings* tests can be refactored with extraction of single parent

Yakov Zhdanov created IGNITE-4266: - Summary: GridSessionCancelSiblings* tests can be refactored with extraction of single parent Key: IGNITE-4266 URL: https://issues.apache.org/jira/browse/IGNITE-4266

[jira] [Created] (IGNITE-4265) Need to revisit compute grid checkpoints

Yakov Zhdanov created IGNITE-4265: - Summary: Need to revisit compute grid checkpoints Key: IGNITE-4265 URL: https://issues.apache.org/jira/browse/IGNITE-4265 Project: Ignite Issue Type: Task

Re: IgniteCache.loadCache improvement proposal

> > > Why not store the partition ID in the database and query only local > partitions? Whatever approach we design with a DataStreamer will be slower > than this. > Because this can be some generic DB. Imagine the app migrating to IMDG. I am pretty sure that in many cases approach with data stre

Re: IgniteCache.loadCache improvement proposal

> On Wed, Nov 16, 2016 at 11:22 AM, Yakov Zhdanov wrote: > > > Yakov, I agree that such scenario should be avoided. I also think that > > > loadCache(...) method, as it is right now, provides a way to avoid it. > > > > No, it does not. > > > Yes it

Re: IgniteCache.loadCache improvement proposal

> Yakov, I agree that such scenario should be avoided. I also think that > loadCache(...) method, as it is right now, provides a way to avoid it. No, it does not. --Yakov

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

Re: Add new event in putblic API

I would better add onError() to CQ local listener. --Yakov 2016-11-08 10:29 GMT+03:00 Anton Vinogradov : > Vova, > > We just give user 2 additional tips. > We write exception to ExceptionRegistry and send event. > In case user will use some management console he will see big red warning > window

Re: TX savepoints

// Is this allowed? > > tx.commit(); > } > > > 2016-11-07 13:47 GMT+03:00 Sergey Kozlov : > > > Hi, Yakov > > > > I suppose it's very very handy feature. > > My two cents are following: > > - number of savepoints may be more than one per

TX savepoints

Guys, Let's think of implementing savepoints for Ignite transactions. For me, this is not too hard to do. Having "savepoints" seems to be pretty handy. Please consider the following snippet. ignite.transactions.; INSERT INTO table1 VALUES (1); SAVEPOINT my_savepoint; INSERT INTO table1 VALUES (2

meta cache throws exception on sending compute

https://issues.apache.org/jira/browse/IGNITE-4174 Guys, I have filed a new ticket. Sam, can you please take a look and comment? --Yakov

[jira] [Created] (IGNITE-4174) binary meta cache throws exception on sending compute

Yakov Zhdanov created IGNITE-4174: - Summary: binary meta cache throws exception on sending compute Key: IGNITE-4174 URL: https://issues.apache.org/jira/browse/IGNITE-4174 Project: Ignite

Re: Threads got stuck

he > data to be replicated to others. Can that cause such a situation, too? > > On Tue, Oct 25, 2016 at 11:14 AM, Yakov Zhdanov > wrote: > >> Alper, >> >> There can be multiple reasons. >> >> Can you please reproduce the issue one more time, collect an

Re: Threads got stuck

Alper, There can be multiple reasons. Can you please reproduce the issue one more time, collect and share the following with us: 1. collect all the logs from all the nodes - clients and servers 2. take threaddumps of all JVMs (from all nodes) with jstack -l --Yakov 2016-10-25 10:49 GMT+03:00

Re: Create separate thread pool for query execution

> As far as the query thread pool, how many threads should be in it by > default? What happens is the query is run from compute task - will the > execution be shifted from the public to the query thread pool? Pool management should be the same as for other pools. Remote executions should be execu

Re: Improve "direct" serialization

I already tried smth like that when tried to make marshalling parallel. This is how I tried to reapproach it. 1. allocate set of direct buffers per each session (connection). that was 1 large buffer, but sliced with smaller ones over large offheap array. 2. each thread acquires chunk by chunk from

Ignite service for redhat/centos

Hello Igniters! As far as I know many of Ignite deployments run under rhel & centos I think it would be very convenient to include sample service configuration and service installation instructions to our distribution. Here is the link to redhat documentation. https://access.redhat.com/document

Re: Concurrent read-through

I don't think there is a way to fix this other than having some bounded collection of futures finished with "null" result. --Yakov 2016-10-04 23:09 GMT+03:00 Dmitriy Setrakyan : > Hm... sounds like a bug. > > On Tue, Oct 4, 2016 at 1:06 PM, Valentin Kulichenko < > valentin.kuliche...@gmail.com>

[jira] [Created] (IGNITE-3958) Client node should not start rest processor

Yakov Zhdanov created IGNITE-3958: - Summary: Client node should not start rest processor Key: IGNITE-3958 URL: https://issues.apache.org/jira/browse/IGNITE-3958 Project: Ignite Issue Type

Re: about isolated ignite clusters on the same set of machines

This overrides org.apache.ignite.spi.discovery.tcp.ipfinder.multicast.TcpDiscoveryMulticastIpFinder#setMulticastGroup --Yakov 2016-09-20 17:43 GMT+03:00 李玉珏@163 <18624049...@163.com>: > Hi: > > what is the java api? > > 在 16/9/20 22:03, Yakov Zhdanov 写道: > > Hi! &

Re: about isolated ignite clusters on the same set of machines

Hi! When I need to isolate clusters in the same network I pass -DIGNITE_OVERRIDE_MCAST_GRP=x.x.x.x to java process starting node or -J-DIGNITE_OVERRIDE_MCAST_GRP=x.x.x.x as ignite.sh parameter. --Yakov 2016-09-20 16:52 GMT+03:00 李玉珏@163 <18624049...@163.com>: > Guys: > > in our network, we wa

[jira] [Created] (IGNITE-3900) Need to include yardstick-benchmarks to binary release

Yakov Zhdanov created IGNITE-3900: - Summary: Need to include yardstick-benchmarks to binary release Key: IGNITE-3900 URL: https://issues.apache.org/jira/browse/IGNITE-3900 Project: Ignite

[jira] [Created] (IGNITE-3899) Need to automate benchmark running and gathering results

Yakov Zhdanov created IGNITE-3899: - Summary: Need to automate benchmark running and gathering results Key: IGNITE-3899 URL: https://issues.apache.org/jira/browse/IGNITE-3899 Project: Ignite

Re: Simulating network outages

You can shutdown and then restart (after some sleep) network stack on the host. I remember doing that on Fedora several years ago for exactly the same purposes. --Yakov 2016-08-31 15:21 GMT+03:00 Alexey Goncharuk : > Hi, > > As a starting point you can take a look > at org.apache.ignite.spi.di

Re: copyOnRead performance issues

1. Agree. You can use org.apache.ignite.internal.GridPerformanceSuggestions to print this warning. 2. Disagree. For me this brings a lot of confusion. Alex, can you please check that all internal caches used in Ignite internals have this property set to false. --Yakov 2016-08-18 17:24 GMT+03:00

Re: Ignite 2.0 tasks/roadmap

2:41 GMT+03:00 Dmitriy Setrakyan : > On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov wrote: > > > One more point. > > > > I insist on stop using marshaller and meta caches but switch to spreading > > this info via custom discovery events. > > > > Do we hav

Re: Ignite 2.0 tasks/roadmap

One more point. I insist on stop using marshaller and meta caches but switch to spreading this info via custom discovery events. --Yakov 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan : > On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov > wrote: > > > Guys, I think we can a

Re: Multi-cache transactions & persistent store

Igor, you factory should return the same instance for all caches started locally. This way Ignite should call sessionEnd() once. Can you please check? --Yakov 2016-07-30 4:40 GMT+03:00 Igor Rudyak : > Hi guys, > > Playing with Ignite multi-cache transactions(transactions involving > multiple cac

Re: Ignite 2.0 tasks/roadmap

Guys, I think we can also split event notification for user listeners and internal system listeners. I have been seeing a lot of issues caused by some heavy or blocking operations in user-defined listeners. This may block internal component notification (e.g. on discovery event) causing topology ha

[jira] [Created] (IGNITE-3569) Set copyOnRead property to FALSE for marshaller cache

Yakov Zhdanov created IGNITE-3569: - Summary: Set copyOnRead property to FALSE for marshaller cache Key: IGNITE-3569 URL: https://issues.apache.org/jira/browse/IGNITE-3569 Project: Ignite

NullPointerException when stopping IgniteSemaphore

Vladislav, can you please review and merge to master the fix and test case suggested by Krome? Vlad, btw, why don't we init semaphore during construction time? https://issues.apache.org/jira/browse/IGNITE-3515 Thanks! --Yakov

Re: Rework "withAsync" in Apache 2.0

Agree with Alex. Vova, please go on with issues taking Alex's comments into consideration. Thanks! --Yakov 2016-07-21 10:43 GMT+03:00 Alexey Goncharuk : > Big +1 on this in general. > > I would also relax our guarantees on operations submitted from the same > thread. Currently we guarantee that

Re: ReadWriteUpdateLock

t; 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. &

Re: ReadWriteUpdateLock

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

Re: Ignite 2.0 tasks/roadmap

te all fields, thus > transferring lots of zeros without any reason. We should support branching. > 3) Review all messages (especially cache, double-especially - atomic) in > terms of performance. Most probably we will refactor/split some of them. > > 14 июля 2016 г. 12:06 польз

Re: Ignite 2.0 tasks/roadmap

Alex, a lot of excitement for Ignite-2.0 from my side! =) I agree with your points and I will take a close look at them in the nearest future. Here are some suggestions from me. I don't remember if I shared my thoughts on moving to single TCP port per node. So, I filed a new ticket - https://iss

[jira] [Created] (IGNITE-3480) Use single TCP port per node

Yakov Zhdanov created IGNITE-3480: - Summary: Use single TCP port per node Key: IGNITE-3480 URL: https://issues.apache.org/jira/browse/IGNITE-3480 Project: Ignite Issue Type: Improvement

Re: Ignite monitoring

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

Re: Apache Ignite - New Release

null > IGNITE-3468 - Missing Primary Key flag in getColumns() > > > > > > Take care, > Alexandre "Sasha" Boudnik > > call me via Google Voice: > 1(405) BUDNIKA > 1(405) 283-6452 > > > > On Mon, Jul 11, 2016 at 11:46 AM, Yakov Zhdanov > wr

Apache Ignite - New Release

Guys, We have recently found and fixed several issues in the product along with number of smaller fixes and optimizations and I would like to release these changes. Issue list follows (complete change list can be obtained via git log). ignite-3428 Fixed message recovery handling on reconnect igni

Re: ignite-2310

f5daeeddec8a >>>>> >>>>> So, two methods is added affinityRun and affinityCall. There is >>>>> additional >>>>> parameter Collection of extra caches names. >>>>> An affinity job without the extra caches reserves o

Re: ignite-2310

Guys, this does not work in general case. If you provide more than one partition you can end up with a situation when they reside on more than one node. --Yakov 2016-07-06 13:50 GMT+03:00 Vladimir Ozerov : > If we add "partsToLock" to job execute request, then why we allow it only > for "affinit

Re: IP and hosts

Sebastian, can you please provide a pull request or a patch so I can get better understanding of the idea. What IP do you suggest to use? --Yakov 2016-06-07 9:43 GMT-04:00 Sebastien DIAZ : > Actually you have two notions as localaddr and addr. > > The local adress transformed in InetAdress (when

[jira] [Created] (IGNITE-3233) need to optimize injections

Yakov Zhdanov created IGNITE-3233: - Summary: need to optimize injections Key: IGNITE-3233 URL: https://issues.apache.org/jira/browse/IGNITE-3233 Project: Ignite Issue Type: Improvement

[jira] [Created] (IGNITE-3232) Ignite RDD: need to add transformer closure to saveValues and savePairs

Yakov Zhdanov created IGNITE-3232: - Summary: Ignite RDD: need to add transformer closure to saveValues and savePairs Key: IGNITE-3232 URL: https://issues.apache.org/jira/browse/IGNITE-3232 Project

Re: 1.6 version in Jira is not released

Done. --Yakov 2016-05-30 11:41 GMT-04:00 Dmitriy Setrakyan : > Guys, > > Can we release version 1.6 in Jira? Currently I can still assign tickets to > version 1.6, which is not correct. > > D. >

Re: IgniteCache.invoke on ALL keys

Vova, even though it operates on single key we will need to "pin" partition so key does not go to another node. Pavel, you can also send closures to all primary nodes to do local scan query for each partition. This way you will go over each entry. Thanks! -- Yakov Zhdanov, Director R&a

Contributions Merged

Guys, I have reviewed and merged (to master branch) the following contributions IGNITE-1102: IgniteSpringBean should have getConfiguration() method. By Saikat Maitra. IGNITE-1248: Add a method to retrieve Spring application context. By Saikat Maitra. IGNITE-2708 Need to validate that SPIs are sta

ignite-3023 merged

jcfiorenzano, thank you for contributing fix for ignite-3023 Rename keyBackups to Backups for performance advices printed out on a node ( https://issues.apache.org/jira/browse/IGNITE-3023). I merged it to master. Please close the PR. --Yakov

Re: Added documentation for Continuous Mapping, and Cron based scheduling

Prachi, pages look good to me. --Yakov 2016-05-11 3:14 GMT+06:00 Prachi Garg : > Engineers, > > Can someone please review the documentation for - > >- Continuous Mapping - >http://apacheignite.gridgain.org/v1.5/docs/continuous-mapping >- CRON based scheduling - >http://apacheigni

Re: Ignite 1.6 release timelines

ith the outstanding issues, > mainly > > > > ODBC > > > > > > > support and cache concurrent map changes. As far as the > > concurrent > > > > map, > > > > > > we > > > > > > > had a performance drop, and I t

Re: Ignite 1.6 release timelines

I think we are almost done with odbc support and I hope that we can release about mid or second half of May. --Yakov 2016-04-27 11:13 GMT+03:00 sssow : > Hi, > When will you release 1.6? > Thank you, > > > > > -- > View this message in context: > http://apache-ignite-developers.2346864.n4.nabble

Ignite Reentrant Lock

Guys, Vlad Jelisavcic has implemented Ignite reentrant lock ( https://issues.apache.org/jira/browse/IGNITE-642). I have finally reviewed and merged it today. Vlad, thank you for your efforts! I look forward to next contribution from you! I have removed origin/ignite-642 branch. Please close PR an

Re: Semaphore blocking on tryAcquire() while holding a cache-lock

Vlad and All! I have reviewed and merged ignite-642 ( https://issues.apache.org/jira/browse/IGNITE-642 Implement IgniteReentrantLock data structure) to master. I will send separate email to user- and dev-list on this. --Yakov 2016-04-27 13:07 GMT+03:00 Yakov Zhdanov : > Vlad, not

Re: Release Plan

I have updated the page - moved distributed joins to 1.7 and added odbc to 1.6. The thing is that page has been abandoned. Thanks for pointing this out. --Yakov 2016-04-27 2:51 GMT+03:00 Dmitriy Setrakyan : > I think we are running a bit behind. Yakov, can you please update the page? > > On Tue,

Re: Semaphore blocking on tryAcquire() while holding a cache-lock

; Can you please look at my comment in ignite-642 ticket? > >> > >> Thanks! > >> Vladisav > >> > >> On Thu, Apr 14, 2016 at 7:51 PM, Vladisav Jelisavcic < > vladis...@gmail.com > >> > wrote: > >> > >>> Sure, I'll

Contribution - Optimize usage of GridCacheConcurrentMap (IGNITE-2948)

Guys, I have finally reviewed and accepted contribution made by Ilya Lantukh. That was pretty useful change - it removes data duplication (after years of having one!), i.e. earlier we had to store cache entry by reference in 2 maps, now only in 1. It brings up to 20% for memory efficiency (this de

Re: Hi all!

Hi Maxim! I am glad to welcome you! We have added you to contributor list. Please get familiar with https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute and let us know what ticket you want to start with so we can assist. --Yakov 2016-04-25 5:11 GMT+03:00 Afanasiev Maxim : > Hi

Re: Victor Maevskiy. Request for contribution permissions.

Hi Victor! We have added you to contributor list. You can pick up any ticket you like (preferably tagged with 'newbie') and ask for details here. Or you can start with this one - https://issues.apache.org/jira/browse/IGNITE-1192 (provide spring data integration). Thanks! --Yakov 2016-04-23 17:1

Re: API for asynchronous execution.

re close to completing IGNITE-2004 ticket. > > > > As part this ticket was made the following changes on public API > > > > - if callback has @IgniteAsyncCallback annotation then callback > should > > be > > > > run asynchronously > > > > - these callbacks are exe

Re: Semaphore blocking on tryAcquire() while holding a cache-lock

Vlad, please see my changes in ignite-642 and comment in the ticket. Alex, can you please take a look at my latest commit as well and provide comments? --Yakov 2016-04-12 23:47 GMT+03:00 Yakov Zhdanov : > Very good points, Alexey. I will look at this tomorrow and finalize the > c

Re: Introduce generic server configuration.

guration { > ServerConfiguration serverConfiguration; > int maxCursors; // This is ODBC-specific stuff. > } > > ServerConfiguration { > String address; // E.g. "myHost:15000..15004" > } > > Vladimir. > > > On Wed, Apr 13, 2016 at 12:59 PM, Yakov Zh

Re: Introduce generic server configuration.

Vladimir, I like the idea and it should really make things simpler, however, it is not clear to me how to incorporate this bean properly. NIO server is in internal package, but configuration should be under public one. Having this bean on public API of components exposes their internal implementati

Re: Semaphore blocking on tryAcquire() while holding a cache-lock

Very good points, Alexey. I will look at this tomorrow and finalize the changes. --Yakov 2016-04-12 23:41 GMT+03:00 Alexey Goncharuk : > Guys, > > I fixed code style a bit and pushed my changes to the branch. > > Couple of questions: > - I see that some of the Errors caught do not get re-thrown

Re: Semaphore blocking on tryAcquire() while holding a cache-lock

for contributing this! --Yakov 2016-04-11 18:22 GMT+03:00 Yakov Zhdanov : > Vlad, I did not have time today. Will review tomorrow. > > --Yakov > > 2016-04-08 13:51 GMT+03:00 Yakov Zhdanov : > >> Very good news, Vlad! I will take a look over weekend or on Monday. >> >&g

Re: Semaphore blocking on tryAcquire() while holding a cache-lock

Vlad, I did not have time today. Will review tomorrow. --Yakov 2016-04-08 13:51 GMT+03:00 Yakov Zhdanov : > Very good news, Vlad! I will take a look over weekend or on Monday. > > --Yakov > > 2016-04-08 12:58 GMT+03:00 Vladisav Jelisavcic : > >> Yakov, >> >&g

Re: [jira] [Created] (IGNITE-2964) Please delete old releases from mirroring system

I think Anton V can help here. Anton, can you please take a look and remove releases prior to 1.5.final? --Yakov 2016-04-08 15:07 GMT+03:00 Denis Magda : > Igniters, > > Who can handle this? > > -- > Denis > > > > Forwarded Message > Subject:[jira] [Created] (IGNITE-296

Re: Stream API doesn't update cache metrics.

What is your usecase? пятница, 8 апреля 2016 г. пользователь Dmitry Karachentsev написал: > Yes, switching it to 'true' does the magic. > > Thanks! > > On 08.04.2016 13:52, Yakov Zhdanov wrote: > >> Is allowOverwrite set to 'false'? >> >> T

Re: Stream API doesn't update cache metrics.

Is allowOverwrite set to 'false'? Thanks! -- Yakov Zhdanov, Director R&D *GridGain Systems* www.gridgain.com 2016-04-08 10:30 GMT+03:00 Dmitry Karachentsev : > Hi all. > > Adding data to cache via streamer doesn't update cache metrics like > AveragePutTime, Cache

Re: Semaphore blocking on tryAcquire() while holding a cache-lock

n, Mar 27, 2016 at 11:30 AM, Vladisav Jelisavcic > > wrote: > > > Yakov, I've seen your comments, can you please check the jira again? > > > > > > On Wed, Mar 23, 2016 at 4:46 PM, Yakov Zhdanov > > wrote: > > > >> Vlad, can you please ch

Re: CacheStoreBalancingWrapper is not serializable

Store may be non-serializable, but factory should be. Singleton factories serialized along with their instances in my understanding suitable only for tests or pre-configured caches. --Yakov 2016-04-01 10:34 GMT+03:00 endianignite : > Should I make CacheStoreBalancingWrapper serializable, or is t

Re: Default for backups in AtomicConfiguration

ost due to a failed or left node): > *MyStructureName*” > > D. > > On Thu, Mar 31, 2016 at 2:56 AM, Yakov Zhdanov > wrote: > > > How about this one - Failed to find atomic with given name (increase > > AtomicConfiguration.backups > > count if it has bee

Re: Deprecate GridFunc

+1, However, personally I try not to accept new code on reviews relying on F. I don't think we have any usages of mentioned methods on critical paths that may affect performance. So, for now I would ask reviewers to very carefully accept new code using F. --Yakov 2016-04-01 10:41 GMT+03:00 endia

Re: Default for backups in AtomicConfiguration

How about this one - Failed to find atomic with given name (increase AtomicConfiguration.backups count if it has been lost due to node leave) ? --Yakov 2016-03-31 9:50 GMT+03:00 Vladimir Ozerov : > Igniters, > > I noted that in our AtomicConfiguration we have PARTITIONED cache with > backups=0.

Re: Pre-loading entry from a persistent store after it has been evicted/expired/removed+skipStore

Did you try setting javax.cache.configuration.MutableConfiguration#isReadThrough? Or you claiming it is not working? --Yakov 2016-03-31 11:16 GMT+03:00 Denis Magda : > Igniters, > > Let's say that we have the following task. Due to RAM memory constraints > we need to evict entries from a cache.

Re: API for asynchronous execution.

I think this approach works unless user does not initiate number of concurrent cache operations greater than MSG_QUEUE_SIZE. Where msg queue size default is 1024, but still configurable. Thanks! -- Yakov Zhdanov, Director R&D *GridGain Systems* www.gridgain.com 2016-03-30 11:44 GMT+0

Re: API for asynchronous execution.

Vladimir, Communication should stop reading from connection is there are too many unprocessed messages. Sender will be blocked on putting message to queue. --Yakov 2016-03-30 11:11 GMT+03:00 Vladimir Ozerov : > Guys, > > Can you explain how backpressure control is implemented? What if event > a

<    1   2   3   4   5   6   7   8   >