Re: IEP-76 Thin Client Protocol for Ignite 3.0
Igniters, The initial implementation is ready for review. To limit the PR size, I've only implemented insert and get operations. https://issues.apache.org/jira/browse/IGNITE-14970 https://github.com/apache/ignite-3/pull/191 On Wed, Jul 7, 2021 at 1:56 PM Pavel Tupitsyn wrote: > Thanks everyone, I've moved the proposal to Active status. > Working on the implementation. > > On Tue, Jul 6, 2021 at 10:31 PM Valentin Kulichenko < > valentin.kuliche...@gmail.com> wrote: > >> The proposal looks good to me. >> >> -Val >> >> On Tue, Jul 6, 2021 at 2:24 AM Ivan Daschinsky >> wrote: >> >> > I suppose, that general idea is great. Some details are missing, but I >> > suppose during implementation of clients we will add more details and >> > redefine some parts. >> > >> > вт, 6 июл. 2021 г., 09:59 Pavel Tupitsyn : >> > >> > > Ivan, Val, and others - are there any open objections or questions? >> > > Can we accept the proposal? >> > > >> > > On Mon, Jul 5, 2021 at 1:28 PM Pavel Tupitsyn >> > > wrote: >> > > >> > > > Igniters, >> > > > >> > > > I've updated the IEP to support "Live Schema" [1] from IEP-54. >> > > > Some operations now have schemaless variants, where tuples are >> > serialized >> > > > as maps (String -> val). >> > > > >> > > > [1] >> > > > >> > > >> > >> https://cwiki.apache.org/confluence/display/IGNITE/IEP-54%3A+Schema-first+Approach#IEP54:SchemafirstApproach-Dynamicschemaexpansion(Live-schema) >> > > > >> > > > On Thu, Jul 1, 2021 at 8:31 PM Ivan Daschinsky > > >> > > > wrote: >> > > > >> > > >> Val, my understanding about it was exactly the same as yours, but, >> > > again, >> > > >> I >> > > >> heard a different opinion. >> > > >> >> > > >> But nevertheless, binary protocol should not be about objects, >> records >> > > aka >> > > >> tuples are the best varii, simple and powerful. >> > > >> >> > > >> As for me, I want to take part in implementing python and golang >> thin >> > > >> clients for ignite 3, so consider my remarks using this info. I am >> not >> > > >> just >> > > >> a rude critic, >> > > >> I am just interested in consice and universal binary prorocol >> > > >> чт, 1 июл. 2021 г., 20:23 Valentin Kulichenko < >> > > >> valentin.kuliche...@gmail.com >> > > >> >: >> > > >> >> > > >> > Ivan, >> > > >> > >> > > >> > KV view does work over the tuples. Nested objects and arbitrary >> > > >> structures >> > > >> > can be stored as blobs. So if you need a basic KV cache, you can >> > > always >> > > >> > create a table with two blob fields - one for key and one for >> value >> > - >> > > >> and >> > > >> > store anything there. >> > > >> > >> > > >> > -Val >> > > >> > >> > > >> > On Thu, Jul 1, 2021 at 9:55 AM Ivan Daschinsky < >> ivanda...@gmail.com >> > > >> > > >> > wrote: >> > > >> > >> > > >> > > Val, am I right, that kv view over the tuples is just simple >> > mapping >> > > >> from >> > > >> > > POJO to tuple? No collections, no nested objects? I have >> discussed >> > > >> this >> > > >> > in >> > > >> > > private with Igor and Pavel and they told me different info. >> > > >> > > >> > > >> > > чт, 1 июл. 2021 г., 19:43 Valentin Kulichenko < >> > > >> > > valentin.kuliche...@gmail.com >> > > >> > > >: >> > > >> > > >> > > >> > > > Ivan, >> > > >> > > > >> > > >> > > > I was answering your question about the KV API. The API I >> > provided >> > > >> has >> > > >> > > been >> > > >> > > > discussed and agreed upon. One of the goals of the protocol >> is >> > to >> > > >> > > implement >> > > >> > > > this API, so it should give you a clear idea of what we're >> > looking >> > > >> for. >> > > >> > > > >> > > >> > > > Of course, I agree with you that the protocol should be >> simple >> > and >> > > >> > > flexible >> > > >> > > > enough to allow other implementations for different languages >> > and >> > > >> > > > platforms. >> > > >> > > > >> > > >> > > > -Val >> > > >> > > > >> > > >> > > > On Thu, Jul 1, 2021 at 9:38 AM Ivan Daschinsky < >> > > ivanda...@gmail.com >> > > >> > >> > > >> > > > wrote: >> > > >> > > > >> > > >> > > > > Andrey, yep, you are right. This was just a quick idea. As >> for >> > > >> me, I >> > > >> > > just >> > > >> > > > > don't want to repeat the same problem with compactFooter in >> > thin >> > > >> > client >> > > >> > > > api >> > > >> > > > > of ignite 2.x. >> > > >> > > > > >> > > >> > > > > чт, 1 июл. 2021 г., 19:22 Andrey Mashenkov < >> > > >> > andrey.mashen...@gmail.com >> > > >> > > >: >> > > >> > > > > >> > > >> > > > > > > >> > > >> > > > > > > I suppose that we should describe this more verbose and >> > > >> > explicit. I >> > > >> > > > > > > nevertheless suggest to also consider writing values >> this >> > > way: >> > > >> > > > > > > - arr of fields names (if name is missed, corresponding >> > > field >> > > >> is >> > > >> > > nil) >> > > >> > > > > > > - arr of rows (row as array, length equal to fields >> array) >> > > >> > > > > > >> > > >> > > > > > >> > > >> > > > > > Ivan, >> > > >> > > > > > I think GET and PUT operation parameters
Re: [DISCUSS] Confuse default inspections.
+1
20.07.2021, 23:06, "Юрий" :
> I totally agree.
> Let's get rid of them.
>
> вт, 20 июл. 2021 г. в 18:11, Konstantin Orlov :
>
>> + for both
>>
>> --
>> Regards,
>> Konstantin Orlov
>>
>> > On 20 Jul 2021, at 16:32, Pavel Tupitsyn wrote:
>> >
>> > Agree with for both points
>> >
>> > On Tue, Jul 20, 2021 at 3:14 PM Alexander Polovtcev <
>> alexpolovt...@gmail.com>
>> > wrote:
>> >
>> >> this is a very welcome change for me
>> >>
>> >> On Tue, Jul 20, 2021 at 10:13 AM Ivan Pavlukhin
>> >> wrote:
>> >>
>> >>> + for both points.
>> >>>
>> >>> 2021-07-20 9:56 GMT+03:00, Ivan Daschinsky :
>> Hi!
>>
>> Firstly, lets talk about interfaces.
>>
>> 1. First of all, do we have an automatic inspection for it? AFAIK we
>> >>> don't
>> 2. I am for consistency. At least for production code. Nothing worse
>> is
>> when someone mixes both approaches.
>>
>> About a prohibition of curly brackets around one line -- I am strongly
>> against this rule, it should be removed. There were a few bugs that
>> >> this
>> rule caused.
>>
>> вт, 20 июл. 2021 г. в 09:23, Zhenya Stanilovsky
>> >>> > > :
>>
>> >
>> > Igniters, i understand that this is very long and fundamental story.
>> >> but
>> > … still want to rise up this discussion, we have 2 very strange
>> > inspections:
>> > * «public» modifier in interface methods.
>> > * Illegal ‘{}’ for one line statement. — i found it harmful.
>> > I don`t want to link additional discussion about pos. 2 i think that
>> >>> harm
>> > is obvious.
>> > I suggest to get rid of them.
>> >
>> > what do you think ?
>> >
>> >
>> >
>>
>>
>>
>> --
>> Sincerely yours, Ivan Daschinskiy
>>
>> >>>
>> >>>
>> >>> --
>> >>>
>> >>> Best regards,
>> >>> Ivan Pavlukhin
>> >>>
>> >>
>> >>
>> >> --
>> >> With regards,
>> >> Aleksandr Polovtcev
>> >>
>
> --
> Живи с улыбкой! :D
Re: [Discussion] Race on heartbeat update in checkpoint thread
Ilya, Race only affects the future listener (which only updates heartbeat), but not checkpoint listeners, so no other bugs possible caused by this race except wrong heartbeat update. As I've written before, I think it's not a good idea to wait for other threads by the critical thread in the blocking section. If these threads are not monitored we can never detect lack of progress and never trigger the failure handler. Perhaps a good solution will be to register async threads as critical threads (additionally to waiting for these threads in the blocing section) and update their own heartbeat. But the current fix is required too, to avoid such problems for other critical threads in the future. ср, 21 июл. 2021 г. в 06:29, Ilya Kazakov : > 1. > I mean calling listeners in CheckpointWorkflow.markCheckpointBegin(): > > This > -- > for (CheckpointListener lsnr : dbLsnrs) > lsnr.beforeCheckpointBegin(ctx0); > > ctx0.awaitPendingTasksFinished(); > -- > > And this: > > -- > // Listeners must be invoked before we write checkpoint record to WAL. > for (CheckpointListener lsnr : dbLsnrs) > lsnr.onMarkCheckpointBegin(ctx0); > > ctx0.awaitPendingTasksFinished(); > -- > > Inside lsnr.beforeCheckpointBegin(ctx0) and > lsnr.onMarkCheckpointBegin(ctx0) we call CheckpointContextImpl.executor() > which submit heartbeat update tasks in threadpool. But due to a bug in > registration, ctx0.awaitPendingTasksFinished() do not work correctly. > Checpoint thread does not wait for all tasks to complete and moves on. > > This could lead to other bugs because as written in the comment "// > Listeners must be invoked before we write checkpoint record to WAL." > > 2. > About the fix. > Yes, the fix resolves the issue, but does not resolve the root cause - a > race between checkpoint thread and threads run in asyncRunner. Also, as I > understand, there should be no attempts to update heartbeat inside > blockingSection, but the fix does not exclude such attempts but blocks them. > > 3. > But my main point is that it looks strange to update the heartbeat of > thread A from thread B. It's like doing artificial respiration and chest > compressions. Thread A is waiting on async tasks completion, but these > tasks are updating progress of thread A. I suppose that blockingSection was > designed for such situations when the thread is waiting for something and > does not perform any progress. > > вт, 20 июл. 2021 г. в 21:43, Ivan Daschinsky : > >> +1 For current fix. Code is clean and understandable. I suppose that the >> current fix is a correct variant to update heartbeatTs. >> >> вт, 20 июл. 2021 г. в 16:13, Alex Plehanov : >> >> > Hello, Ilya >> > >> > > But anyway, I propose to remove the update of the heartbeat from other >> > threads altogether and wrap the call to listeners in a blockingSection. >> > I don't quite understand your proposal. Which call to listeners do you >> > mean? If we wrap the listener into the blocking section the result will >> be >> > the same. >> > Alternatively, I think we can wrap awaitPendingTasksFinished into the >> > blocking section, this will also solve the problem, but in this case we >> can >> > never detect lack of progress by async executor threads and checkpointer >> > thread hangs due to this reason. >> > What's wrong with the current fix? It solves the current problem and I >> hope >> > will protect us from problems like this in the future. >> > >> > вт, 20 июл. 2021 г. в 15:28, Ilya Kazakov : >> > >> > > Hi Igniters, hi Alexey. >> > > >> > > I want to discuss this issue: >> > > https://issues.apache.org/jira/browse/IGNITE-15099. I have caught it >> > too. >> > > >> > > I was able to determine where there is a race. >> > > >> > > The update of the heartbeat happens asynchronously into the listener >> > code. >> > > But we always wait in the checkpoint thread for all pending async >> > > tasks. And this is reasonable. >> > > >> > > for (CheckpointListener lsnr : dbLsnrs) >> > > lsnr.beforeCheckpointBegin(ctx0); >> > > >> > > ctx0.awaitPendingTasksFinished(); >> > > >> > > The race was because of inappropriate order of future registration. In >> > > CheckpointContextImpl.executor () (inside listeners execution) >> > > >> > > GridFutureAdapter res = new GridFutureAdapter<>(); >> > > res.listen(fut -> heartbeatUpdater.updateHeartbeat()); >> > > asyncRunner.execute(U.wrapIgniteFuture(cmd, res)); >> > > pendingTaskFuture.add(res); >> > > >> > > Here we create a task, submit a task to the executor, and only after >> this >> > > do we register the task. Thus we got a situation where checkpointer >> > thread >> > > was moving on after ctx0.awaitPendingTasksFinished(); and still, >> > > the unregistered asyncRunner task was moving on in parallel. >> > > >> > > But anyway, I propose to remove the update of the heartbeat from other >> > > thread
Your Nabble Forum
We are downsizing Nabble to one server. If you want to preserve your forum: http://apache-ignite-developers.2346864.n4.nabble.com/ Then you should follow the instructions here: http://support.nabble.com/Downsizing-Nabble-tp7609715.html
Re: Your Nabble Forum
Hello! They say they don't host mailing list archives anymore. I wonder what they expect us to do here. I think it's a pity since Nabble had a great deal of SEO visibility, especially for user list. Unfortunately, Pony Mail is almost useless in that regard. Regards, -- Ilya Kasnacheev ср, 21 июл. 2021 г. в 23:23, : > We are downsizing Nabble to one server. If you want to preserve your > forum: > > http://apache-ignite-developers.2346864.n4.nabble.com/ > > Then you should follow the instructions here: > > http://support.nabble.com/Downsizing-Nabble-tp7609715.html >
Re: [Announcement] Apache Ignite 2.11 Code Freeze started
Folks, We've faced [1][2] issues related to the new functionality added to the 2.11 release (it will be safe to merge to the release branch). >From my point of view, both of them are critical and must be included in the 2.11 release. The [2] is ready for merge. The [1] will be completed by the end of this week. Please share your thoughts. [1] https://issues.apache.org/jira/browse/IGNITE-15146 [2] https://issues.apache.org/jira/browse/IGNITE-15170 On Tue, 20 Jul 2021 at 15:08, Maxim Muzafarov wrote: > > Folks, > > Since the release branch was created some time ago, should we bump up > the master branch version to the next one? > > On Thu, 1 Jul 2021 at 17:15, Alexey Gidaspov wrote: > > > > Hi, Pavel. > > > > I think, it looks like blocker. Please cherry-pick it to 2.11 release branch > > > > On 2021/07/01 09:29:57, Pavel Pereslegin wrote: > > > Hello, Alexey! > > > > > > Is it possible to include a hotfix that corrects the command syntax > > > output in the control script? [1] > > > > > > This bug can significantly complicate the use of the snapshot restore > > > function (one of the important features of 2.11). In addition, this > > > may raise a number of questions to the product support, which we can > > > prevent by adding this patch in 2.11. > > > > > > This patch does not affect any functions other than the "help" output > > > of the control script. > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-14989 > > > > > > чт, 1 июл. 2021 г. в 11:56, Alexey Gidaspov : > > > > > > > > Hi, Iilya! > > > > > > > > As I can see, this feature highly improves debugging during incidents. > > > > So I think we can call it blocker and cherry-pick to ignite-2.11 branch > > > > > > > > On 2021/06/30 20:26:43, Shishkov Ilya wrote: > > > > > Hello, Alexey! > > > > > Is it possible to add system views for BaselineNode attributes [1] and > > > > > corresponding documentation [2] to 2.11? > > > > > > > > > > 1. https://issues.apache.org/jira/browse/IGNITE-15007 > > > > > 2. https://issues.apache.org/jira/browse/IGNITE-15028 > > > > > > > > > > ср, 30 июн. 2021 г. в 11:07, Nikita Amelchev : > > > > > > > > > > > Thanks! I have cherry-picked the commit to the 2.11 branch. > > > > > > > > > > > > ср, 30 июн. 2021 г. в 11:00, Alexey Gidaspov : > > > > > > > > > > > > > > Hi, Nikita! > > > > > > > > > > > > > > I think it's important fix and should be included in 2.11 > > > > > > > release. I've > > > > > > tagged ticket by fixVersion 2.11. Can you cherry-pick it to > > > > > > ignite-2.11 > > > > > > branch? And please fill release notes or delete flag. > > > > > > > > > > > > > > On 2021/06/30 07:55:04, Nikita Amelchev > > > > > > > wrote: > > > > > > > > Hello, Alexey. > > > > > > > > > > > > > > > > I suggest adding to the 2.11 scope the resolved issue [1]. It > > > > > > > > fixes > > > > > > > > incorrect values of cache, cache groups, data region metrics > > > > > > > > after > > > > > > > > cluster reactivation. > > > > > > > > WDYT? > > > > > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-14990 > > > > > > > > > > > > > > > > вт, 29 июн. 2021 г. в 15:09, Alexey Gidaspov > > > > > > > > : > > > > > > > > > > > > > > > > > > Ok, we can add this fix to release scope. > > > > > > > > > > > > > > > > > > On 2021/06/29 08:36:00, Сурков Александр > > > > > > Викторович wrote: > > > > > > > > > > Hi Alexey. > > > > > > > > > > > > > > > > > > > > I think need add ticket: JmxMetricExporter fails to export > > > > > > discovery metrics - > > > > > > https://issues.apache.org/jira/browse/IGNITE-14376 > > > > > > > > > > > > > > > > > > > > On 2021/06/15 14:43:55, Alexey Gidaspov > > > > > > > > > > wrote: > > > > > > > > > > > Apache Ignite 2.11 Code Freeze started now> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Best wishes, > > > > > > > > Amelchev Nikita > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Best wishes, > > > > > > Amelchev Nikita > > > > > > > > > > > > > >
Apache Ignite 3 Alpha 2 webinar follow up questions
Hey everyone, I attended the Alpha 2 update yesterday and was quite pleased to see the progress on things so far. So first, congratulations to everyone on the work being put in and thank you to Val and Kseniya for running yesterday's event. I asked a few questions after the webinar which Val had some answers to but suggested posting here as some of them are not things that have been thought about yet or no plans exist around it at this point. I'll put all of them here and if necessary we can break into different threads after. 1. Schema change - does that include the ability to change the types of fields/columns? 1. Val's answer was yes with some limitations but those are not well defined yet. He did mention that something like some kind of transformer could be provided for doing the conversion and I would second this, even for common types like int to long being able to do a custom conversion will be immensely valuable. 2. Will the new guaranteed consistency between APIs also mean SQL will gain transaction support? 1. I believe the answer here was yes but perhaps someone else may want to weigh in to confirm 3. Has there been any decision about how much of Calcite will be exposed to the client? When using thick clients, it'll be hugely beneficial to be able to work with Calcite APIs directly to provide custom rules and optimisations to better suit organisation needs 1. We currently use Calcite ourselves and have a lot of custom rules and optimisations and have slowly pushed more of our queries to Calcite that we then push down to Ignite. 2. We Index into Solr and use the Solr indices and others to fulfill over all queries with Ignite just being one of the possible storage targets Calcite pushes down to. If we could get to the calcite API from an Ignite thick client, it would enable us to remove a layer of abstraction and complexity and make Ignite our primary that we then link with Solr and others to fulfill queries. 4. Will the unified storage model enable different versions of Ignite to be in the cluster when persistence is enabled so that rolling restarts can be done? 1. We have to do a strange dance to perform Ignite upgrades without downtime because pods/nodes will fail to start on version mismatch and if we get that dance wrong, we will corrupt a node's data. It will make admin/upgrades far less brittle and error prone if this was possible. 5. Will it be possible to provide a custom cache store still and will these changes enable custom cache stores to be queryable from SQL? 1. Our Ignite usage is wide and complex because we use KV, SQL and other APIs. The inconsistency of what can and can't be used from one API to another is a real challenge and has forced us over time to stick to one API and write alternative solutions outside of Ignite. It will drastically simplify things if any CacheStore (or some new equivalent) could be plugged in and be made accessible to SQL (and in fact all other APIs) without having to load all the data from the underlying CacheStore first into memory 6. This question wasn't mine but I was going to ask it as well: What will happen to the Indexing API since H2 is being removed? 1. As I mentioned above, we Index into Solr, in earlier versions of our product we used the indexing SPI to index into Lucene on the Ignite nodes but this presented so many challenges we ultimately abandoned it and replaced it with the current Solr solution. 2. Lucene indexing was ideal because it meant we didn't have to re-invent Solr or Elasticsearch's sharding capabilities, that was almost automatic with Ignite only giving you the data that was meant for the current node. 3. The Lucene API enabled more flexibility and removed a network round trip from our queries. 4. Given Calcite's ability to support custom SQL functions, I'd love to have the ability to define custom functions that Lucene was answering 7. What impact does RAFT now have on conflict resolution, off the top of my head there are two cases 1. On startup after a split brain Ignite currently takes an "exercise for the reader" approach and dumps a log along the lines of >1. BaselineTopology of joining node is not compatible with > BaselineTopology in the cluster. >1. Branching history of cluster BlT doesn't contain branching point > hash of joining node BlT. Consider cleaning persistent storage of the > node > and adding it to the cluster again. > 1. This leaves you with no choice except to take one half and manually copy, write data back over to the other half then destroy the bad one. 2. The second case is conflicts on keys, I beleive CacheVersionConflictResolver and manager are used by GridCacheM
Re: [Announcement] Apache Ignite 2.11 Code Freeze started
+1 to fix both prior to release Отправлено с iPhone > 22 июля 2021 г., в 02:36, Maxim Muzafarov написал(а): > > Folks, > > We've faced [1][2] issues related to the new functionality added to > the 2.11 release (it will be safe to merge to the release branch). > From my point of view, both of them are critical and must be included > in the 2.11 release. > The [2] is ready for merge. The [1] will be completed by the end of this week. > > Please share your thoughts. > > [1] https://issues.apache.org/jira/browse/IGNITE-15146 > [2] https://issues.apache.org/jira/browse/IGNITE-15170 > >> On Tue, 20 Jul 2021 at 15:08, Maxim Muzafarov wrote: >> >> Folks, >> >> Since the release branch was created some time ago, should we bump up >> the master branch version to the next one? >> >>> On Thu, 1 Jul 2021 at 17:15, Alexey Gidaspov wrote: >>> >>> Hi, Pavel. >>> >>> I think, it looks like blocker. Please cherry-pick it to 2.11 release branch >>> >>> On 2021/07/01 09:29:57, Pavel Pereslegin wrote: Hello, Alexey! Is it possible to include a hotfix that corrects the command syntax output in the control script? [1] This bug can significantly complicate the use of the snapshot restore function (one of the important features of 2.11). In addition, this may raise a number of questions to the product support, which we can prevent by adding this patch in 2.11. This patch does not affect any functions other than the "help" output of the control script. [1] https://issues.apache.org/jira/browse/IGNITE-14989 чт, 1 июл. 2021 г. в 11:56, Alexey Gidaspov : > > Hi, Iilya! > > As I can see, this feature highly improves debugging during incidents. So > I think we can call it blocker and cherry-pick to ignite-2.11 branch > > On 2021/06/30 20:26:43, Shishkov Ilya wrote: >> Hello, Alexey! >> Is it possible to add system views for BaselineNode attributes [1] and >> corresponding documentation [2] to 2.11? >> >> 1. https://issues.apache.org/jira/browse/IGNITE-15007 >> 2. https://issues.apache.org/jira/browse/IGNITE-15028 >> >> ср, 30 июн. 2021 г. в 11:07, Nikita Amelchev : >> >>> Thanks! I have cherry-picked the commit to the 2.11 branch. >>> >>> ср, 30 июн. 2021 г. в 11:00, Alexey Gidaspov : Hi, Nikita! I think it's important fix and should be included in 2.11 release. I've >>> tagged ticket by fixVersion 2.11. Can you cherry-pick it to ignite-2.11 >>> branch? And please fill release notes or delete flag. On 2021/06/30 07:55:04, Nikita Amelchev wrote: > Hello, Alexey. > > I suggest adding to the 2.11 scope the resolved issue [1]. It fixes > incorrect values of cache, cache groups, data region metrics after > cluster reactivation. > WDYT? > > [1] https://issues.apache.org/jira/browse/IGNITE-14990 > > вт, 29 июн. 2021 г. в 15:09, Alexey Gidaspov : >> >> Ok, we can add this fix to release scope. >> >> On 2021/06/29 08:36:00, Сурков Александр >>> Викторович wrote: >>> Hi Alexey. >>> >>> I think need add ticket: JmxMetricExporter fails to export >>> discovery metrics - https://issues.apache.org/jira/browse/IGNITE-14376 >>> >>> On 2021/06/15 14:43:55, Alexey Gidaspov wrote: Apache Ignite 2.11 Code Freeze started now> > > > > -- > Best wishes, > Amelchev Nikita > >>> >>> >>> >>> -- >>> Best wishes, >>> Amelchev Nikita >>> >>
