Re: [DISCUSSION] Tracing: IGNITE-13060

[Ivan Rakov]

Igniters,

The PR is ready to be merged, all comments from my side have been fixed.
If anyone has more comments, please let know today.

Best Regards,
Ivan Rakov



On Tue, Jun 30, 2020 at 10:43 AM Alexander Lapin 
wrote:

> Hello Igniters,
>
> I'd like to discuss with you and then donate changes related to
> IGNITE-13060
> 
> In very brief it's an initial tracing implementation that allows to thrace
> Communication, Exchange, Discovery and Transactions. Spi concept is used
> with OpenCensus as one of implementations. For more details about tracing
> engine, tracing configuration, etc please see IEP-48
> .
>
> Best regards,
> Alexander
>

Re: Apache Ignite 2.9.0 RELEASE [Time, Scope, Manager]

[Ivan Rakov]

Hi,

We are still waiting for a final review of Tracing functionality [1] until
the end of tomorrow (July 15).
We anticipate that it will be merged to Ignite master no later than July 16.

Sorry for being a bit late here. Alex P., can you include [1] to the
release scope?

[1]: https://issues.apache.org/jira/browse/IGNITE-13060

--
Best Regards,
Ivan Rakov

On Tue, Jul 14, 2020 at 6:16 AM Alexey Kuznetsov 
wrote:

> Alex,
>
> Can you cherry-pick to Ignite 2.9 this issue:
> https://issues.apache.org/jira/browse/IGNITE-13246 ?
>
> This issue is about BASELINE events and it is very useful for notification
> external tools about changes in baseline.
>
> Thank you!
>
> ---
> Alexey Kuznetsov
>

Re: Apache Ignite 2.9.0 RELEASE [Time, Scope, Manager]

[Alex Plehanov]

Ivan,

It was already in release scope as discussed in this thread.

вт, 14 июл. 2020 г. в 14:31, Ivan Rakov :

> Hi,
>
> We are still waiting for a final review of Tracing functionality [1] until
> the end of tomorrow (July 15).
> We anticipate that it will be merged to Ignite master no later than July
> 16.
>
> Sorry for being a bit late here. Alex P., can you include [1] to the
> release scope?
>
> [1]: https://issues.apache.org/jira/browse/IGNITE-13060
>
> --
> Best Regards,
> Ivan Rakov
>
> On Tue, Jul 14, 2020 at 6:16 AM Alexey Kuznetsov 
> wrote:
>
>> Alex,
>>
>> Can you cherry-pick to Ignite 2.9 this issue:
>> https://issues.apache.org/jira/browse/IGNITE-13246 ?
>>
>> This issue is about BASELINE events and it is very useful for notification
>> external tools about changes in baseline.
>>
>> Thank you!
>>
>> ---
>> Alexey Kuznetsov
>>
>

NodeFilter discussion

[Aleksandr Shapkin]

Hi,

I'm working on adding the NodeFilter functionality to the .NET client
https://issues.apache.org/jira/browse/IGNITE-2890

And there are several points I want to highlight regarding the current
implementation:

1) A node filter is being called on every put which seems redundant. This
might be ok unless we don't cross the JNI boundaries. For .NET, it means at
least an additional serialization on every cache operation.
Can we change this behavior and call CU.affinityNode(node, aff.cacheFilter)
only once per assignment? Or at least to wrap it with some cacheable
function?

2) It feels like the default AttributeNodeFilter is suitable for most of
the cases. I found an existing proposal of removing custom filters, but the
thread seems to be abandoned:
http://apache-ignite-developers.2346864.n4.nabble.com/Replacing-NodeFilter-functionality-with-label-approach-td42874.html#a42942

Do we need to support those filters?

3) I noticed that in reality a filter is limited to the DetachedClusterNode
representation. Consider the following stack trace and the #
createBaselineView

 at 
org.apache.ignite.internal.processors.cache.GridCacheUtils.affinityNode(GridCacheUtils.java:1332)
  at 
org.apache.ignite.internal.processors.cluster.BaselineTopology.createBaselineView(BaselineTopology.java:329)
  at 
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.recalculateBaselineAssignment(GridAffinityAssignmentCache.java:461)


