Re: Batch service deployment

hould > always return the future. However, the IgniteFuture.get(...) method does > throw an exception, and in this exception you should provide the info about > the failures. > > D. > > On Tue, Aug 15, 2017 at 1:31 AM, Denis Mekhanikov <dmekhani...@gmail.com> > wrote: > > > Dmitr

Re: Batch service deployment

. > > On Mon, Aug 14, 2017 at 2:22 AM, Denis Mekhanikov <dmekhani...@gmail.com> > wrote: > > > Hi Igniters! > > > > Currently Ignite doesn't have support for batch service deployment, but > it > > may be a very useful feature in case of a big number of n

Batch service deployment

, but no interface changes are needed there. Ticket: https://issues.apache.org/jira/browse/IGNITE-5145 -- Cheers, Denis Mekhanikov

Re: Batch service deployment

ge this behavior and start tracking failures during deployment and initialization on the server, then we could automatically cancel services that are already deployed in a batch. чт, 17 авг. 2017 г. в 8:34, Dmitriy Setrakyan <d...@gridgain.com>: > On Wed, Aug 16, 2017 at 8:17 AM, D

Hello

Hi everyone! My name is Denis, I'm from Saint Petersburg. I'd like to contribute to Apache Ignite project. I hope, you'll find my work useful. -- Best regards, Denis Mekhanikov

Re: Hello

forward to your contributions! > > Sincerely, > Dmitry Pavlov > > вт, 25 июл. 2017 г. в 14:21, Denis Mekhanikov <dmekhani...@gmail.com>: > > > Hi everyone! > > > > My name is Denis, I'm from Saint Petersburg. > > I'd like to contribute to Apache Ignit

Re: Expiry policy for Cache.invoke

istent, but you will not find > > anything about transactions in JCache. To my knowledge, JCache does not > > have transactions. > > > > I would file a ticket about the issue you found, so the community could > > address it. If you are interested, perhaps you can contribute a

Re: Expiry policy for Cache.invoke

/EntryProcessor.html I think, that if the value is loaded from CacheStore, then getExpiryForCreation() should be used. Other methods should be called depending on operations performed. Denis чт, 14 сент. 2017 г. в 12:02, Denis Mekhanikov <dmekhani...@gmail.com>: > Val, > > Sorry,

Re: Expiry policy for Cache.invoke

on cache mode. > > -Val > > On Thu, Sep 14, 2017 at 3:02 AM, Denis Mekhanikov <dmekhani...@gmail.com> > wrote: > > > Dmitriy, > > > > You are right about transactions, but the spec describes invoke, so, if > it > > specifies some behavior in general, then

Re: NPE from service processor

I can only say that recent changes introduced by IGNITE-5145 in GridServiceProcessor shouldn't have changed this behavior in any way. It must be somehow connected with a lifecycle of IgniteKernal and other components. A reproducing example would

Expiry policy for Cache.invoke

Igniters! I noticed a weird behavior regarding expiry policy in Ignite. You can find an example in the attachment. When you call invoke on a cache with configured CacheStore and ExpiryPolicy, then chosen expiry depends on cache's atomicity mode. If cache is atomic, then "creation" expiry timeout

Re: Service versioning

Guys, Let me remind you that services still don't support peer class loading: https://issues.apache.org/jira/browse/IGNITE-975 I think, it should be fixed as well, because versioning is pretty useless without ability to change implementation without downtime. Also I've seen a lot of questions

Re: DataStreamer usability

Here is another little example of non-obvious DataStreamer-related API: https://stackoverflow.com/questions/46045987/unknown-pair-exception-when-using-streamtransformer-for-binaryobject/46051447?noredirect=1#comment79063618_46051447 I think, passing new value as the first element of Object array

Re: Use @ServiceResource with property placeholder

Hi Krzysztof! We don't have this capability right now. You can only specify name of a service in this annotation. You are able to use properties in XML config, because it is processed by Spring. But the code, that performs service injection, doesn't know anything about Spring. Ignite uses its own

Re: Conflicting cross-version suffixes in: org.scalatest:scalatest, com.twitter:chill, org.apache.spark:spark-unsafe, org.apache.spark:spark-tags

