[jira] [Created] (IGNITE-12838) Fails to start server with spring configuration with known host addresses
Ramya Magham created IGNITE-12838:
-
Summary: Fails to start server with spring configuration with
known host addresses
Key: IGNITE-12838
URL: https://issues.apache.org/jira/browse/IGNITE-12838
Project: Ignite
Issue Type: Bug
Components: cassandra, spring
Affects Versions: 2.8.1
Reporter: Ramya Magham
Fails to start server with spring configuration with known host addresses. I am
trying to start Ignite cluster from a java class but get the following error.
The version I am using is 2.8.0 ignite-core and ignite-cassandra-store.
{code:java}
Caused by: org.springframework.beans.NotWritablePropertyException: Invalid
property 'addresses' of bean class
[org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder]: Bean
property 'addresses' is not writable or has an invalid setter method. Does the
parameter type of the setter match the return type of the getter?Caused by:
org.springframework.beans.NotWritablePropertyException: Invalid property
'addresses' of bean class
[org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder]: Bean
property 'addresses' is not writable or has an invalid setter method. Does the
parameter type of the setter match the return type of the getter? at
org.springframework.beans.BeanWrapperImpl.createNotWritablePropertyException(BeanWrapperImpl.java:239){code}
The configuration looks like below:
{code:java}
http://www.springframework.org/schema/beans;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xmlns:util="http://www.springframework.org/schema/util;
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util.xsd;>
10.33.40.116:47500
10.33.40.117:47500
10.33.40.95:47500
...
..{code}
The class TcpDiscoveryVmIpFinder has setAddresses method but not a getter. Is
that the error it is throwing? Doesn't the class support to be able to
instantiate from the Spring config xml?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[MTCGA]: new failures in builds [5153180] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. If your changes can lead to this failure(s): We're grateful that you were a volunteer to make the contribution to this project, but things change and you may no longer be able to finalize your contribution. Could you respond to this email and indicate if you wish to continue and fix test failures or step down and some committer may revert you commit. *New stable failure of a flaky test in master WALRecordSerializationTest.testAllWalRecordsSerializedAndDeserializedSuccessfully https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3192056576753991319=%3Cdefault%3E=testDetails Changes may lead to failure were done by - ibessonov https://ci.ignite.apache.org/viewModification.html?modId=898974 - 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 01:22:26 26-03-2020
[MTCGA]: new failures in builds [5153197] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. If your changes can lead to this failure(s): We're grateful that you were a volunteer to make the contribution to this project, but things change and you may no longer be able to finalize your contribution. Could you respond to this email and indicate if you wish to continue and fix test failures or step down and some committer may revert you commit. *New test failure in master-nightly WALRecordSerializationTest.testAllWalRecordsSerializedAndDeserializedSuccessfully https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7661388890479089957=%3Cdefault%3E=testDetails Changes may lead to failure were done by - ibessonov https://ci.ignite.apache.org/viewModification.html?modId=898974 - nikolay https://ci.ignite.apache.org/viewModification.html?modId=898971 - 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 23:22:26 25-03-2020
Re: Thin client: compute support
Pavel, 1. Actually it can be solved on the client-side (and already solved in PoC implementation). But I agreed it brings extra complexity for client-side implementation, will try to provide such guarantees on the server-side. 2. ComputeTask has also "reduce" step which is executed on the initiator node. Binary-rest client implementation, for example, has such affinity methods (to execute the task by name). I'm ok with removing it. At least if someone will need it we can implement it again at any time in the future without protocol change. I've fixed IEP. Denis, Deployment API definitely needed as one of the next steps. Currently, we are talking only about the first step (execution of already deployed tasks). Also, I'm not sure about automatic redeploy and peer-class-loading for thin clients, I think it's better to have more control here and provide API to explicitly deploy classes or jar files. WDYT? ср, 25 мар. 2020 г. в 21:17, Denis Magda : > Alex, thanks for preparing the outline. > > I'd like us to discuss an approach for compute tasks update with no > downtimes on the servers' end. For instance, let's assume that a > Python/C++/Node.JS developer requested to update a compute task he called > from the app. Should we introduce some system level API to the binary > protocol that can take a jar file (or class) and redeploy it automatically > with the usage of peer-class-loading? > > - > Denis > > > On Wed, Mar 25, 2020 at 5:47 AM Alex Plehanov > wrote: > > > Hello guys. > > > > I've implemented PoC and created IEP [1] for thin client compute grid > > functionality. Please have a look. > > > > [1]: > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-42+Thin+client%3A+compute+support > > > > пт, 24 янв. 2020 г. в 16:56, Alex Plehanov : > > > > > We've discussed thin client compute protocol with Pavel Tupitsyn and > Igor > > > Sapego and come to the conclusion that approach with two-way requests > > > should be used: client generates taskId and send a request to the > server > > to > > > execute a task. The server responds that the request has been accepted. > > > After task has finished the server notifies the client (send a request > > > without waiting for a response). The client can cancel the task by > > sending > > > a corresponding request to the server. > > > > > > Also, a node list should be passed (optionally) with a request to limit > > > nodes to execute the task. > > > > > > I will create IEP and file detailed protocol changes shortly. > > > > > > вт, 21 янв. 2020 г. в 18:46, Alex Plehanov : > > > > > >> Igor, thanks for the reply. > > >> > > >> > Approach with taskId will require a lot of changes in protocol and > > thus > > >> more "heavy" for implementation > > >> Do you mean approach with server notifications mechanism? Yes, it will > > >> require a lot of changes. But in most recent messages we've discussed > > with > > >> Pavel approach without server notifications mechanism. This approach > > have > > >> the same complexity and performance as an approach with requestId. > > >> > > >> > But such clients as Python, Node.js, PHP, Go most probably won't > have > > >> support for this API, at least for now. > > >> Without a server notifications mechanism, there will be no breaking > > >> changes in the protocol, so client implementation can just skip this > > >> feature and protocol version and implement the next one. > > >> > > >> > Or never. > > >> I think it still useful to execute java compute tasks from non-java > thin > > >> clients. Also, we can provide some out-of-the-box java tasks, for > > example > > >> ExecutePythonScriptTask with python compute implementation, which can > > run > > >> python script on server node. > > >> > > >> > So, maybe it's a good time for us to change our backward > compatibility > > >> mechanism from protocol versioning to feature masks? > > >> I like the idea with feature masks, but it will force us to support > both > > >> backward compatibility mechanisms, protocol versioning and feature > > masks. > > >> > > >> пн, 20 янв. 2020 г. в 20:34, Pavel Tupitsyn : > > >> > > >>> Huge +1 from me for Feature Masks. > > >>> I think this should be our top priority for thin client protocol, > since > > >>> it > > >>> simplifies change management a lot. > > >>> > > >>> On Mon, Jan 20, 2020 at 8:21 PM Igor Sapego > > wrote: > > >>> > > >>> > Sorry for the late reply. > > >>> > > > >>> > Approach with taskId will require a lot of changes in protocol and > > thus > > >>> > more "heavy" for implementation, but it definitely looks to me less > > >>> hacky > > >>> > than reqId-approach. Moreover, as was mentioned, server > notifications > > >>> > mechanism will be required in a future anyway with high > probability. > > So > > >>> > from this point of view I like taskId-approach. > > >>> > > > >>> > On the other hand, what we should also consider here is > performance. > > >>> > Speaking of latency, it looks like reqId will have better results > in > >
Re: Thin client: compute support
Alex, thanks for preparing the outline. I'd like us to discuss an approach for compute tasks update with no downtimes on the servers' end. For instance, let's assume that a Python/C++/Node.JS developer requested to update a compute task he called from the app. Should we introduce some system level API to the binary protocol that can take a jar file (or class) and redeploy it automatically with the usage of peer-class-loading? - Denis On Wed, Mar 25, 2020 at 5:47 AM Alex Plehanov wrote: > Hello guys. > > I've implemented PoC and created IEP [1] for thin client compute grid > functionality. Please have a look. > > [1]: > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-42+Thin+client%3A+compute+support > > пт, 24 янв. 2020 г. в 16:56, Alex Plehanov : > > > We've discussed thin client compute protocol with Pavel Tupitsyn and Igor > > Sapego and come to the conclusion that approach with two-way requests > > should be used: client generates taskId and send a request to the server > to > > execute a task. The server responds that the request has been accepted. > > After task has finished the server notifies the client (send a request > > without waiting for a response). The client can cancel the task by > sending > > a corresponding request to the server. > > > > Also, a node list should be passed (optionally) with a request to limit > > nodes to execute the task. > > > > I will create IEP and file detailed protocol changes shortly. > > > > вт, 21 янв. 2020 г. в 18:46, Alex Plehanov : > > > >> Igor, thanks for the reply. > >> > >> > Approach with taskId will require a lot of changes in protocol and > thus > >> more "heavy" for implementation > >> Do you mean approach with server notifications mechanism? Yes, it will > >> require a lot of changes. But in most recent messages we've discussed > with > >> Pavel approach without server notifications mechanism. This approach > have > >> the same complexity and performance as an approach with requestId. > >> > >> > But such clients as Python, Node.js, PHP, Go most probably won't have > >> support for this API, at least for now. > >> Without a server notifications mechanism, there will be no breaking > >> changes in the protocol, so client implementation can just skip this > >> feature and protocol version and implement the next one. > >> > >> > Or never. > >> I think it still useful to execute java compute tasks from non-java thin > >> clients. Also, we can provide some out-of-the-box java tasks, for > example > >> ExecutePythonScriptTask with python compute implementation, which can > run > >> python script on server node. > >> > >> > So, maybe it's a good time for us to change our backward compatibility > >> mechanism from protocol versioning to feature masks? > >> I like the idea with feature masks, but it will force us to support both > >> backward compatibility mechanisms, protocol versioning and feature > masks. > >> > >> пн, 20 янв. 2020 г. в 20:34, Pavel Tupitsyn : > >> > >>> Huge +1 from me for Feature Masks. > >>> I think this should be our top priority for thin client protocol, since > >>> it > >>> simplifies change management a lot. > >>> > >>> On Mon, Jan 20, 2020 at 8:21 PM Igor Sapego > wrote: > >>> > >>> > Sorry for the late reply. > >>> > > >>> > Approach with taskId will require a lot of changes in protocol and > thus > >>> > more "heavy" for implementation, but it definitely looks to me less > >>> hacky > >>> > than reqId-approach. Moreover, as was mentioned, server notifications > >>> > mechanism will be required in a future anyway with high probability. > So > >>> > from this point of view I like taskId-approach. > >>> > > >>> > On the other hand, what we should also consider here is performance. > >>> > Speaking of latency, it looks like reqId will have better results in > >>> case > >>> > of > >>> > small and fast tasks. The only question here, if we want to optimize > >>> thin > >>> > clients for this case. > >>> > > >>> > Also, what are you talking about mostly involves clients on platforms > >>> > that already have Compute API for thick clients. Let me mention one > >>> > more point of view here and another concern here. > >>> > > >>> > The changes you propose are going to change protocol version for > sure. > >>> > In case with taskId approach and server notifications - even more so. > >>> > > >>> > But such clients as Python, Node.js, PHP, Go most probably won't have > >>> > support for this API, at least for now. Or never. But current > >>> > backward-compatibility mechanism implies protocol versions where we > >>> > imply that client that supports version 1.5 also supports all the > >>> features > >>> > introduced in all the previous versions of the protocol. > >>> > > >>> > Thus implementing Compute API in any of the proposed ways *may* > >>> > force mentioned clients to support changes in protocol which they not > >>> > necessarily need in order to introduce new features in the future. > >>> > > >>> > So, maybe it's a
Re: Thin client: compute support
Hi Alex, First of all, thank you for preparing this IEP! Protocol changes look good to me. However, I have objections regarding race condition behavior and about Java API. 1. "Due to some races, it's possible that notification for some task will be delivered to the client before the response for this task is delivered. Client implementation should be ready to process such cases" I don't think this is acceptable. Client must never receive OP_COMPUTE_TASK_FINISHED notification before OP_COMPUTE_TASK_EXECUTE response, because there is no way to correlate task result with the task itself this way. 2. affinityExecute Does not make sense to me, and not consistent with Thick Compute API, where we have affinityRun/affinityCall instead. Compute API implies that heavy lifting is inside ComputeJob, so it does not matter where ComputeTask is executed, because jobs are mapped to other nodes. Pavel On Wed, Mar 25, 2020 at 3:47 PM Alex Plehanov wrote: > Hello guys. > > I've implemented PoC and created IEP [1] for thin client compute grid > functionality. Please have a look. > > [1]: > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-42+Thin+client%3A+compute+support > > пт, 24 янв. 2020 г. в 16:56, Alex Plehanov : > > > We've discussed thin client compute protocol with Pavel Tupitsyn and Igor > > Sapego and come to the conclusion that approach with two-way requests > > should be used: client generates taskId and send a request to the server > to > > execute a task. The server responds that the request has been accepted. > > After task has finished the server notifies the client (send a request > > without waiting for a response). The client can cancel the task by > sending > > a corresponding request to the server. > > > > Also, a node list should be passed (optionally) with a request to limit > > nodes to execute the task. > > > > I will create IEP and file detailed protocol changes shortly. > > > > вт, 21 янв. 2020 г. в 18:46, Alex Plehanov : > > > >> Igor, thanks for the reply. > >> > >> > Approach with taskId will require a lot of changes in protocol and > thus > >> more "heavy" for implementation > >> Do you mean approach with server notifications mechanism? Yes, it will > >> require a lot of changes. But in most recent messages we've discussed > with > >> Pavel approach without server notifications mechanism. This approach > have > >> the same complexity and performance as an approach with requestId. > >> > >> > But such clients as Python, Node.js, PHP, Go most probably won't have > >> support for this API, at least for now. > >> Without a server notifications mechanism, there will be no breaking > >> changes in the protocol, so client implementation can just skip this > >> feature and protocol version and implement the next one. > >> > >> > Or never. > >> I think it still useful to execute java compute tasks from non-java thin > >> clients. Also, we can provide some out-of-the-box java tasks, for > example > >> ExecutePythonScriptTask with python compute implementation, which can > run > >> python script on server node. > >> > >> > So, maybe it's a good time for us to change our backward compatibility > >> mechanism from protocol versioning to feature masks? > >> I like the idea with feature masks, but it will force us to support both > >> backward compatibility mechanisms, protocol versioning and feature > masks. > >> > >> пн, 20 янв. 2020 г. в 20:34, Pavel Tupitsyn : > >> > >>> Huge +1 from me for Feature Masks. > >>> I think this should be our top priority for thin client protocol, since > >>> it > >>> simplifies change management a lot. > >>> > >>> On Mon, Jan 20, 2020 at 8:21 PM Igor Sapego > wrote: > >>> > >>> > Sorry for the late reply. > >>> > > >>> > Approach with taskId will require a lot of changes in protocol and > thus > >>> > more "heavy" for implementation, but it definitely looks to me less > >>> hacky > >>> > than reqId-approach. Moreover, as was mentioned, server notifications > >>> > mechanism will be required in a future anyway with high probability. > So > >>> > from this point of view I like taskId-approach. > >>> > > >>> > On the other hand, what we should also consider here is performance. > >>> > Speaking of latency, it looks like reqId will have better results in > >>> case > >>> > of > >>> > small and fast tasks. The only question here, if we want to optimize > >>> thin > >>> > clients for this case. > >>> > > >>> > Also, what are you talking about mostly involves clients on platforms > >>> > that already have Compute API for thick clients. Let me mention one > >>> > more point of view here and another concern here. > >>> > > >>> > The changes you propose are going to change protocol version for > sure. > >>> > In case with taskId approach and server notifications - even more so. > >>> > > >>> > But such clients as Python, Node.js, PHP, Go most probably won't have > >>> > support for this API, at least for now. Or never. But current > >>> > backward-compatibility
Per-cache CACHE_CREATE/CACHE_DESTROY permissions handling
Hi, Igniters! Long ago I raised the issue [1]. The change is obvious yet useful; it allows Ignite security implementations to manage per-cache-based CACHE_CREATE/CACHE_DESTROY permissions (as opposed to system level permissions). It is ready now, and some of community members have approved it. Who could make final review, please? [1] https://issues.apache.org/jira/browse/IGNITE-12220 -- Best regards, Andrey Kuznetsov.
Re: Change Ignite download.cgi page to satisfy requirements
Hi Maxim, Here is a ticket [1] where I've collected INFRA recommendations shared in an adjacent discussion thread. Please check it, add anything new you heard from them. Feel free to take over this task, appreciate your help. However, please give me a couple of days to finish the merge of the new website to the master branch. After that, you can update the downloads page and I'll request INFRA to move the website to a Git repository. I'll send a note here once the new website is released. [1] https://issues.apache.org/jira/browse/IGNITE-12775 - Denis On Wed, Mar 25, 2020 at 3:31 AM Maxim Muzafarov wrote: > Igniters, > > > I've recently found that some of our releases were missed at the > Apache announce mail list: 2.6.0 [4], 2.7.0 [5], 2.8.0 [3]. > > I've contacted the Apache announce list moderators and got the > requirements for our download page [6] (see the message below). I'm > going to update the download page on the Apache Ignite website > according to received instructions using these pages as an example [1] > [2]. > > WDYT? > > > Denis, > > Do we have maintainer here or I can proceed with this by myself? > > > > > > > Sorry, but the download page does not meet the requirements. > > 1) There is no link to the KEYS file > https://downloads.apache.org/ignite/KEYS > This is necessary for validating downloaded artifacts > > 2) No description of how to validate downloads > > 3) There is a link to nightly builds. > That is not allowed on a public download page, as the builds have not been > voted on. > > 4) The paragraph introducing the binary artifact says: > > "In order to verify the release, we recommend that you download the > official source distribution and verify the signatures of the downloaded > files before opening them." > > This does not make sense in the binary section (it belongs in the source > section and/or needs rewording). > Nor is there any description of how to perform the verification. > > Please correct the page and resubmit the announce when that has been done. > > < < > > [1] https://tika.apache.org/download.html > [2] http://tomcat.apache.org/download-70.cgi > [3] > http://mail-archives.us.apache.org/mod_mbox/www-announce/202003.mbox/browser > [4] > http://mail-archives.us.apache.org/mod_mbox/www-announce/201806.mbox/browser > [5] > http://mail-archives.us.apache.org/mod_mbox/www-announce/201812.mbox/browser > [6] https://ignite.apache.org/download.cgi >
[jira] [Created] (IGNITE-12837) Make sure Ignite leaves nothing in static fields after node is stopped, write test
Ilya Kasnacheev created IGNITE-12837:
Summary: Make sure Ignite leaves nothing in static fields after
node is stopped, write test
Key: IGNITE-12837
URL: https://issues.apache.org/jira/browse/IGNITE-12837
Project: Ignite
Issue Type: Improvement
Components: general
Reporter: Ilya Kasnacheev
{code}
There are at least two way link to IgniteKernal leaks to GC root and makes it
unavailable for GC.
1. The first one:
this - value: org.apache.ignite.internal.IgniteKernal #1
<\- grid - class: org.apache.ignite.internal.GridKernalContextImpl, value:
org.apache.ignite.internal.IgniteKernal #1
<\- ctx - class:
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing, value:
org.apache.ignite.internal.GridKernalContextImpl #2
<\- this$0 - class:
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$10, value:
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing #2
<\- serializer - class: org.h2.util.JdbcUtils, value:
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$10 #1
<\- [5395] - class: java.lang.Object[], value: org.h2.util.JdbcUtils class
JdbcUtils
<\- elementData - class: java.util.Vector, value: java.lang.Object[] #37309
<\- classes - class: sun.misc.Launcher$AppClassLoader, value: java.util.Vector
#31
<\- contextClassLoader (thread object) - class: java.lang.Thread, value:
sun.misc.Launcher$AppClassLoader #1
org.h2.util.JdbcUtils has static field JavaObjectSerializer serializer, which
see IgniteKernal via IgniteH2Indexing. It make closed and stopped IgniteKernal
non collectable by GC.
If some Ignites run in same JVM, JdbcUtils will always use only one, and it
can cause some races.
2. The second way:
this - value: org.apache.ignite.internal.IgniteKernal #2
<\- grid - class: org.apache.ignite.internal.GridKernalContextImpl, value:
org.apache.ignite.internal.IgniteKernal #2
<\- ctx - class: org.apache.ignite.internal.processors.cache.GridCacheContext,
value: org.apache.ignite.internal.GridKernalContextImpl #1
<\- cctx - class:
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry,
value: org.apache.ignite.internal.processors.cache.GridCacheContext #24
<\- parent - class:
org.apache.ignite.internal.processors.cache.GridCacheMvccCandidate, value:
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry
#4
<\- [0] - class: java.lang.Object[], value:
org.apache.ignite.internal.processors.cache.GridCacheMvccCandidate #1
<\- elements - class: java.util.ArrayDeque, value: java.lang.Object[] #43259
<\- value - class: java.lang.ThreadLocal$ThreadLocalMap$Entry, value:
java.util.ArrayDeque #816
<\- [119] - class: java.lang.ThreadLocal$ThreadLocalMap$Entry[], value:
java.lang.ThreadLocal$ThreadLocalMap$Entry #51
<\- table - class: java.lang.ThreadLocal$ThreadLocalMap, value:
java.lang.ThreadLocal$ThreadLocalMap$Entry[] #21
<\- threadLocals (thread object) - class: java.lang.Thread, value:
java.lang.ThreadLocal$ThreadLocalMap #2
{code}
as reported on mailing list.
I suggest we fix that (make sure Ignite node leaves nothing in static fields/GC
roots after it is stopped). I also suggest we introduce a check, probably by
using jmap and searching dump for IgniteKernal, etc.
It would also be nice to check that if Ignite is loaded to non-root class
loader, started and stopped, it would allow this class-loader to unload Ignite
classes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Thin client: compute support
Hello guys. I've implemented PoC and created IEP [1] for thin client compute grid functionality. Please have a look. [1]: https://cwiki.apache.org/confluence/display/IGNITE/IEP-42+Thin+client%3A+compute+support пт, 24 янв. 2020 г. в 16:56, Alex Plehanov : > We've discussed thin client compute protocol with Pavel Tupitsyn and Igor > Sapego and come to the conclusion that approach with two-way requests > should be used: client generates taskId and send a request to the server to > execute a task. The server responds that the request has been accepted. > After task has finished the server notifies the client (send a request > without waiting for a response). The client can cancel the task by sending > a corresponding request to the server. > > Also, a node list should be passed (optionally) with a request to limit > nodes to execute the task. > > I will create IEP and file detailed protocol changes shortly. > > вт, 21 янв. 2020 г. в 18:46, Alex Plehanov : > >> Igor, thanks for the reply. >> >> > Approach with taskId will require a lot of changes in protocol and thus >> more "heavy" for implementation >> Do you mean approach with server notifications mechanism? Yes, it will >> require a lot of changes. But in most recent messages we've discussed with >> Pavel approach without server notifications mechanism. This approach have >> the same complexity and performance as an approach with requestId. >> >> > But such clients as Python, Node.js, PHP, Go most probably won't have >> support for this API, at least for now. >> Without a server notifications mechanism, there will be no breaking >> changes in the protocol, so client implementation can just skip this >> feature and protocol version and implement the next one. >> >> > Or never. >> I think it still useful to execute java compute tasks from non-java thin >> clients. Also, we can provide some out-of-the-box java tasks, for example >> ExecutePythonScriptTask with python compute implementation, which can run >> python script on server node. >> >> > So, maybe it's a good time for us to change our backward compatibility >> mechanism from protocol versioning to feature masks? >> I like the idea with feature masks, but it will force us to support both >> backward compatibility mechanisms, protocol versioning and feature masks. >> >> пн, 20 янв. 2020 г. в 20:34, Pavel Tupitsyn : >> >>> Huge +1 from me for Feature Masks. >>> I think this should be our top priority for thin client protocol, since >>> it >>> simplifies change management a lot. >>> >>> On Mon, Jan 20, 2020 at 8:21 PM Igor Sapego wrote: >>> >>> > Sorry for the late reply. >>> > >>> > Approach with taskId will require a lot of changes in protocol and thus >>> > more "heavy" for implementation, but it definitely looks to me less >>> hacky >>> > than reqId-approach. Moreover, as was mentioned, server notifications >>> > mechanism will be required in a future anyway with high probability. So >>> > from this point of view I like taskId-approach. >>> > >>> > On the other hand, what we should also consider here is performance. >>> > Speaking of latency, it looks like reqId will have better results in >>> case >>> > of >>> > small and fast tasks. The only question here, if we want to optimize >>> thin >>> > clients for this case. >>> > >>> > Also, what are you talking about mostly involves clients on platforms >>> > that already have Compute API for thick clients. Let me mention one >>> > more point of view here and another concern here. >>> > >>> > The changes you propose are going to change protocol version for sure. >>> > In case with taskId approach and server notifications - even more so. >>> > >>> > But such clients as Python, Node.js, PHP, Go most probably won't have >>> > support for this API, at least for now. Or never. But current >>> > backward-compatibility mechanism implies protocol versions where we >>> > imply that client that supports version 1.5 also supports all the >>> features >>> > introduced in all the previous versions of the protocol. >>> > >>> > Thus implementing Compute API in any of the proposed ways *may* >>> > force mentioned clients to support changes in protocol which they not >>> > necessarily need in order to introduce new features in the future. >>> > >>> > So, maybe it's a good time for us to change our backward compatibility >>> > mechanism from protocol versioning to feature masks? >>> > >>> > WDYT? >>> > >>> > Best Regards, >>> > Igor >>> > >>> > >>> > On Fri, Jan 17, 2020 at 9:37 AM Alex Plehanov >> > >>> > wrote: >>> > >>> > > Looks like we didn't rich consensus here. >>> > > >>> > > Igor, as thin client maintainer, can you please share your opinion? >>> > > >>> > > Everyone else also welcome, please share your thoughts about options >>> to >>> > > implement operations for compute. >>> > > >>> > > >>> > > чт, 28 нояб. 2019 г. в 10:02, Alex Plehanov >> >: >>> > > >>> > > > > Since all thin client operations are inherently async, we should >>> be >>> > > able >>> > > >
[jira] [Created] (IGNITE-12836) Writing methods to avoid limit of 65535 bytes for java.io.DataOutput#writeUTF
Kirill Tkalenko created IGNITE-12836: Summary: Writing methods to avoid limit of 65535 bytes for java.io.DataOutput#writeUTF Key: IGNITE-12836 URL: https://issues.apache.org/jira/browse/IGNITE-12836 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Assignee: Kirill Tkalenko -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12835) Thin client: compute support
Aleksey Plekhanov created IGNITE-12835: -- Summary: Thin client: compute support Key: IGNITE-12835 URL: https://issues.apache.org/jira/browse/IGNITE-12835 Project: Ignite Issue Type: New Feature Components: thin client Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Add compute grid functionality to thin clients. As a first step execution of task by task name should be added. Implement a compute facade in java thin client. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Change Ignite download.cgi page to satisfy requirements
Igniters, I've recently found that some of our releases were missed at the Apache announce mail list: 2.6.0 [4], 2.7.0 [5], 2.8.0 [3]. I've contacted the Apache announce list moderators and got the requirements for our download page [6] (see the message below). I'm going to update the download page on the Apache Ignite website according to received instructions using these pages as an example [1] [2]. WDYT? Denis, Do we have maintainer here or I can proceed with this by myself? > > Sorry, but the download page does not meet the requirements. 1) There is no link to the KEYS file https://downloads.apache.org/ignite/KEYS This is necessary for validating downloaded artifacts 2) No description of how to validate downloads 3) There is a link to nightly builds. That is not allowed on a public download page, as the builds have not been voted on. 4) The paragraph introducing the binary artifact says: "In order to verify the release, we recommend that you download the official source distribution and verify the signatures of the downloaded files before opening them." This does not make sense in the binary section (it belongs in the source section and/or needs rewording). Nor is there any description of how to perform the verification. Please correct the page and resubmit the announce when that has been done. < < [1] https://tika.apache.org/download.html [2] http://tomcat.apache.org/download-70.cgi [3] http://mail-archives.us.apache.org/mod_mbox/www-announce/202003.mbox/browser [4] http://mail-archives.us.apache.org/mod_mbox/www-announce/201806.mbox/browser [5] http://mail-archives.us.apache.org/mod_mbox/www-announce/201812.mbox/browser [6] https://ignite.apache.org/download.cgi