Thus, any NodeFilter depending on a ClusterNode#addresses
or ClusterNode#metrics will fail due to "Operation is not supported on
DetachedClusterNode".

Therefore if we disallow custom node filters completely, the latter issue
would be resolved as well.

Am I missing something?

-- 
Alex.

Re: NodeFilter discussion

[Pavel Tupitsyn]

Alex,

Thank you for diving into this.
Indeed, custom node filters seem to have some issues.

1. For .NET, I'm fairly certain that we don't need custom node filters.
Let's just make AttributeNodeFilter available natively (as a .NET class).

2. For Java, we should at least fix the "call filter on every cache op"
behavior -
should be a simple fix.


On Tue, Jul 14, 2020 at 12:48 PM Aleksandr Shapkin 
wrote:

> Hi,
>
> I'm working on adding the NodeFilter functionality to the .NET client
> https://issues.apache.org/jira/browse/IGNITE-2890
>
> And there are several points I want to highlight regarding the current
> implementation:
>
> 1) A node filter is being called on every put which seems redundant. This
> might be ok unless we don't cross the JNI boundaries. For .NET, it means at
> least an additional serialization on every cache operation.
> Can we change this behavior and call CU.affinityNode(node, aff.cacheFilter)
> only once per assignment? Or at least to wrap it with some cacheable
> function?
>
> 2) It feels like the default AttributeNodeFilter is suitable for most of
> the cases. I found an existing proposal of removing custom filters, but the
> thread seems to be abandoned:
>
> http://apache-ignite-developers.2346864.n4.nabble.com/Replacing-NodeFilter-functionality-with-label-approach-td42874.html#a42942
>
> Do we need to support those filters?
>
> 3) I noticed that in reality a filter is limited to the DetachedClusterNode
> representation. Consider the following stack trace and the #
> createBaselineView
>
>  at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.affinityNode(GridCacheUtils.java:1332)
>   at
> org.apache.ignite.internal.processors.cluster.BaselineTopology.createBaselineView(BaselineTopology.java:329)
>   at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.recalculateBaselineAssignment(GridAffinityAssignmentCache.java:461)
>
>
> Thus, any NodeFilter depending on a ClusterNode#addresses
> or ClusterNode#metrics will fail due to "Operation is not supported on
> DetachedClusterNode".
>
> Therefore if we disallow custom node filters completely, the latter issue
> would be resolved as well.
>
> Am I missing something?
>
> --
> Alex.
>

[jira] [Created] (IGNITE-13253) Advanced heuristics for historical rebalance

[Vladislav Pyatkov (Jira)]

Vladislav Pyatkov created IGNITE-13253:
--

 Summary: Advanced heuristics for historical rebalance
 Key: IGNITE-13253
 URL: https://issues.apache.org/jira/browse/IGNITE-13253
 Project: Ignite
  Issue Type: Improvement
Reporter: Vladislav Pyatkov


Before, cluster detects partitions that have not to rebalance by history, by 
them size. This threshold might be set through a system property 
IGNITE_PDS_WAL_REBALANCE_THRESHOLD. But it is not fair deciding which 
partitions will be rebalanced by WAL only by them size. WAL can have much more 
records than size of a partition (many update by one key) and that rebalance 
required more data than full transferring by network.
Need to implement a heuristic, that might to estimate data size.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-13255) ODBC/JDBC is very slow

[Christian Ehrlicher (Jira)]

Christian Ehrlicher created IGNITE-13255:


 Summary: ODBC/JDBC is very slow
 Key: IGNITE-13255
 URL: https://issues.apache.org/jira/browse/IGNITE-13255
 Project: Ignite
  Issue Type: Bug
  Components: jdbc, odbc
Affects Versions: 2.8.1
Reporter: Christian Ehrlicher
 Attachments: create_table.sql, drop_table.sql

The ODBC/JDBC interface seems to be very slow compared to other databases. I'm 
not sure if it is a configuration problem on my side but since I more or less 
used the default configuration I don't think so.

Attached a small testcase which simply creates 100 tables and another one which 
deletes them afterwards. Executing both in a sql browser (I'm using DBeaver for 
this test, but should not matter) takes 17 and 20 seconds and java.exe takes ~2 
full cpus. Executing this on a postgreSQL or informix database the runtime is 
~200 / 60 msec.