Igniters, I noticed a problem in POM files of *ignite-spark* and *ignite-spark_2.10* modules. *ignite-spark* is targeted to be used by Scala 2.11, while *ignite-spark_2.10* is made for Scala 2.10. *But, **ignite-spark* has *spark-unsafe_2.10* as a dependency, and *ignite-spark_2.10* depends on

Re: Service grid redesign

adur <daradu...@gmail.com>: > Hi, Denis M., > > I'd like to pick up a ticket from IEP-17 next week. > > Could you please advise a ticket to start? > > On Tue, Apr 24, 2018 at 11:47 AM, Dmitriy Setrakyan > <dsetrak...@apache.org> wrote: > > On Tue, Apr 24,

Re: Problems with unlocking multiply held cache locks.

Cross-posting to developers list. Guys, cache locks work inconsistently: if you take a lock twice, but release it only once, then *IgniteCache#isLocalLocked* will tell you, that you hold a lock, but another node will be able to acquire it. We should either make the lock non-reentrant, or not

Re: Irrelevant data in discovery messages

ge. It would > be enough to include it only into Join requests and not regular heartbeats. > I hope that it is already happening this way. Can you please confirm? > > D. > > On Wed, Jan 10, 2018 at 12:30 AM, Denis Mekhanikov <dmekhani...@gmail.com> > wrote: > >

Re: Connection problem between client and server

Jeff, Your have indeed a lot of data sent over discovery. Almost all of it is taken by node attributes. Try reducing Java classpath and PATH environment variable. Also increasing of TCP window could help, because now a lot of small messages are sent instead of a few big ones. Cross-sending it to

Re: Irrelevant data in discovery messages

Thanks, Yakov! Maybe we should change the default behaviour? Any environment contains *PATH* and *java.class.path* variables at least, and they are not used by anybody. I don't think we should include them to node attributes by default. Denis пн, 15 янв. 2018 г. в 13:02, Yakov Zhdanov

Re: Irrelevant data in discovery messages

At least *java.net.preferIPv4Stack* parameter shouldn't be ignored. We check, that nodes have the same value of this parameter, and print a warning otherwise. It is pretty helpful sometimes. Maybe, some other parameters are also used internally. They should be added to node attributes regardless

Irrelevant data in discovery messages

Igniters, Turns out, that we are sending a lot of irrelevant information in discovery messages. Some messages contain *TcpDiscoveryNode* objects, which in turn have such attributes like *PATH, java.class.path, sun.boot.class.path, java.library.path, org.apache.ignite.jvm.args, *etc. Some of these

Re: Batch size parameter at DataStreamerCacheUpdaters.batched()

Guys, I think, it makes sense to move this receiver implementation to public API. It has much better performance, than the default one, that performs single puts. I don't see any point in adding a batch size parameter to it though, since DataStreamer already has such setting itself. Denis пт,

Re: Service grid redesign

> guarantee. > > ср, 25 июл. 2018 г. в 21:58, Vyacheslav Daradur : > > > Denis, long service initialization isn't a big problem for us. > > > > The problem is hung initialization, that means the service deployment > > will never complete. > > On Wed, Jul 25, 2

Local Continuous Query

Igniters, As you may know, *ContinuousQuery * class extends the *Query *class, so *setLocal *method is

IP finder in tests

Igniters, Almost every test in Ignite project has the following pattern: shared *TcpDiscoveryVmIpFinder *is defined as a field of a test class, which is then used in discovery configuration in *getConfiguration(...)* method. There are more than 700 test classes with this setup. But for some

Re: IP finder in tests

Yakov, Almost every test in the project uses the Vm IP finder anyway. It has become a convention to use it in all tests. So, I'm trying to reduce the amount of copy-pasted code and improve test's isolation. Also tests may be run outside TeamCity during development process. Multicast Ip Finder

Backup queue for local continuous query

Igniters, I noticed, that local continuous queries store queues with backup entries. And since the queries are local, other nodes never send acknowledges. It has two negative effects: 1) Backup queue may grow indefinitely and cause OOME. 2) When topology changes, the backup queue is flushed, and

Re: Service grid redesign

I don't think, that we really need this feature. It seems to me, that if you want to use a different implementation of a service, you can assign a different name to it. What do you think? Denis чт, 9 авг. 2018 г. в 16:32, Dmitriy Setrakyan : > On Thu, Aug 9, 2018 at 4:41 AM, Vyacheslav Daradur

