Re: Ignite website HTML files are not updated for 2.8 release
Mauricio, Thanks for the quick turnaround. I've merged the patch. Look forward to getting the updated instructions. We need to ensure that a release manager doesn't hit any bumps while working on this release step. - Denis On Fri, Mar 13, 2020 at 1:53 PM Mauricio Stekl wrote: > hi Denis, > Attached you can find a patch to add GA to all 2.8 and 2.7.x doc pages. > Also adds noindex to older versions. > > Please let me know if you have any questions. > > I will work on better instructions and probably some easier script to do > these changes. > > Best, > Mauricio > > > > > On Fri, Mar 13, 2020 at 1:23 PM Denis Magda wrote: > >> Mauricio, >> >> I've just spotted that all 2.8 API files (java, .net, etc.) miss the GA >> breadcrumbs. Most likely, this step of our release process was not fully >> completed: >> >> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-6.3.5.Updatereferencetodocsfromsite,SEOupdates >> >> Could you please step in and send a patch to resolve the issue? Plus, >> please help to update the existing instruction/script to a format that >> everyone could complete this step throughout a release. Presently, I failed >> to figure out how to make things working. >> >> - >> Denis >> >
[jira] [Created] (IGNITE-12785) KILL QUERY command doesn't support parameters
Nikolay Izhikov created IGNITE-12785:
Summary: KILL QUERY command doesn't support parameters
Key: IGNITE-12785
URL: https://issues.apache.org/jira/browse/IGNITE-12785
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Nikolay Izhikov
Ignite don't support parameter for KILL QUERY command.
SqlParser doesn't recognize parameter token.
{code:sql}
KILL QUERY ?
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Server Node comes down with : (err) Failed to notify listener: GridDhtTxPrepareFuture Error
Raised this jira : https://issues.apache.org/jira/browse/IGNITE-12784 Observed in 2.7.6. Unable to easily test in 2.8.0 because of other issues. One of them being - http://apache-ignite-users.70518.x6.nabble.com/2-8-0-JDBC-Thin-Client-Unable-to-load-the-tables-via-DBeaver-td31681.html Please note this happens -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
Veena - subscribe to the dev list before sending emails
Hello Veena, Our moderators' queue for the Ignite dev list is flooded with your emails. As suggested earlier, please subscribe to the dev list first and that will eliminate the need for all further moderation of your messages: https://ignite.apache.org/community/resources.html#mail-lists Also, this last message "Server Node comes down with : (err) Failed to notify listener: GridDhtTxPrepareFuture Error" that was added to the moderator list and needs to be forwarded to the user list instead. Please use the user list to report any issues or ask questions (dev list is used solely for Ignite development needs). Copying @dev to let other moderators know that you were updated on this matter. - Denis
[jira] [Created] (IGNITE-12784) Server Node comes down with : (err) Failed to notify listener: GridDhtTxPrepareFuture Error
Veena Mithare created IGNITE-12784: -- Summary: Server Node comes down with : (err) Failed to notify listener: GridDhtTxPrepareFuture Error Key: IGNITE-12784 URL: https://issues.apache.org/jira/browse/IGNITE-12784 Project: Ignite Issue Type: Bug Affects Versions: 2.7.6 Reporter: Veena Mithare We have a 3 node server cluster ( Issue observed in 2.7.6, could not test in 2.8.0 because I am unable to bring up the dbeaver in 2.8.0 with securityplugin enabled )([http://apache-ignite-users.70518.x6.nabble.com/2-8-0-JDBC-Thin-Client-Unable-to-load-the-tables-via-DBeaver-td31681.html]) A 4th node joins as a client with a continuous query on a Table A( Transaction_mode = transactional ). Now If I bring the client down and issue an update to the Table A within failureDetectionTimeout 3 , I get the following error and *this error* *brings the server down:* "(err) Failed to notify listener: GridDhtTxPrepareFuture Error" === Basically the server , tries to update the record on the Table A, and tries to notify Client since it had registered a continuous query for Table A. But since the Client Node has been brought down, it undeploys the remotefilterfactory lambda. Hence the server is no longer able to complete the transaction . */This also brings the server down./ * How can I resolve this issue ? === Please find the complete stack trace for this error : 2020-03-13 17:13:40,145 [sys-stripe-19-#20] ERROR [] - Critical system error detected. Will be handled accordingly to configured handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0, super=AbstractFailureHandler [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext [type=CRITICAL_ERROR, err=java.lang.NoClassDefFoundError: com/companyname/projectname/Module/helper/ContinuousQueryHelper]] java.lang.NoClassDefFoundError: com/companyname/projectname/Module/helper/ContinuousQueryHelper at com.companyname.projectname.Module.helper.ContinuousQueryHelper$ModuleTableRemoteFilterFactory$1.evaluate(ContinuousQueryHelper.java:289) ~[?:?] at org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.filter(CacheContinuousQueryHandler.java:833) ~[ignite-core-2.7.6.jar:2.7.6] at org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler$2.onEntryUpdated(CacheContinuousQueryHandler.java:422) ~[ignite-core-2.7.6.jar:2.7.6] at org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:426) ~[ignite-core-2.7.6.jar:2.7.6] at org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerSet(GridCacheMapEntry.java:1584) ~[ignite-core-2.7.6.jar:2.7.6] at org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:741) ~[ignite-core-2.7.6.jar:2.7.6] at org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.localFinish(GridNearTxLocal.java:3646) ~[ignite-core-2.7.6.jar:2.7.6] at org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:475) ~[ignite-core-2.7.6.jar:2.7.6] at org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:425) ~[ignite-core-2.7.6.jar:2.7.6] at org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$25.apply(GridNearTxLocal.java:3788) ~[ignite-core-2.7.6.jar:2.7.6] at org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$25.apply(GridNearTxLocal.java:3782) ~[ignite-core-2.7.6.jar:2.7.6] at org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:385) ~[ignite-core-2.7.6.jar:2.7.6] at org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:349) ~[ignite-core-2.7.6.jar:2.7.6] at org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:337) ~[ignite-core-2.7.6.jar:2.7.6] at org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:497) ~[ignite-core-2.7.6.jar:2.7.6] at org.apache.ignite.internal.processors.cache.GridCacheCompoundFuture.onDone(GridCacheCompoundFuture.java:56) ~[ignite-core-2.7.6.jar:2.7.6] at org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:476) ~[ignite-core-2.7.6.jar:2.7.6] at org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onComplete(GridNearOptimisticTxPrepareFuture.java:307) ~[ignite-core-2.7.6.jar:2.7.6] at
[jira] [Created] (IGNITE-12783) Partition state validation warnings erroneously logged when cache groups are used
Vyacheslav Koptilin created IGNITE-12783: Summary: Partition state validation warnings erroneously logged when cache groups are used Key: IGNITE-12783 URL: https://issues.apache.org/jira/browse/IGNITE-12783 Project: Ignite Issue Type: Bug Affects Versions: 2.8 Reporter: Vyacheslav Koptilin Assignee: Vyacheslav Koptilin Fix For: 2.9 -- This message was sent by Atlassian Jira (v8.3.4#803005)
Ignite website HTML files are not updated for 2.8 release
Mauricio, I've just spotted that all 2.8 API files (java, .net, etc.) miss the GA breadcrumbs. Most likely, this step of our release process was not fully completed: https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-6.3.5.Updatereferencetodocsfromsite,SEOupdates Could you please step in and send a patch to resolve the issue? Plus, please help to update the existing instruction/script to a format that everyone could complete this step throughout a release. Presently, I failed to figure out how to make things working. - Denis
Re: Re[4]: Text queries/indexes (GridLuceneIndex, @QueryTextFiled)
Ivan, I have made changes in the fork that reflects merge-sort strategy and now query future iterator unblocks as soon all first pages are delivered from nodes; then it waits for the next pages portions and so on. https://github.com/shuliga/ignite/commit/c84f04c18f67e99ab7bc0a7893b75f1dc83a76bd Please validate the design if you wish. Regarding ranking field in the entity. Entities for text queries in search domain are usually treated as documents with some metadata. This can be an id, issued/expired date, and document score returned for given query. It is common to include such fields in entity design. Answer to your question about omitting QueryRankField: - Then the response records just will come in arbitrary order. This should not fail TextQuery execution. Another point about rank value among different indices. - ranks are to be used for comparison between entities in praticular query response, they are not intended to be absolute over the system. Let me summarize the approaches: 1. Subclassing from Ranked.class. pros: the simplest and ignite-natural approach cons: implicit nature, limits entity inheritance 2. Explicitly Introducing dedicated field annotated @QueryRankField pros: ignite-natural approach, easy to introduce, explicitly controlled by developer cons: adds extra metadata to entity 3. Wrapping entity response with rank data, used for merge sort, not exposing it to client. pros: leaves entity design clean cons: rank is not available for client, development will require complex change in query execution / entity marshaling mechanisms I'd stay on p.2 as most balanced solution of these. What do you think? BR, Yuriy Shuliha ср, 11 бер. 2020 о 01:14 Ivan Pavlukhin пише: > Igniters, > > Not intentionally the discussion continued outside of dev list. I am > returning it back. You can find it below. Do not hesitate to join if you > have some thoughts on raised questions. May be you have ideas how to enrich > text query results with score/rank information. > > вт, 10 мар. 2020 г. в 09:11, Yuriy Shuliga : > > > Yes, please do. > > > > вт, 10 бер. 2020, 02:26 користувач Ivan Pavlukhin > > пише: > > > >> Yuriy, > >> > >> I noticed that from some point our discussion moved out of Ignite dev > >> list. Would you mind if I return it back to dev list? > >> > >> Best regards, > >> Ivan Pavlukhin > >> > >> вт, 10 мар. 2020 г. в 03:25, Ivan Pavlukhin : > >> > > >> > > PS As far as i see, the are no chance to get on 2.8 release train. > >> What will be the next version/date we can aim on with this update? > >> > > >> > Yes, 2.8 is already available and the community is working on > >> finalizing activities (e.g. publishing documentation). I do not have any > >> reliable expectations about next releases. I suppose that there could > be a > >> couple of maintenance releases like 2.8.1 as several problems were > already > >> discovered. I do not know whether next more significant release is > going to > >> be 2.9 even major release 3.0. It sounds realistic to facilitate 2.9 > >> because there are already several "almost ready" features in master. In > my > >> mind it is a good idea to start a discussion about next releases on dev > >> list. > >> > > >> > Best regards, > >> > Ivan Pavlukhin > >> > > >> > вт, 10 мар. 2020 г. в 00:58, Ivan Pavlukhin : > >> > > > >> > > Hi Yuriy, > >> > > > >> > > Sorry for a late response. > >> > > > >> > > > Suitable solution without subclassing might be: > >> > > > 1. Explicitly add float field to entity > >> > > > 2. Annotate it with special @QueryRankField, (for instance) > >> > > > 3. Fill in this field with docScore in GrlidLuceneindex, pass back > >> to initiating node > >> > > > 4. Possibly still need to proxify entity with adding Comparable > >> interface. > >> > > > 5. Perform merge sort on initiating node > >> > > > >> > > Possibly I missed it but one moment is not clear for me. What will > >> > > happen if an entity class does not have a field annotated with > >> > > QueryRankField? > >> > > > >> > > And I am still not sure that it is a proper (enough) approach. The > >> > > thing which bothers me is a transient and dynamic nature of "rank" > >> > > field. It does belong to entity, it can have different values for > the > >> > > same entity (e.g. different indices are used). > >> > > > >> > > I would like to experiment with a code a little bit. But most > likely I > >> > > will have a chance only at the end of this week. > >> > > > >> > > Best regards, > >> > > Ivan Pavlukhin > >> > > > >> > > пн, 2 мар. 2020 г. в 20:09, Yuriy Shuliga : > >> > > > > >> > > > Hi Ivan, > >> > > > > >> > > > Have concerns about entity annotation variant. > >> > > > Wrapping into dynamic proxy for passing back, will be quite a > >> complex thing that requires changes in IgniteCacheObjectProcessor > >> > > > and entity marshaling. > >> > > > > >> > > > Suitable solution without subclassing might be: > >> > > > 1. Explicitly add float field to entity > >> > > > 2. Annotate
[jira] [Created] (IGNITE-12782) [IEP-39] Interrupt service method executions on service cancel.
Nikolay Izhikov created IGNITE-12782: Summary: [IEP-39] Interrupt service method executions on service cancel. Key: IGNITE-12782 URL: https://issues.apache.org/jira/browse/IGNITE-12782 Project: Ignite Issue Type: Bug Affects Versions: 2.8 Environment: [ Reporter: Nikolay Izhikov Fix For: None Currently, service method execution not interrupted on service cancel. If some service has a buggy method that consumes server node resources cluster administrator can't stop invocation of this method. We should interrupt service method executions on service cancel. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Cache metrics on server nodes does not update correctly
Hi,
AI 2.7.6 doesn't contain a bug with aggregation of cache hits/misses.
I don't sure that described problem is related with IGNITE-3495 [1].
So it makes sense to file an issue.
[1] https://issues.apache.org/jira/browse/IGNITE-3495
On Thu, Mar 12, 2020 at 8:21 PM Dominik Przybysz wrote:
>
> Hi,
> I used ignite in version 2.7.6 (but I have also seen this behaviour on other
> 2.7.x versions) and there aren't any near or local cache.
> I expect that if I ask distributed cache about key which does not exist then
> the miss metric will be incremented.
>
>
> śr., 11 mar 2020 o 11:35 Andrey Gura napisał(a):
>>
>> Denis,
>>
>> I don't sure that I understand what is expected behavior should be.
>> There are local and aggregated cluster wide metrics. I don't know
>> which one used by Visor because I never used it :)
>>
>> Also it would be great to know what version of Apache Ignite used in
>> described case. I remember some bug with metrics aggregation during
>> discovery metrics message round trip.
>>
>> On Wed, Mar 11, 2020 at 12:05 AM Denis Magda wrote:
>> >
>> > @Nikolay Izhikov , @Andrey Gura ,
>> > could you folks check out this thread?
>> >
>> > I have a feeling that what Dominik is describing was talked out before and
>> > rather some sort of a limitation than an issue with the current
>> > implementation.
>> >
>> > -
>> > Denis
>> >
>> >
>> > On Tue, Mar 3, 2020 at 11:41 PM Dominik Przybysz
>> > wrote:
>> >
>> > > Hi,
>> > > I am trying to use partitioned cache on server nodes to which I connect
>> > > with client node. Statistics of cache in the cluster are updated, but
>> > > only
>> > > for hits metric - misses metric is always 0.
>> > >
>> > > To reproduce this problem I created cluster of two nodes:
>> > >
>> > > Server node 1 adds 100 random test cases and prints cache statistics
>> > > continuously:
>> > >
>> > > public class IgniteClusterNode1 {
>> > > public static void main(String[] args) throws InterruptedException {
>> > > IgniteConfiguration igniteConfiguration = new
>> > > IgniteConfiguration();
>> > >
>> > > CacheConfiguration cacheConfiguration = new CacheConfiguration();
>> > > cacheConfiguration.setName("test");
>> > > cacheConfiguration.setCacheMode(CacheMode.PARTITIONED);
>> > > cacheConfiguration.setAtomicityMode(CacheAtomicityMode.ATOMIC);
>> > > cacheConfiguration.setStatisticsEnabled(true);
>> > > igniteConfiguration.setCacheConfiguration(cacheConfiguration);
>> > >
>> > > TcpCommunicationSpi communicationSpi = new TcpCommunicationSpi();
>> > > communicationSpi.setLocalPort(47500);
>> > > igniteConfiguration.setCommunicationSpi(communicationSpi);
>> > >
>> > > TcpDiscoverySpi discoverySpi = new TcpDiscoverySpi();
>> > > discoverySpi.setLocalPort(47100);
>> > > discoverySpi.setLocalPortRange(100);
>> > > TcpDiscoveryVmIpFinder ipFinder = new TcpDiscoveryVmIpFinder();
>> > > ipFinder.setAddresses(Arrays.asList("127.0.0.1:47100..47200",
>> > > "127.0.0.1:48100..48200"));
>> > > igniteConfiguration.setDiscoverySpi(discoverySpi);
>> > >
>> > > try (Ignite ignite = Ignition.start(igniteConfiguration)) {
>> > > try (IgniteCache cache =
>> > > ignite.getOrCreateCache("test")) {
>> > > new Random().ints(1000).map(i -> Math.abs(i %
>> > > 1000)).distinct().limit(100).forEach(i -> {
>> > > String key = "data_" + i;
>> > > String value = UUID.randomUUID().toString();
>> > > cache.put(key, value);
>> > > }
>> > > );
>> > > }
>> > > while (true) {
>> > > System.out.println(ignite.cache("test").metrics());
>> > > Thread.sleep(5000);
>> > > }
>> > > }
>> > > }
>> > > }
>> > >
>> > > Server node 2 only prints cache statistics continuously:
>> > >
>> > > public class IgniteClusterNode2 {
>> > > public static void main(String[] args) throws InterruptedException {
>> > > IgniteConfiguration igniteConfiguration = new
>> > > IgniteConfiguration();
>> > >
>> > > CacheConfiguration cacheConfiguration = new CacheConfiguration();
>> > > cacheConfiguration.setName("test");
>> > > cacheConfiguration.setCacheMode(CacheMode.PARTITIONED);
>> > > cacheConfiguration.setStatisticsEnabled(true);
>> > > igniteConfiguration.setCacheConfiguration(cacheConfiguration);
>> > >
>> > > TcpCommunicationSpi communicationSpi = new TcpCommunicationSpi();
>> > > communicationSpi.setLocalPort(48500);
>> > > igniteConfiguration.setCommunicationSpi(communicationSpi);
>> > >
>> > > TcpDiscoverySpi discoverySpi = new TcpDiscoverySpi();
>> > > discoverySpi.setLocalPort(48100);
>> > > discoverySpi.setLocalPortRange(100);
>> > > TcpDiscoveryVmIpFinder