Even considering that it's no sql database I find the execution times far from 
useable. Is this maybe a regression?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-13254) Historical rebalance iterator may skip checkpoint if it not contains updates

[Vladislav Pyatkov (Jira)]

Vladislav Pyatkov created IGNITE-13254:
--

 Summary: Historical rebalance iterator may skip checkpoint if it 
not contains updates
 Key: IGNITE-13254
 URL: https://issues.apache.org/jira/browse/IGNITE-13254
 Project: Ignite
  Issue Type: Improvement
Reporter: Vladislav Pyatkov






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Choosing historical rebalance heuristics

[Vladislav Pyatkov]

Hi guys,

I want to implement a more honest heuristic for historical rebalance.
Before, a cluster makes a choice between the historical rebalance or not it
only from a partition size. This threshold more known by a name of property
IGNITE_PDS_WAL_REBALANCE_THRESHOLD.
It might prevent a historical rebalance when a partition is too small, but
not if WAL contains more updates than a size of partition, historical
rebalance still can be chosen.
There is a ticket where need to implement more fair heuristic[1].

My idea for implementation is need to estimate a size of data which will be
transferred owe network. In other word if need to rebalance a part of WAL
that contains N updates, for recover a partition on another node, which
have to contain M rows at all, need chooses a historical rebalance on the
case where N < M (WAL history should be presented as well).

This approach is easy implemented, because a coordinator node has the size
of partitions and counters' interval. But in this case cluster still can
find not many updates in too long WAL history. I assume a possibility to
work around it, if rebalance historical iterator will not handle
checkpoints where not contains updates of particular cache. Checkpoints can
skip if counters for the cache (maybe even a specific partitions) was not
changed between it and next one.

Ticket for improvement rebalance historical iterator[2]

I want to hear a view of community on the thought above.
Maybe anyone has another opinion?

[1]: https://issues.apache.org/jira/browse/IGNITE-13253
[2]: https://issues.apache.org/jira/browse/IGNITE-13254

-- 
Vladislav Pyatkov

Re: IEP-50 Thin Client Continuous Queries

[Pavel Tupitsyn]

I've removed Initial Query from the POC and IEP (left a note there about
the decision).

Since there are no other comments and concerns, I'll move on with the final
implementation.

On Fri, Jul 10, 2020 at 4:14 PM Pavel Tupitsyn  wrote:

> Igor, Alex,
>
> I was aware of the duplicates issue with the initial query, but I did not
> give it a second thought.
>
> Now I see that Vladimir was right - Initial query seems to be pointless,
> since users can
> achieve the same by simply invoking the regular query.
>
> I will remove Initial Query from the IEP and POC next week if there are no
> objections by then.
>
>
> On Fri, Jul 10, 2020 at 3:58 PM Alex Plehanov 
> wrote:
>
>> Igor, Pavel,
>>
>> Here is discussion about removal: [1]
>>
>> [1] :
>>
>> http://apache-ignite-developers.2346864.n4.nabble.com/ContinuousQueryWithTransformer-implementation-questions-2-td21418i20.html#a22041
>>
>> пт, 10 июл. 2020 г. в 17:44, Igor Sapego :
>>
>> > Can not find proposal to remove them, so maybe it was not on devlist,
>> > but here is discussion about the problem: [1]
>> >
>> > [1] -
>> >
>> >
>> http://apache-ignite-developers.2346864.n4.nabble.com/Continuous-queries-and-duplicates-td39444.html
>> >
>> > Best Regards,
>> > Igor
>> >
>> >
>> > On Fri, Jul 10, 2020 at 3:27 PM Pavel Tupitsyn 
>> > wrote:
>> >
>> > > > What's about "stop" message? How can user unsubscribe from receiving
>> > > notifications?
>> > > OP_RESOURCE_CLOSE is used for that. I've updated the IEP in an
>> attempt to
>> > > make this cleaner.
>> > >
>> > > >  I've seen discussions on removing initial query from continuous
>> > queries
>> > > Interesting, I'm not aware of this. Can you please link those
>> > discussions?
>> > >
>> > > On Fri, Jul 10, 2020 at 2:04 PM Igor Sapego 
>> wrote:
>> > >
>> > > > Pavel,
>> > > >
>> > > > What's about "stop" message? How can user unsubscribe from receiving
>> > > > notifications?
>> > > >
>> > > > Also, I believe I've seen discussions on removing initial query from
>> > > > continuous queries,
>> > > > as there are not any guarantees about getting consistent results
>> with
>> > > them.
>> > > > Should
>> > > > we avoid adding them in thin protocol maybe? It would also simplify
>> > > > protocol a lot.
>> > > >
>> > > > Best Regards,
>> > > > Igor
>> > > >
>> > > >
>> > > > On Tue, Jun 30, 2020 at 2:39 PM Pavel Tupitsyn <
>> ptupit...@apache.org>
>> > > > wrote:
>> > > >
>> > > > > Igniters,
>> > > > >
>> > > > > Let's discuss Thin Client Continuous Queries,
>> > > > > I've prepared an IEP [1] and a PoC [2].
>> > > > >
>> > > > > [1]
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-50%3A+Thin+Client+Continuous+Queries
>> > > > >
>> > > > > [2] https://github.com/apache/ignite/pull/7966
>> > > > >
>> > > >
>> > >
>> >
>>
>