Re: Service grid redesign

services API versioning which is being used > widely t in SOAP/REST microservices infrastructure. > > In my opinion, it is about services with the same name and the same > full class name, but different classes versions for example in > different classloaders. > > > On

Re: Backup queue for local continuous query

expect local query shouldn't involve remote nodes at all. > Also, I'm not sure we should filter out backup events. Can we let users to > do this in their listener code as it shouldn't costs for local CQ? > > > > > > On Thu, Aug 2, 2018 at 3:35 PM Denis Mekhanikov >

Bots on dev list

Igniters, We have a lot of threads, created by bots on the dev list. Currently messages are sent by JIRA, GitHub and MTCGA bots. Maybe, some others too, but these are the most active. Take a look at this page:

Re: Service grid redesign

Pavel, could you assist? Does it make sense for .Net to specify service class name instead of its implementation? I think, it shouldn't be a problem. Denis On Sat, Aug 18, 2018, 11:33 Vyacheslav Daradur wrote: > I think that the replacement of serialized instance makes sense to me > for Java

Re: Bots on dev list

generated messages, would help here. Denis ср, 29 авг. 2018 г. в 12:26, Dmitrii Ryabov : > Modern mail services allow users to filter messages. You can easily filter > out bot messages. > > 2018-08-29 11:48 GMT+03:00 Denis Mekhanikov : > > > Igniters, > > > >

Re: Service grid redesign

I don't think, that client nodes, that host services make much sense. May we forbid it? Does anybody know, when it may be useful? Vyacheslav, does it complicate the implementation somehow? Denis вт, 24 июл. 2018 г. в 11:57, Vyacheslav Daradur : > Hi, Igniters! > > I am close to completing the

Re: Service grid redesign

ed services on data free nodes with access to IgniteCaches on > remote nodes in the same cluster. > > > > > On Tue, Jul 24, 2018 at 12:10 PM Denis Mekhanikov > wrote: > > > > I don't think, that client nodes, that host services make much sense. >

Re: Service grid redesign

; > > > > wrote: > > > > > > > > > > Got it. > > > > > > > > > > Yes, we will preserve this behavior. > > > > > > > > > > Thanks! > > > > > On Tue, Jul 24, 2018 at 2:20 PM Dmitriy Setrakyan < > dsetrak

Re: Bots on dev list

ble for the dev list > communication? Personally, I am subscribed to the dev list and use filters > in my email client. > > D. > > On Wed, Aug 29, 2018 at 3:40 AM, Denis Mekhanikov > wrote: > > > Guys, > > > > Yep, I use filters on my mail account. But the portal i

Re: IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpi timeouts

Absolutely agree. Personally I find it particularly frustrating, that *IgniteConfiguration.networkTimeout* and TcpDiscoverySpi.networkTime*out *are not the same thing. If we had a small set of timeouts with simple and clear semantics, it would make everybody happier. Denis вт, 6 мар. 2018 г. в

Re: Service grid redesign

this behaviour. I'm not sure, if anybody relies on this functionality right now. Should we support it at all? If yes, should we make it configurable? Denis пн, 9 апр. 2018 г. в 19:27, Denis Mekhanikov <dmekhani...@gmail.com>: > Val, > > Sounds reasonable. I just think, that user shoul

Re: Service grid redesign

Val, Sounds reasonable. I just think, that user should have some way to know, that new version of a service class was deployed. One way to do it is to listen to *EVT_CLASS_DEPLOYED. *I'm not sure, whether it is triggered on class redeployment, though. If not, then another event type should be

Re: Service grid redesign

component and I'd like to take part in the > development. > > > > On Mon, Apr 2, 2018 at 2:55 PM, Denis Mekhanikov <dmekhani...@gmail.com> > wrote: > > Vyacheslav, > > > > Service deployment design, based on replicated utility cache has proven > to

Re: Service grid redesign

rect link: > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP- > > > 17%3A+Oil+Change+in+Service+Grid > > > > > > I have looked at the tickets there, and I believe that we should not > > > support peer-deployment for services. It is very hard and I do n

Re: Service grid redesign

