[MTCGA]: new failures in builds [6494600] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. *Test with high flaky rate in master TcpDiscoverySslParametersTest.testOneCommonProtocol https://ci2.ignite.apache.org/test/5096844946511650792?currentProjectId=IgniteTests24Java8=%3Cdefault%3E 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 03:23:20 29-06-2022
Re: [DISCUSS] Ignite service interceptor.
Hello Pavel,
The IEP looks good to me in general. It is a good addition to the service
API.
One suggestion is to improve control over service method execution within
the interceptor:
1. Bypass service call without throwing an exception.
2. Convert service call result in some way
This can be achieved by a different interface, with a single method:
public interface ServiceCallInterceptor extends Serializable {
public default Object onInvoke(Supplier delegate, String mtd, Object[]
args, ServiceContext ctx) throws ServiceInterceptException {
return delegate.get();
}
}
which can be implemented like this:
public class MyInterceptor implements ServiceCallInterceptor {
@Override
public Object onInvoke(Supplier delegate, String mtd, Object[] args,
ServiceContext ctx) throws Exception {
AuditProvider.get().recordStartEvent(mtd,
ctx.currentCallContext().attribute("sessionId"));
try {
if (!checkAuthorization(ctx))
return notAuthorizedResult();
Object value = delegate.get();
return convert(value);
}
catch (Exception e) {
// Log error
return errorResult(...);
}
finally {
AuditProvider.get().recordEndEvent(mtd,
ctx.currentCallContext().attribute("sessionId"));
}
}
}
As you can see, this way the user has full control over all aspects of the
service call.
Thoughts?
On Tue, Jun 28, 2022 at 6:33 PM Pavel Pereslegin wrote:
> Hello Igniters!
>
> I want to continue discussing a feature that allows users to create
> their own middleware for Ignite services [1].
> Earlier was added the ability to implicitly pass a set of user
> parameters (ServiceCallContext) to the service [2].
> This feature allows users to track the origin of a service call.
> Now I'd like to add a service call interceptor to allow the user to
> separate the "middleware" logic from the business code and reduce
> boilerplate code [3].
>
> I've prepared an IEP for this feature, please take a look [4].
> I will prepare patches for Java and .NET for this feature soon.
>
> [1] https://lists.apache.org/thread/wqlvskxr0fvdo6rbo64bnct4zz53kpr0
> [2] https://issues.apache.org/jira/browse/IGNITE-15572
> [3] https://issues.apache.org/jira/browse/IGNITE-17022
> [4]
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191334119
>
[DISCUSS] Ignite service interceptor.
Hello Igniters! I want to continue discussing a feature that allows users to create their own middleware for Ignite services [1]. Earlier was added the ability to implicitly pass a set of user parameters (ServiceCallContext) to the service [2]. This feature allows users to track the origin of a service call. Now I'd like to add a service call interceptor to allow the user to separate the "middleware" logic from the business code and reduce boilerplate code [3]. I've prepared an IEP for this feature, please take a look [4]. I will prepare patches for Java and .NET for this feature soon. [1] https://lists.apache.org/thread/wqlvskxr0fvdo6rbo64bnct4zz53kpr0 [2] https://issues.apache.org/jira/browse/IGNITE-15572 [3] https://issues.apache.org/jira/browse/IGNITE-17022 [4] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191334119
Re: I want to contribute to Apache ignite
Hi, you already have contributor permissions (JIRA username is wkhapy123123): https://lists.apache.org/thread/g2hlllxo7232yw1qh9wkhjrkf8mocc9j On Tue, Jun 28, 2022 at 2:36 PM wkhapy...@gmail.com wrote: > Hi, > > I want to contribute to Apache ignite . > > Would you please give me the contributor permission? > below is my account > > -- > wkhapy...@gmail.com >
I want to contribute to Apache ignite
Hi, I want to contribute to Apache ignite . Would you please give me the contributor permission? below is my account wkhapy...@gmail.com
Re: [MTCGA]: new failures in builds [6497895] needs to be handled
Filed a ticket for Thin Client project timeouts. I'm on it. testValidInvalidNodeAddressesMix test hangs, this happened before too, so not related to Mikhail's changes. https://issues.apache.org/jira/browse/IGNITE-17247 On Tue, Jun 28, 2022 at 8:53 AM wrote: > 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 Critical Failure in master Thin Client: Java > https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ThinClientJava?branch=%3Cdefault%3E > Changes may lead to failure were done by > - mikhail petrov <32207922+ololo3...@users.noreply.github.com> > https://ci2.ignite.apache.org/viewModification.html?modId=974885 > > - 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 05:53:21 28-06-2022 >
Re: IEP-90 Ignite 3 Client Lifecycle
Igor, ok, agreed. On Mon, Jun 27, 2022 at 11:27 PM Igor Sapego wrote: > Pavel, let's postpone developing a sessions part until all the corner cases > are clarified. I'll let you know when new the proposal is ready for > discussion > again. > > Best Regards, > Igor > > > On Mon, May 23, 2022 at 12:25 PM Andrey Gura wrote: > > > Thanks for the answers, Igor. > > > > On Thu, May 19, 2022 at 10:55 PM Igor Sapego wrote: > > > > > > Andrey, > > > > > > 1. If a server generates a UUID that already exists it can check and > just > > > re-generate it straight away > > > as a check is just a simple map lookup. > > > > > > 2. Well, yes. This proposal does not consider monitoring, but with > > current > > > approach it will be definitely > > > easier to implement it properly. > > > > > > Pavel, > > > > > > Wow, that's really cool that you've already started working on it. > > > > > > Regarding your proposal I like it - it will really make a procedure > > easier > > > and faster for a client. I'll change > > > the IEP accordingly. > > > > > > Best Regards, > > > Igor > > > > > > > > > On Thu, May 19, 2022 at 11:40 PM Pavel Tupitsyn > > > wrote: > > > > > > > Igor, > > > > > > > > I've started working on the initial sessions implementation [1], > > > > and I'd like to clarify the procedure of logical connection restore. > > > > > > > > > client in its turn tries to establish a new *node connection* > > > > > and restore *logical connection *using ConnectionRestoreReq > > > > > > > > This implies either an additional request, or something that replaces > > > > normal handshake. > > > > However, we need to handle two cases here: > > > > - Logical connection is restored > > > > - Logical connection is not restored (timed out, server restarted, > > etc), in > > > > which case we still establish the connection and use it. > > > > > > > > To account for the second case, we should always start with a regular > > > > handshake. > > > > I propose to add a nullable UUID field to the handshake request to > > cover > > > > both cases: > > > > - connectionId is null or not found on server: proceed with normal > > > > handshake, return newly generated connectionId. > > > > - connectionId is not null and found on server: restore logical > > connection, > > > > return the same connectionId > > > > > > > > Client checks if returned connectionId equals to the original and > > > > understands whether logical connection was restored or not. > > > > > > > > Thoughts? > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-16928 > > > > > > > > On Thu, May 19, 2022 at 10:27 PM Pavel Tupitsyn < > ptupit...@apache.org> > > > > wrote: > > > > > > > > > Andrey, > > > > > > > > > > > different connections on different client instances theoretically > > > > > > could generate an already existing connection ID > > > > > > > > > > Do you mean an UUID collision? > > > > > > > > > > On Thu, May 19, 2022 at 1:09 AM Andrey Gura > > wrote: > > > > > > > > > >> Igor, > > > > >> > > > > >> Thanks for the proposal. > > > > >> > > > > >> I understand that such a situation is almost impossible but "if > > > > >> anything can go wrong, it will". Does the protocol take into > account > > > > >> that different connections on different client instances > > theoretically > > > > >> could generate an already existing connection ID? > > > > >> > > > > >> Also, do I understand correctly that a server has enough > information > > > > >> about client connections so it will be possible to observe a > > > > >> connections list on the server? It would be useful for cluster > > > > >> monitoring purposes. > > > > >> > > > > >> On Tue, May 17, 2022 at 3:11 PM Igor Sapego > > wrote: > > > > >> > > > > > >> > 1. I've tried to clarify IDs part; > > > > >> > 2. Maybe you are right, though in this case we'd need to use > > > > >> authentication > > > > >> > in ConnectionRestoreReq. Which sounds reasonable to me. > > > > >> > > > > > >> > Best Regards, > > > > >> > Igor > > > > >> > > > > > >> > > > > > >> > On Tue, May 17, 2022 at 10:47 AM Pavel Tupitsyn < > > ptupit...@apache.org > > > > > > > > > >> > wrote: > > > > >> > > > > > >> > > Igor, > > > > >> > > > > > > >> > > The proposal looks good to me. Very detailed! > > > > >> > > > > > > >> > > A couple comments: > > > > >> > > > > > > >> > > 1. There is a bit of a term mixup with "Connection ID", "Node > > ID", > > > > >> "Token" > > > > >> > > - can you please review those? > > > > >> > > > > > > >> > > 2. > The Connection ID should be generated using a proper > secure > > > > >> algorithm > > > > >> > > (additional research is required here) to make sure an > intruder > > can > > > > >> not > > > > >> > > generate an existing Connection ID > > > > >> > > Not sure about the reasoning here. I think randomUUID() should > > be > > > > >> enough: > > > > >> > > - In the case of an unsecured cluster it does not matter, > > because > > > > >> anyone > > > > >> > > can do anything. > > > > >> > > - In the case of