[jira] [Created] (IGNITE-13256) IgniteCacheNearRestartRollbackSelfTest.testRestarts (Cache restarts) (Regression) became flaky

[Sergey Uttsel (Jira)]

Sergey Uttsel created IGNITE-13256:
--

 Summary: IgniteCacheNearRestartRollbackSelfTest.testRestarts 
(Cache restarts) (Regression) became flaky
 Key: IGNITE-13256
 URL: https://issues.apache.org/jira/browse/IGNITE-13256
 Project: Ignite
  Issue Type: Bug
Reporter: Sergey Uttsel






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-13257) Kubernetes example is not working

[Maksim Timonin (Jira)]

Maksim Timonin created IGNITE-13257:
---

 Summary: Kubernetes example is not working
 Key: IGNITE-13257
 URL: https://issues.apache.org/jira/browse/IGNITE-13257
 Project: Ignite
  Issue Type: Bug
Reporter: Maksim Timonin
Assignee: Maksim Timonin


kubernetes module contains config directory that:
 # contains misleading DEVNOTES.txt that contains non-actual description how to 
assemble Apache Ignite;
 # default example isn't worked out-of-the box:
 ## latest kubernetes complains about deployment API version;
 ## leads to 403 error while nodes try find each other. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re[2]: Apache Ignite 2.9.0 RELEASE [Time, Scope, Manager]

[Zhenya Stanilovsky]

 
Alex, i also suggest to merge this 
https://issues.apache.org/jira/browse/IGNITE-13229 too, GridClient leakage and 
further TC OOM preventing.
 
>Ivan,
>
>It was already in release scope as discussed in this thread.
>
>вт, 14 июл. 2020 г. в 14:31, Ivan Rakov < ivan.glu...@gmail.com >:
> 
>> Hi,
>>
>> We are still waiting for a final review of Tracing functionality [1] until
>> the end of tomorrow (July 15).
>> We anticipate that it will be merged to Ignite master no later than July
>> 16.
>>
>> Sorry for being a bit late here. Alex P., can you include [1] to the
>> release scope?
>>
>> [1]:  https://issues.apache.org/jira/browse/IGNITE-13060
>>
>> --
>> Best Regards,
>> Ivan Rakov
>>
>> On Tue, Jul 14, 2020 at 6:16 AM Alexey Kuznetsov < akuznet...@gridgain.com >
>> wrote:
>>
>>> Alex,
>>>
>>> Can you cherry-pick to Ignite 2.9 this issue:
>>>  https://issues.apache.org/jira/browse/IGNITE-13246 ?
>>>
>>> This issue is about BASELINE events and it is very useful for notification
>>> external tools about changes in baseline.
>>>
>>> Thank you!
>>>
>>> ---
>>> Alexey Kuznetsov
>>>
>> 
 
 
 
 

[jira] [Created] (IGNITE-13258) Improve control.sh --cache list command to show cache sizes

[Vladimir Goncharov (Jira)]

Vladimir Goncharov created IGNITE-13258:
---

 Summary: Improve control.sh --cache list command to show cache 