г. в 11:28, Denis Mekhanikov <dmekhani...@gmail.com>: > Denis, > > Sounds reasonable. It's not clear, though, what should happen, if a > joining node has some services persisted, that are missing on other nodes. > Should we deploy them? > If we do so, it could lead

Re: Service grid redesign

.@apache.org> > wrote: > > > > > > > Denis, > > > > > > > > I would encourage us to persist a service configuration in the meta > > store > > > > and have this capability enabled by default. That's essential for > > > servi

Re: Service grid redesign

t lower levels (meta store, discovery, > >> etc.). > >> > >> Also, I heard that presently we store a service configuration in the > >> system > >> cache that doesn't give us a way to deploy a new version of a service > >> without undeployment o

Re: Service grid redesign

ver the time requiring to update the > > > class on all the nodes (if, for instance, someone wants to deploy the > > next > > > version of a service)? Just want to be sure we don't need to restart > the > > > cluster nodes (that won't be used for

Re: Service grid redesign

essage to > the > > logs and, probably, generate a system event the user can be subscribed > to. > > > > Regardless, of the service initialization time, I think we still need to > > utilize discovery SPI to avoid problems discussed later. > > > > Val, others, what do you think

Re: Service grid redesign

Denis > > On Fri, Apr 13, 2018 at 5:30 AM, Denis Mekhanikov <dmekhani...@gmail.com> > wrote: > > > Vladimir, > > > > Currently we don't save binary metadata to disk, when persistence is > > disabled. > > But we still persist marshaller mappings for so

Re: Service grid redesign

ke unnecessary complication. > > -Val > > On Tue, Apr 17, 2018 at 1:00 AM, Denis Mekhanikov <dmekhani...@gmail.com> > wrote: > > > Val, > > > > Service initialisation is not going to happen in the discovery thread. > > It should be done asynchronous

Re: Service grid redesign

enis, > > > > > > > > > On the other hand, if exception is thrown from the *execute() > > *method, > > > > then service won't be undeployed. > > > > > > > > This is actually weird... What is going to happen in this case a

Re: [jira] [Created] (IGNITE-8279) Clients can't operate on services after deactivation

rely, > Dmitriy Pavlov > > пн, 16 апр. 2018 г. в 21:52, Raymond Wilson <raymond_wil...@trimble.com>: > > > Hi Denis, > > > > Would this be better to target 2.5? It seems like a significant > > regression... > > > > Thanks, > > Raymond

Re: Service grid redesign

lt;daradu...@gmail.com>: > Hi, Denis Mekhanikov! > > As far as I know, Ignite services are based on IgniteCache and we have > all its features. We can use listeners or continuous queries for > deployment synchronizations. > > Why do you want using the discovery layer for tha

Service grid redesign

Igniters, I'd like to start a discussion on Ignite service grid redesign. We have a number of problems in our current architecture, that have to be addressed. Here are the most severe ones: One of them is lack of guarantee, that service is successfully deployed and ready for work by the time,

Continuous query deployment

Igniters, I'm concerned with our continuous query API and deployment procedure. Continuous queries have remote filters, that can be deployed over peer class loading mechanism (this functionality is currently broken though: IGNITE-3653 ,

Re: Continuous query deployment

> > > Is it possible to simply disable P2P class loading for remote filter of > > continuous queries with autoUnsubscribe = true? > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > чт, 18 окт. 2018 г. в 18:31, Denis Mekhanikov : > >

Re: Abbreviation code-style requirement.

+1 I'm for long and descriptive names over short and counterintuitive. I think, abbreviations shouldn't be mandatory, as they often obscure the meaning of used names. One-letter abbreviations should be removed from the list at all. When I see a variable *c*, I can't tell, whether it's a char,

Re: Continuous query deployment

on initial query execution, but not for the new > nodes that join after it's already deployed. > > If that's the case, we should just find a right way of dynamic class > loading that always works. Deployment SPI seems to be a good candidate, > just like for services. > > -Val > > On

Re: Brainstorm: Make TC Run All faster

Dmitry, Sergey, There is a common pattern in the test codebase, when each test starts its own set of nodes, and closes them after the test finishes. Node startup takes quite a lot of time, and this time could be reduced, if tests shared the same set of nodes. I mean, if there is a test class with