sizes
 Key: IGNITE-13258
 URL: https://issues.apache.org/jira/browse/IGNITE-13258
 Project: Ignite
  Issue Type: Improvement
  Components: general
Affects Versions: 2.8.1
Reporter: Vladimir Goncharov


For now --list command doesn't show cache size.
CacheInfo and ViewCacheClosure is extended with cache size parameter and 
according code to show caches size.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: NodeFilter discussion

[Valentin Kulichenko]

This might be a topic for Ignite 3.0, but I do agree that the ability to
create custom node filters is unnecessary and error-prone. Attribute-based
filtering should be more than enough.

-Val

On Tue, Jul 14, 2020 at 3:15 AM Pavel Tupitsyn  wrote:

> Alex,
>
> Thank you for diving into this.
> Indeed, custom node filters seem to have some issues.
>
> 1. For .NET, I'm fairly certain that we don't need custom node filters.
> Let's just make AttributeNodeFilter available natively (as a .NET class).
>
> 2. For Java, we should at least fix the "call filter on every cache op"
> behavior -
> should be a simple fix.
>
>
> On Tue, Jul 14, 2020 at 12:48 PM Aleksandr Shapkin 
> wrote:
>
> > Hi,
> >
> > I'm working on adding the NodeFilter functionality to the .NET client
> > https://issues.apache.org/jira/browse/IGNITE-2890
> >
> > And there are several points I want to highlight regarding the current
> > implementation:
> >
> > 1) A node filter is being called on every put which seems redundant. This
> > might be ok unless we don't cross the JNI boundaries. For .NET, it means
> at
> > least an additional serialization on every cache operation.
> > Can we change this behavior and call CU.affinityNode(node,
> aff.cacheFilter)
> > only once per assignment? Or at least to wrap it with some cacheable
> > function?
> >
> > 2) It feels like the default AttributeNodeFilter is suitable for most of
> > the cases. I found an existing proposal of removing custom filters, but
> the
> > thread seems to be abandoned:
> >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Replacing-NodeFilter-functionality-with-label-approach-td42874.html#a42942
> >
> > Do we need to support those filters?
> >
> > 3) I noticed that in reality a filter is limited to the
> DetachedClusterNode
> > representation. Consider the following stack trace and the #
> > createBaselineView
> >
> >  at
> >
> org.apache.ignite.internal.processors.cache.GridCacheUtils.affinityNode(GridCacheUtils.java:1332)
> >   at
> >
> org.apache.ignite.internal.processors.cluster.BaselineTopology.createBaselineView(BaselineTopology.java:329)
> >   at
> >
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.recalculateBaselineAssignment(GridAffinityAssignmentCache.java:461)
> >
> >
> > Thus, any NodeFilter depending on a ClusterNode#addresses
> > or ClusterNode#metrics will fail due to "Operation is not supported on
> > DetachedClusterNode".
> >
> > Therefore if we disallow custom node filters completely, the latter issue
> > would be resolved as well.
> >
> > Am I missing something?
> >
> > --
> > Alex.
> >
>

Re: Proposal of new event QUERY_EXECUTION_EVENT

[Denis Magda]

Hi Max,

Could you check if the EVT_CACHE_QUERY_EXECUTED event is what you're
looking for?
https://www.gridgain.com/docs/latest/developers-guide/events/events#cache-query-events

-
Denis


On Fri, Jul 10, 2020 at 3:54 AM Max Timonin  wrote:

> Hi Igniters!
>
> We're going to protocol all input SQL queries from our users. Currently
> there is no such mechanism in Ignite to use for it. So we're proposing to
> add a new event: QUERY_EXECUITION_EVENT.
>
> Requirements for the event:
> 1. If this event fires it means that a query is correct and will be
> executed (and failed only in exceptional cases);
>
> 2. Event fires for all query types;
>
> 3. Required fields are:
> - text of a query (with hidden arguments);
> - arguments of query;
> - query type;
> - node id.
>
> Looks that this event should go along with `runningQryMgr::register` in
> class `IgniteH2Indexing` as this method invoked for all input queries too.
>
> What do you think?
>
> Regards,
> Maksim
>