Re: Time to remove automated messages from the devlist?

nable to fight with JIRA messages it is reasonable to > grow a culture of on-list development. If we don't have it, JIRA should > remain here. > > чт, 15 нояб. 2018 г. в 18:30, Denis Mekhanikov : > > > Dmitriy, > > > > If we want people to act openly an

Re: Time to remove automated messages from the devlist?

t. > > If we came to practice that all contributors announce important features > and bugs, JIRA can be removed. Now it can't. > > Which problem we can solve by removing JIRA from the list? > > Sincerely, > Dmitriy Pavlov > > чт, 15 нояб. 2018 г. в 17:34, Denis Me

Re: Time to remove automated messages from the devlist?

Guys, I vote for moving automatically generated messages to a separate mailing list (maybe except most important ones). I already wrote about it here: http://apache-ignite-developers.2346864.n4.nabble.com/Bots-on-dev-list-td34406.html What we have now makes the Nabble portal an absolute mess

Re: Service grid redesign

This should help during a review. Should I post the document > into > > > > > > > > wiki > > > > > > or > > > > > > > > IEP? > > > > > > > > > > > > > > > > I'd like to ask Ignite'

Re: [Result][VOTE] Creation dedicated list for github notifiacations

Great news! Is it possible to move all GitHub messages from the archive of the developers list to the newly-created one? Denis вт, 11 дек. 2018 г. в 10:05, Dmitriy Pavlov : > Hi Igniters, > > Infra changed notifications, so now GitHub emails are being sent to > notifications@ > > Web UI:

Re: Continuous queries and duplicates

Guys, FYI: Partition counters are already a part of the public API. The following method reveals this information: CacheQueryEntryEvent#getPartitionUpdateCounter()

Re: Service grid redesign

ymentResult* Let's do this as the final step of the code review to avoid repeated renaming. Denis чт, 6 дек. 2018 г. в 15:21, Denis Mekhanikov : > Alexey, > > I don't see any problem in letting services work on a deactivated cluster. > All services need is discovery messages and c

Re: Use of marshaller at node startup routine (need advice)

Slava, Interface *Service *extends *Serializable.* So, all services are supposed to be serializable by the JdkMarshaller. Usage of *BinaryMarshaller* or *OptimizedMarshaller* makes sense only from performance point of view. But I don't think, that we should try too hard to minimize the

Re: [DISCUSSION] Performance issue with cluster-wide cache metrics distribution

Alex, Did you measure the impact of metrics collection? What is the overhead you are trying to avoid? Just to make it clear, MetricUpdateMessage-s are used as heartbeats. So they are sent anyways, even if no metrics are distributed between nodes. Denis вт, 4 дек. 2018 г. в 12:46, Alex Plehanov

Re: Set 'TcpDiscoveryVmIpFinder' as default IP finder for tests instead of 'TcpDiscoveryMulticastIpFinder'

Slava, These are exactly my thoughts, so I fully support you here. I already wrote about it: http://apache-ignite-developers.2346864.n4.nabble.com/IP-finder-in-tests-td33322.html But I kind of abandoned this activity. Feel free to take over it. Denis ср, 5 дек. 2018 г. в 17:22, Vladimir Ozerov

Re: Set 'TcpDiscoveryVmIpFinder' as default IP finder for tests instead of 'TcpDiscoveryMulticastIpFinder'

for similar issue in 'examples' module. > > Seems, there are some issues with Platforms module integration. > > Slava, do you think Platforms tests can be fixed as well or one more > ticket > > should be created? > > > > [1] https://issues.apache.org/jira/browse/IG

Re: Service grid redesign

Alexey, I don't see any problem in letting services work on a deactivated cluster. All services need is discovery messages and compute tasks. Both of these features are available at all times. But it should be configurable. Services may need caches for their work, so it's better to undeploy such

Re: [IMPORTANT] Future of Binary Objects

sses, implementa field extraction logic, etc.) - then just implement > that interface. They key is that this implementation will only be needed in > Java, not in a dozen of platform we support. > > But when it comes to how to store object in a cache > > On Wed, Nov 21, 2018 at

Re: Service grid redesign

hich are somewhat > similar > > in > > > internal flow. > > > > > > On Wed, Nov 21, 2018 at 10:49 AM Nikolay Izhikov > > > wrote: > > > > > > > Hello, Vladimir. > > > > > > > > What is correct term? > > > &

Re: TcpCommunicationSpi extension to ignore docker bridge network

David, This is a problem, that many people encounter. And I think, it's about time to deal with it. We have the following method, that collects all local addresses, that will be sent with node attributes: *IgniteUtils#resolveLocalAddresses()*. And it iterates over all local interfaces, that the

Re: [IMPORTANT] Future of Binary Objects

People often ask about possibility to store their data in that format, that they use in their applications. If you use Avro everywhere in your application, then why not store data in the same format in Ignite? So, how about making an interface, that would enlist all operations we need, and use

Re: [VOTE] Creation dedicated list for github notifiacations

+1 I'm for making the dev list readable without filters of any kind. On Tue, Nov 27, 2018, 15:14 Maxim Muzafarov +1 > > Let's have a look at how it will be. > > On Tue, 27 Nov 2018 at 14:48 Seliverstov Igor > wrote: > > > +1 > > > > вт, 27 нояб. 2018 г. в 14:45, Юрий : > > > > > +1 > > > > > >

Re: New API for changing configuration of persistent caches

Guys, I like the idea with the configuration builder more. We could limit the set of properties by providing only modifiable ones in the builder interface. Otherwise only runtime will show whether you tried to modify a proper setting. And if we decide to make another property modifiable, then we

Re: proposed realization KILL QUERY command

Actually, option with separate parameters was mentioned in another thread http://apache-ignite-developers.2346864.n4.nabble.com/proposed-design-for-thin-client-SQL-management-and-monitoring-view-running-queries-and-kill-it-tp37713p38056.html Denis чт, 22 нояб. 2018 г. в 08:51, Vladimir Ozerov :

Re: How to deprecate unused Ignite's system property properly? (IGNITE-7441 Drop IGNITE_SERVICES_COMPATIBILITY_MODE system property)

Vyacheslav, You are right. This property is not used anywhere, so you can safely remove it. I don't think, there is any need in deprecation. You can just go ahead and drop it, since it doesn't have any effect. Denis чт, 22 нояб. 2018 г. в 15:47, Vyacheslav Daradur : > Hi, Igniters! > > Here is

Re: Time to remove automated messages from the devlist?

> > > > > > > > > > > > > > > > > > > > > > > Personal emails for _watched_ JIRA tickets are very > > > > useful. > > > > > > > > > > > > > Em

Re: proposed design for thin client SQL management and monitoring (view running queries and kill it)

Guys, Syntax like *KILL QUERY '25.1234'* look a bit cryptic to me. I'm going to look up in documentation, which parameter goes first in this query every time I use it. I like the syntax, that Igor suggested more. Will it be better if we make *nodeId* and *queryId *named properties? Something

Re: Service grid redesign

contact me directly in case of questions. > Thanks! > > > > On Sun, Nov 11, 2018 at 10:09 PM Denis Mekhanikov > wrote: > > > > > > Guys, > > > > > > I'd like to take a look at the changes before they are merged. > > > I'll do my best

Re: Time to remove automated messages from the devlist?

ifications@ for this. > > > >> > > > > >> > So only one option to proceed here is to run a formal vote on list > > > >> creation > > > >> > and redirection of github/gitbox messages to a new list. > > > >> > > > >

High priority TCP discovery messages

A bit of background: When TcpDiscoverySpi is used, TcpDiscoveryMetricsUpdateMessage is sent by a coordinator once in metricsUpdateFrequency, which is 2 seconds by default. It serves as a ping message, which ensures, that the ring is connected, and all nodes are alive. These messages have a high

Re: High priority TCP discovery messages

Yakov, Sounds good. But there is a flaw in the procedure, that you described. If we have a TcpDiscoveryMetricsUpdateMessage in a queue, and a newer one arrives, then we will consider the existing one obsolete and won't process it. The newest metrics update message will be moved to the queue's

Re: High priority TCP discovery messages

I like the idea to make all messages be processed with equal priority. It will make nodes with overgrown discovery message queues die more often, though. But maybe, this is how it's supposed to work. Denis пт, 11 янв. 2019 г. в 16:26, Denis Mekhanikov : > Yakov, > > So