Re: [DISCUSSION] Complete Discontinuation of IGFS and Hadoop Accelerator

[Denis Magda]

I don't think it's required to wait until Ignite 3.0 to make this happen.
If I'm not mistaken, we stopped releasing Hadoop binaries and sources a
long time ago (at least you can't longer find them on the downloads page).
Also, we removed all the mentioning from the documentation and website.
Nobody complained or requested for a maintenance release since that time.
Thus, I would remove the integration in 2.9. If anybody shows up later then
they can use the sources in the 2.8 branch and do whatever they want.

-
Denis


On Thu, Jul 9, 2020 at 3:52 AM Pavel Tupitsyn  wrote:

> We are breaking backwards compatibility,
> so this can be only done for Ignite 3.0, am I right?
>
> On Thu, Jul 9, 2020 at 1:46 PM Anton Kalashnikov 
> wrote:
>
> > Hi everyone,
> >
> > The task of removal IGFS and Hadoop accelerator is ready to review.(
> > https://issues.apache.org/jira/browse/IGNITE-11942)
> > I've already asked some guys to take a look at it but if somebody
> familiar
> > with this part of code, feel free to take a look at the changes
> > too(especially scripts changes).
> >
> > I also think it is good to decide which release it should be planned on.
> > This task planned for 2.9 right now but I should notice that first of all
> > there are a lot of changes and secondly there are some changes in public
> > API(removed some methods from configuration). So maybe it makes sense to
> > move this ticket to the next release. What do you think?
> >
> > --
> > Best regards,
> > Anton Kalashnikov
> >
> >
> > 10.02.2020, 15:45, "Alexey Zinoviev" :
> > > Thank you so you much! Will wait:)
> > >
> > > пн, 10 февр. 2020 г. в 15:13, Alexey Goncharuk <
> > alexey.goncha...@gmail.com>:
> > >
> > >>  Got it, then no need to rush, let's wait for the TF-IGFS decoupling.
> > >>
> > >>  пн, 10 февр. 2020 г. в 13:15, Alexey Zinoviev <
> zaleslaw@gmail.com
> > >:
> > >>
> > >>  > Tensorflow integration uses IGFS, if you have any idea how to store
> > files
> > >>  > in memory by another way, please suggest something.
> > >>  > I hope to decouple Ignite-TF integration to the separate repository
> > >>  before
> > >>  > release 2.9 with its own file system over Ignite Caches
> > >>  >
> > >>  > пн, 10 февр. 2020 г. в 12:49, Ivan Pavlukhin  >:
> > >>  >
> > >>  > > Is not it blocked by
> > >>  > > https://issues.apache.org/jira/browse/IGNITE-10292 as stated in
> > JIRA?
> > >>  > >
> > >>  > > @Alex Zinoviev could you please shed some light on this?
> > >>  > >
> > >>  > > Best regards,
> > >>  > > Ivan Pavlukhin
> > >>  > >
> > >>  > > пн, 10 февр. 2020 г. в 12:46, Anton Kalashnikov <
> kaa@yandex.ru
> > >:
> > >>  > >
> > >>  > > >
> > >>  > > > I found the correct ticket for such activity -
> > >>  > > https://issues.apache.org/jira/browse/IGNITE-11942
> > >>  > > >
> > >>  > > > --
> > >>  > > > Best regards,
> > >>  > > > Anton Kalashnikov
> > >>  > > >
> > >>  > > >
> > >>  > > > 10.02.2020, 12:16, "Anton Kalashnikov" :
> > >>  > > > > Hello.
> > >>  > > > >
> > >>  > > > > I created a ticket for this activity -
> > >>  > > https://issues.apache.org/jira/browse/IGNITE-12647. And if we
> are
> > >>  still
> > >>  > > in consensus I'll do it at the nearest time(I've already had the
> > >>  prepared
> > >>  > > code).
> > >>  > > > >
> > >>  > > > > --
> > >>  > > > > Best regards,
> > >>  > > > > Anton Kalashnikov
> > >>  > > > >
> > >>  > > > > 10.02.2020, 12:07, "Alexey Goncharuk" <
> > alexey.goncha...@gmail.com
> > >>  >:
> > >>  > > > >> Folks,
> > >>  > > > >>
> > >>  > > > >> I think there is a consensus here, but we did not remove
> IGFS
> > >>  > > neither in
> > >>  > > > >> 2.7 nor in 2.8, did we? Should we schedule a corresponding
> > ticket
> > >>  > > for 2.9?
> > >>  > >
> > >>  >
> >
>