Re: Service grid redesign

> Agree. Lets's do it. > > > > > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all other > classes> with Services word in them. > > > I think, they would look better if we use a singular word *Service > *instead. > > > Same for *Deployments*. &

Re: Service grid redesign

'Single' means 'single node', maybe we should use one of the following: > > - 'ServicesSingleNodeDeploymentsResults' > > - 'ServicesNodeDeploymentsResults' > > - 'ServicesInstanceDeploymentsResults' > > > > On Wed, Dec 19, 2018 at 4:26 PM Denis Mekhanikov > > wrote: > > > > > &g

Re: UriDeploymentSpi and GAR files

an Ignite version upgrade. What do you think? Denis чт, 21 февр. 2019 г. в 17:48, Denis Mekhanikov : > I created the following tickets: > > https://issues.apache.org/jira/browse/IGNITE-11379 – drop support of GARs > https://issues.apache.org/jira/browse/IGNITE-11380 – support

Re: UriDeploymentSpi and GAR files

1. Support jar files instead of gar. > 2. Write down documentation about XML config format. > 3. Provide some examples. > > Can you crate a tickets for it? > > > ср, 20 февр. 2019 г. в 11:49, Denis Mekhanikov : > > > Denis, > > > > This XML may cont

IgniteServices.serviceProxy and local services

Folks, Currently IgniteServices.serviceProxy(...) [1] method is designed to return a locally deployed service if it's available. The remote services will be considered only if current one doesn't have the needed service locally. This behaviour breaks the load-balancing feature of services. Let's

UriDeploymentSpi and GAR files

Hi! There is a feature in Ignite called DeploymentSpi [1], that allows adding and changing implementation of compute tasks without nodes' downtime. The only usable implementation right now is UriDeploymentSpi [2], which lets you provide classes of compute tasks packaged as an archive of a special

Re: UriDeploymentSpi and GAR files

lain JARs if anybody needs this at all. > > Might still keep meta info support for compatibility. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > вт, 19 февр. 2019 г. в 19:38, Denis Mekhanikov : > > > > > Hi! > > > > >

Re: High priority TCP discovery messages

Yakov, > You can put hard limit and process enqued MetricsUpdate message > if last one of the kind was processed more than metricsUpdFreq millisecs ago. Makes sense. I'll try implementing it. > I would suggest we allow queue overflow for 1 min, but if situation does not go to normal then node >

Services hot redeployment

Igniters, I'd like to start a dedicated thread for discussion of the design of services hot redeployment. The previous service design discussion can be found in the following thread: [1] Currently adding a new service or implementation change of an existing one requires restarting the hosting

Re: Services hot redeployment

; > > Sounds like a good plan. Does it mean that a user will have to > > register a classloader for service's class explicitly in case of using > > the feature? > > > > On Mon, Feb 4, 2019 at 4:38 PM Denis Mekhanikov > wrote: > > > > > > I

Re: Services hot redeployment

methods like redeploy(ServiceConfiguration). 3. Service versioning and packaging. I'd like to focus on the first point. Service grid will become much more usable and mature once we implement it. Denis вт, 5 февр. 2019 г. в 14:06, Denis Mekhanikov : > Vyacheslav, > > I think, w

Re: New Committer: Vyacheslav Daradur

Well done Slava! It was great working with you on the service grid redesign. Looking forward to seeing new commits from you! Denis чт, 11 апр. 2019 г. в 18:27, Denis Magda : > Well deserved, Vyacheslav! Thanks for hardening Service Grid pushing it to > a completely next level! > > - > Denis >

Re: Asynchronous registration of binary metadata

rtial data >> unavailability. >> And may be further index corruption. >> 1. Why your meta takes a substantial size? may be context leaking ? >> 2. Could meta be compressed ? >> >> >>> Среда, 14 августа 2019, 11:22 +03:00 от Alexei Scherbakov >>&

Re: Asynchronous registration of binary metadata

chema, what in this case would be with >> grid operability? >> >>> >>>> 2. Yes, for walmode=FSYNC writes to metastore will be slow. But such >> mode >>>> should not be used if you have more than two nodes in grid because it >> has >>&

  1   2   3   >