Re: IEP-50 Thin Client Continuous Queries

[Pavel Tupitsyn]

Igniters,

I've made an important change to the IEP (and the POC):
OP_QUERY_CONTINUOUS_END_NOTIFICATION is another client -> server message
that notifies the client that the query has stopped and no more events
should be expected.

This is important because client can't immediately stop listening
for OP_QUERY_CONTINUOUS_EVENT_NOTIFICATION
after sending OP_RESOURCE_CLOSE - some more events can be present in one of
the buffers/queues of the server and/or the OS.

Let me know if this makes sense.

On Tue, Jul 14, 2020 at 3:25 PM Pavel Tupitsyn  wrote:

> I've removed Initial Query from the POC and IEP (left a note there about
> the decision).
>
> Since there are no other comments and concerns, I'll move on with the
> final implementation.
>
> On Fri, Jul 10, 2020 at 4:14 PM Pavel Tupitsyn 
> wrote:
>
>> Igor, Alex,
>>
>> I was aware of the duplicates issue with the initial query, but I did not
>> give it a second thought.
>>
>> Now I see that Vladimir was right - Initial query seems to be pointless,
>> since users can
>> achieve the same by simply invoking the regular query.
>>
>> I will remove Initial Query from the IEP and POC next week if there are
>> no objections by then.
>>
>>
>> On Fri, Jul 10, 2020 at 3:58 PM Alex Plehanov 
>> wrote:
>>
>>> Igor, Pavel,
>>>
>>> Here is discussion about removal: [1]
>>>
>>> [1] :
>>>
>>> http://apache-ignite-developers.2346864.n4.nabble.com/ContinuousQueryWithTransformer-implementation-questions-2-td21418i20.html#a22041
>>>
>>> пт, 10 июл. 2020 г. в 17:44, Igor Sapego :
>>>
>>> > Can not find proposal to remove them, so maybe it was not on devlist,
>>> > but here is discussion about the problem: [1]
>>> >
>>> > [1] -
>>> >
>>> >
>>> http://apache-ignite-developers.2346864.n4.nabble.com/Continuous-queries-and-duplicates-td39444.html
>>> >
>>> > Best Regards,
>>> > Igor
>>> >
>>> >
>>> > On Fri, Jul 10, 2020 at 3:27 PM Pavel Tupitsyn 
>>> > wrote:
>>> >
>>> > > > What's about "stop" message? How can user unsubscribe from
>>> receiving
>>> > > notifications?
>>> > > OP_RESOURCE_CLOSE is used for that. I've updated the IEP in an
>>> attempt to
>>> > > make this cleaner.
>>> > >
>>> > > >  I've seen discussions on removing initial query from continuous
>>> > queries
>>> > > Interesting, I'm not aware of this. Can you please link those
>>> > discussions?
>>> > >
>>> > > On Fri, Jul 10, 2020 at 2:04 PM Igor Sapego 
>>> wrote:
>>> > >
>>> > > > Pavel,
>>> > > >
>>> > > > What's about "stop" message? How can user unsubscribe from
>>> receiving
>>> > > > notifications?
>>> > > >
>>> > > > Also, I believe I've seen discussions on removing initial query
>>> from
>>> > > > continuous queries,
>>> > > > as there are not any guarantees about getting consistent results
>>> with
>>> > > them.
>>> > > > Should
>>> > > > we avoid adding them in thin protocol maybe? It would also simplify
>>> > > > protocol a lot.
>>> > > >
>>> > > > Best Regards,
>>> > > > Igor
>>> > > >
>>> > > >
>>> > > > On Tue, Jun 30, 2020 at 2:39 PM Pavel Tupitsyn <
>>> ptupit...@apache.org>
>>> > > > wrote:
>>> > > >
>>> > > > > Igniters,
>>> > > > >
>>> > > > > Let's discuss Thin Client Continuous Queries,
>>> > > > > I've prepared an IEP [1] and a PoC [2].
>>> > > > >
>>> > > > > [1]
>>> > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-50%3A+Thin+Client+Continuous+Queries
>>> > > > >
>>> > > > > [2] https://github.com/apache/ignite/pull/7966
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>
>>

[MTCGA]: new failures in builds [5459975] needs to be handled

[dpavlov . tasks]

Hi Igniters,

 I've detected some new issue on TeamCity to be handled. You are more than 
welcomed to help.

 *New test failure in master-nightly 
IgfsLocalSecondaryFileSystemDualAsyncSelfTest.testAccessAndModificationTimeUpwardsPropagation
 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-4311898764848411041&branch=%3Cdefault%3E&tab=testDetails
 No changes in the build

 - Here's a reminder of what contributors were agreed to do 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute 
 - Should you have any questions please contact dev@ignite.apache.org 

Best Regards,
Apache Ignite TeamCity Bot 
https://github.com/apache/ignite-teamcity-bot
Notification generated at 02:59:20 15-07-2020 

Re: IGNITE-12362 Migrate MQTT module to ignite-extensions

[Saikat Maitra]

Hi Ilya,

Thank you for your reply. I will check if I can recover the nightly
artifact publish job.

Regards,
Saikat

On Mon, Jul 13, 2020 at 6:00 AM Ilya Kasnacheev 
wrote:

> Hello!
>
> We used to publish nightlies to some non-main repo but I'm afraid this may
> be broken currently.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пн, 13 июл. 2020 г. в 01:07, Saikat Maitra :
>
> > Hi Ilya,
> >
> > Thank you for reviewing the changes. I have merged the PRs.
> >
> > I will need to look into how we can pull nightly snapshots build of
> > ignite-core module for Travis build to pass.
> >
> > Travis build is currently failing as it is unable to pull 2.9.0-SNAPSHOT
> > version.
> >
> > Regards,
> > Saikat
> >
> > On Fri, Jul 10, 2020 at 5:55 AM Ilya Kasnacheev <
> ilya.kasnach...@gmail.com
> > >
> > wrote:
> >
> > > Hello!
> > >
> > > I have checked it, looks OK. Please note that Travis fails in
> ignite-ext.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > пт, 3 июл. 2020 г. в 21:50, Saikat Maitra :
> > >
> > > > Hi
> > > >
> > > > I have created PRs for the following jira issue.
> > > >
> > > > https://issues.apache.org/jira/browse/IGNITE-12362
> > > >
> > > > IGNITE-12362 Migrate MQTT module to ignite-extensions
> > > >
> > > > PRs
> > > > https://github.com/apache/ignite-extensions
> > > > https://github.com/apache/ignite/pull/7950
> > > >
> > > >
> > > > Please review and share your feedback.
> > > >
> > > > Regards,
> > > > Saikat
> > > >
> > > > On Sun, Jun 21, 2020 at 3:44 PM Saikat Maitra <
> saikat.mai...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I have created PRs for the following jira issue.
> > > > >
> > > > > https://issues.apache.org/jira/browse/IGNITE-12362
> > > > >
> > > > > IGNITE-12362 Migrate MQTT module to ignite-extensions
> > > > >
> > > > > PRs
> > > > > https://github.com/apache/ignite-extensions
> > > > > https://github.com/apache/ignite/pull/7950
> > > > >
> > > > >
> > > > > Please review and share your feedback.
> > > > >
> > > > > Regards,
> > > > > Saikat
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>

[jira] [Created] (IGNITE-13259) "default" cache usage should be removed from REST API

[Evgeniy Rudenko (Jira)]

Evgeniy Rudenko created IGNITE-13259:


 Summary: "default" cache usage should be removed from REST API
 Key: IGNITE-13259
 URL: https://issues.apache.org/jira/browse/IGNITE-13259
 Project: Ignite
  Issue Type: Improvement
Reporter: Evgeniy Rudenko
Assignee: Evgeniy Rudenko


Right now lots of REST APIs will try to use "default" cache if cacheName is not 
provided. This is pointless because such cache doesn't exist by default. It 
will be better to change current behavior and return correct error instead of 
"Failed to find cache for given cache name: default".



--
This message was sent by Atlassian Jira
(v8.3.4#803005)