Hello!
As I understood, we don't try to solve the problem mentioned in the IEP:
there is unexpected behavior,
users should carefully read the docs to know about this, and so on.
A thread that executes an incorrect listener hung in any case,
and the suggested solution is to change the pool which ow
;t execute user code on striped pool
> >
> > I believe this solves the problem and removes any and all restrictions
> > for async listeners/continuations. Am I missing something else?
> >
> > On Wed, Mar 17, 2021 at 10:16 AM Denis Garus
> wrote:
> >
> >
> - It is recommended to be used by default [1]
> - There are no alternatives?
>
> [1]
>
> https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ForkJoinPool.html
>
> On Wed, Mar 17, 2021 at 1:02 PM Denis Garus wrote:
>
> > Pavel, thank you for your answer.
Pavel,
I tried this:
@Test
public void test() throws Exception {
IgniteCache cache =
startGrid().getOrCreateCache("test_cache");
cache.putAsync(1, "one").listen(f -> cache.replace(1, "two"));
assertEquals("two", cache.get(1));
}
and this test is green.
I believe that an user can mak
Hello!
> Let's say a user started a compute with fut = compute.runAsync(task);
> and now calls fut.complete(someVal); Does this mean that Ignite no longer
needs to execute the task?
> If the task is currently running, does it need to be canceled?
Yes, this case looks like Ignite should cancel com
if complete is invoked.
>
> On Tue, 30 Mar 2021 at 4:58 PM, Denis Garus wrote:
>
> > Hello!
> >
> > > Let's say a user started a compute with fut = compute.runAsync(task);
> > > and now calls fut.complete(someVal); Does this mean that Ignite no
> longer
> And finally, we can have an IgniteFuture that extends CompletableFuture.
> > This might be useful if want the cancel() operation to cancel the
> > underlying operation. This way we keep all the functionality of
> > CompletableFuture while keeping a certain amount of flexibilit
Hello, Mikhail!
Proposed realization provides a security plugin when
isAuthenticationEnabled is true and,
in this way, makes IgniteSecurity enabled. But current implementation of
IgniteAuthenticationProcessor (security plugin)
does not allow:
- apply a security policy, so authorization does
Hello, Igniters!
I've raised the PR [1] for the issue [2].
Could somebody review it?
Suggested implementation
If Ignite Security (IS) is enabled, then executors, accessed through the
PoolProcessor,
are wrapped to a security-aware implementation. Security-aware
implementation sets proper
security
Hello, Igniters!
I want to propose to improve the way which we use
to present permissions in Ignite 3.
The model of permission in Ignite has a set of drawbacks.
The main drawback, IMHO: if you need to add a new permission,
you should change the core module by extended the 'SecurityPermission'
enu
Sorry, I forgot to point the link
1. https://github.com/apache/ignite/pull/8989
чт, 8 апр. 2021 г. в 17:50, Denis Garus :
> Hello, Igniters!
>
> I want to propose to improve the way which we use
> to present permissions in Ignite 3.
>
> The model of permission in Ignite has
ation. In
> > particular, implementation can choose an existing behavior of bundling
> > permissions with SecuritySubject.
> >
> > Makes sense?
> >
> > чт, 8 апр. 2021 г. в 17:52, Denis Garus :
> >
> > > Sorry, I forgot to point the link
> > >
rbak...@gmail.com
> > >:
> >
> > > +1
> > >
> > > We should rethink the security model in Ignite 3 and have a default
> RBAC
> > > based implementation, from my point of view.
> > > By default, no code should be written to enable and
Maksim, ok.
Let me know if you have any questions.
ср, 21 апр. 2021 г. в 17:51, Maksim Stepachev :
> Please wait. I'm watching your review.
>
> вт, 6 апр. 2021 г. в 20:14, Denis Garus :
>
> > Hello, Igniters!
> >
> > I've raised the PR [1] for the
Hello, Igniters!
I've raised the PR [1] with the sandbox for AI [2].
Could somebody review it?
If you have questions and prefer the Slack, I've created the channel [3].
1. https://github.com/apache/ignite/pull/6707
2. https://issues.apache.org/jira/browse/IGNITE-11410
3. https://app.slack.com/cl
>
> Thanks,
> S.
>
> пт, 11 окт. 2019 г. в 12:24, Anton Vinogradov :
>
> > Folks,
> >
> > As a prereviewer, I'd like to say that the solution looks good to me, but
> > fresh eyes would be good.
> >
> > On Fri, Oct 11, 2019 at 9:40 AM Denis Garus
> activities. In that case, we can implement a feature step by step and merge
> it into the master branch once all components are covered.
>
> > But, sure, we should execute any user-defined code in the sandbox on a
> remote node. Feel free to create issues.
> will do.
>
Hi, Igniters!
I'd like to add a new wiki page with IEP for the Sandbox feature.
Could someone grant me (Denis Garus) write permission?
; > > > :)
> > > > >
> > > > > > From my point, we should divide the sandbox and features that use
> > it.
> > > > > > Also, I added in the main features of Ignite (cache and compute)
> > the
> > > > > sandbox calls.
&
Hello, Dmitriy!
I've got the write access.
Thank you!
пн, 21 окт. 2019 г. в 22:03, Dmitriy Pavlov :
> I found someone has granted permission to Denis Garus. Could you confirm
> everything is ok?
>
> вт, 15 окт. 2019 г. в 10:12, Denis Garus :
>
> > Hi, Igniters!
>
Hello, Igniters!
I've raised the PR [1] for the issue [2].
Could somebody review it?
1. https://github.com/apache/ignite/pull/7017
2. https://issues.apache.org/jira/browse/IGNITE-12300
extCheckTest#testClientTaskInitatorCancelOnSrvNode
> is flaky.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> чт, 7 нояб. 2019 г. в 12:10, Denis Garus :
>
> > Hello, Igniters!
> >
> > I've raised the PR [1] for the issue [2].
> > Could somebody revie
ailure.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> чт, 7 нояб. 2019 г. в 15:36, Denis Garus :
>
> > Hi, Ilya!
> >
> > Thank you for the review!
> >
> > > For some reason, when I run it locally, it starts to use persistence,
> do
> > >
our ticket.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> чт, 7 нояб. 2019 г. в 16:18, Denis Garus :
>
> > >> but keep data in-memory?
> >
> > I don't use any data in tests for this issue; only compute task.
> >
> >
> > >> I have com
Hello, Sergey!
>> 3. Ignite doesn't have roles/authorization functionality for now.
I can't agree with you.
We already have authorization functionality in Ignite and for a thin client
too [1].
But, compute support for a thin client requires some additional efforts to
get an appropriate Securi
https://cwiki.apache.org/confluence/display/IGNITE/IEP-38%3A+Sandbox
3. https://github.com/apache/ignite/pull/6707
чт, 17 окт. 2019 г. в 16:21, Denis Garus :
> Hello, Pavel!
>
> Thank you for the feedback!
>
> I've created IEP-38 that describes the Ignite Sandbox [1].
&g
r step down and some committer may revert you commit.
>
> *New test failure in master EntryProcessorPermissionCheckTest.test
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-59427578418496601&branch=%3Cdefault%3E&tab=testDetails
> Chang
Hi, Igniters!
I've prepared the PR[1] for the ticket[2], could somebody do a review?
Thanks.
1. https://github.com/apache/ignite/pull/7338
2. https://issues.apache.org/jira/browse/IGNITE-12344
Hi!
That is a known issue [1].
> is there any workaround to get this information?
I think, unfortunately, no.
1. https://issues.apache.org/jira/browse/IGNITE-12589
пн, 17 февр. 2020 г. в 10:02, VeenaMithare :
> Hi ,
>
> Hi ,
>
> We have built a security and audit plugin for security of our
Hi, Igniters!
At present, a security subject id is assumed to be node id.
But when we are dealing with thin client, JDBC or REST subject id is random
UUID. In this case, we cannot get the subject information on a remote node,
and we get problems like these [1], [2].
To fix the problem, we shoul
nts-for-new-security-approach-td42698.html#a42708
> And in my solution, I just transmitted security subjects for rest requests.
>
> If you remove ATTR_SECURITY_SUBJECT_V2, it breaks compatibility between old
> versions and new.
>
> чт, 20 февр. 2020 г. в 15:56, Denis Garus :
>
&g
Hi!
It will be available in 2.8.
сб, 22 февр. 2020 г. в 15:53, VeenaMithare :
> HI Denis,
>
> Which version of Apache Ignite are the changes you mention in the comment(
> security context always not null ) above available with ? In 2.7.6 I do get
> security context as null in authorize method.
>
t [2] on the example of a JDBC client with the reproducer attached.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-12589
> [2] https://issues.apache.org/jira/browse/IGNITE-12579
>
> On 26.02.2020 11:47, Alexei Scherbakov wrote:
> > Denis Garus,
> >
> > It is forb
Hi guys!
I created the iep ticket [1] and started work.
1. https://issues.apache.org/jira/browse/IGNITE-12759
чт, 5 мар. 2020 г. в 12:00, Denis Garus :
> Hi, guys!
>
>
> I've prepared the IEP-41: Security Context of a thin client on remote
> nodes [1]; take a look, please.
1.Return type. SecurityContext is implemented by security plugin
developers,
and we cannot make SecurityContext from SecuritySubject.
But GridSecurityProcessor#authorize method requires SecurityContext as
parameter.
2. Method GridSecurityProcessor#authenticatedSubject returns
authenticated *node
s
> I dont think that is true.
/**
* *Gets authenticated node subject.*
*
* @param subjId Subject ID.
* @return Security subject.
* @throws IgniteCheckedException If error occurred.
*/
public SecuritySubject authenticatedSubject(UUID subjId) throws
IgniteCheckedException;
> Nothing stops an
clear contract and enforces compatibility check natural way.
вс, 15 мар. 2020 г. в 17:13, Alexei Scherbakov :
> Denis Garus,
>
> I've looked at the IEP proposed by you and currently I'm thinking it's not
> immediately required.
>
> The problem of missing Sec
Hello, Alexei!
Thank you for the review!
I`ve fixed your comments, take a look, please.
пн, 17 февр. 2020 г. в 12:53, Nikita Amelchev :
> Denis,
>
> I have pre-reviewed your changes, LGTM.
>
> Could some security maintainer take a look?
>
> вт, 11 февр. 2020 г.
; We really need to resolve this concern as well :
> > https://issues.apache.org/jira/browse/IGNITE-12781
> >
> > ( Incorrect security subject id is associated with a cache_put event
> > when the originator of the event is a thin cl
gt; or less consistent state.
> > 2. Remove IEP-41 because it's no longer needed because of change [1]
> > 3. Propose an IEP to make security API avoid using internals.
> >
> >
> >
> > пн, 23 мар. 2020 г. в 19:53, Denis Garus :
> >
> > > H
Hi!
I'm not sure that @Nullable can really fix the NPE problem.
Currently, we have @Nullable annotation and NPE simultaneously.
The best way to avoid NPE is by using a null object pattern.
I agree we shouldn't rely on @Nullable.
пт, 27 мар. 2020 г. в 12:58, Sergey Antonov :
> I disagree.
>
> Int
erhaul prior to
> > 2.9. I believe that you are the most suitable Ignite community member to
> > drive this activity. I'd love to share some ideas as well.
> >
> > On Tue, Mar 24, 2020 at 2:04 PM Denis Garus wrote:
> >
> >> Hi, guys!
> >>
Hello!
I have seen projects with Travis-ci they look cool.
I think Travis-ci is a good solution.
вт, 14 апр. 2020 г. в 10:00, Andrey Mashenkov :
> Maxim,
>
> Good idea. I'd add a license check as well.
>
> On Tue, Apr 14, 2020 at 2:14 AM Maxim Muzafarov wrote:
>
> > Igniters,
> >
> > It's reall
; So, I propose to exclude IGNITE-12756 from 2.8.1
> > >>>>>>>>>>>> Andrey, what do you think as a committer of this
> improvements?
> > >>>>>>>>>>> Mainly IGNITE-12756 brings some improvements related with TCP
>
Maxim, Congrats!
Great job!
чт, 7 мая 2020 г. в 15:02, Nikita Amelchev :
> Maxim, congrats!
>
> чт, 7 мая 2020 г. в 14:55, Nikolay Izhikov :
> >
> > Congrats.
> >
> > > 7 мая 2020 г., в 14:54, Ivan Pavlukhin
> написал(а):
> > >
> > > Maxim,
> > >
> > > My congratulations! Well deserved!
> > >
>
Hello, Igniters!
IgniteMessaging has inconsistent behavior when a remote listener throws an
exception.
A remote listener throws an exception, if this listener registered on a
node that sends a message,
the sender gets this exception. But if the sender node and the node with
the remote listener ar
Hello, Saikat!
I know that IgniteMessagin is used in the production environment and
I don't see any bugs in Jira with this feature.
I wrote some tests for IgniteMessaging in the security suite, and only one
confusing thing was noticed [1].
Why did we decide to deprecate IgniyeMessaging API in Ig
Hello!
If I understood your problem correctly, you need to make a thin client's
security context allowed on a remote node.
When a security plugin does authenticate a thin client, it should spread
the thin client's security context on the cluster.
How a security context will be transmitted to a
o this ?
> I checked your poc PR for reference,
> https://github.com/apache/ignite/pull/7375
>
> In thin client case authenticate node will not be called but authenticate
> method is getting called.
>
>
> Regards,
> Vishwas
>
>
> On Fri, 27 Nov, 2020, 14:29 Denis
Hi!
I don't understand why you do something related to thin clients inside
onDisconnected method?
The rest looks good to me.
ср, 9 дек. 2020 г. в 17:00, vbm :
> Hi Denis,
>
> Any thoughts on the approach mentioned above ?
>
>
> Regards,
> Vishwas
>
>
>
> --
> Sent from: http://apache-ignite-devel
742230009
>
>
> It will be great if you can provide input on this.
>
>
> Regards,
> Vishwas
>
> On Fri, 18 Dec, 2020, 21:39 Denis Garus, wrote:
>
> > Hi!
> > I don't understand why you do something related to thin clients inside
> > onDisconnec
Hello!
We should not forget about monitoring security events.
>From security, every fail of authentication or authorization is an
important event that may indicate an attack or configuration mistake.
In any case, grid admins should have tools to get these events on time.
вс, 21 апр. 2019 г. в 22:2
Hi radha!
Regarding your question about SecurityContext as null, you should update
your master branch. Today
ср, 29 мая 2019 г. в 08:00, radha jai :
> Hi,
> I have implemented the grid security processor and setting the
> securityconext holder in the authenticate function as below,
>
> public c
Hi, Radha Jai!
You should update your master branch AI.
Today we don't have the SecurityContextHolder class, but we have a
guaranty, that SecurityContext argument in the authorize method will not be
null.
Good luck!
ср, 29 мая 2019 г. в 08:00, radha jai :
> Hi,
> I have implemented the grid secu
Hello, Maksim!
Thanks for your analysis!
I have a few questions about your proposals.
GridRestProcessor.
AFAIK, when GridRestProcessor handle client request
(GridRestProcessor#handleRequest)
it process authentication (GridRestProcessor#authenticate)
and then authorization of request (GridRestProc
Hello Igniters!
I made the test DoPrivelegedOnRemoteNodeTest[1] (SecurityTestSuite) for the
task "Sandbox for user-defined code" [2]
that uses p2p deploy like the test
ServiceHotRedeploymentViaDeploymentSpiTest [3] from
IgniteServiceGridTestSuite.
That test requires additional Maven command line p
Igniters!
I think it's time to change coding guidelines in part of JavaDoc comments
[1]:
>> Every method, field or initializer public, private or protected in
top-level,
>> inner or anonymous type should have at least minimal Javadoc comments
including
>> description and description of parameters
ding internal.
> > > We should fix useless javadoc you provide.
> > > We should not accept patches without good javadocs.
> > >
> > > As for the tests, seems, we can make javadoc optional.
> > >
> > > What do you think?
> > >
> &g
to extract security tests in a separate build plan on
> TC.
> >
> > BTW, if you are going to write a lot of Sandbox's tests pay attention
> > to 'extdata' module and an approach of P2P tests
> > (IgniteP2PSelfTestSuite) - this may help you to avoid Maven's
>
ability.
> > - It's better to leave the entity undocumented, than write
> > unexpressive/misleading comment.
> > - Even classes may not require javadocs, e.g. simple DTOs.
> >
> > ср, 7 авг. 2019 г., 13:39 Denis Garus :
> >
> > > Thx for f
Thanks all for the feedback!
I think no one is against of proposal.
Petr, could you please assist with wit separation of SecurityTestSuite?
чт, 8 авг. 2019 г. в 14:43, Denis Garus :
> Hello, Ivan!
>
> >> Could you please provide more details why do we need to run these tests
Sure! I created the task [1].
Thank you!
1. https://issues.apache.org/jira/browse/IGNITE-12055
пт, 9 авг. 2019 г. в 11:38, Petr Ivanov :
> Hi, Denis!
>
>
> Could file a ticket with description, please?
>
> On 9 Aug 2019, at 11:35, Denis Garus wrote:
>
> Thanks all
Great!
Could you please add surefire-fork-count-1 to additional Maven command line
parameters?
It's crucial.
Thank you!
пт, 9 авг. 2019 г. в 12:42, Petr Ivanov :
> Done [1]
>
>
> [1] https://ci.ignite.apache.org/viewLog.html?buildId=4482200
>
> On 9 Aug 2019, at 12
Excuse me! I was wrong.
I try to find that parameter on Step 4: Run test suite.
One more time, thank you!
пт, 9 авг. 2019 г. в 14:05, Petr Ivanov :
> Why do you think I did not use it?
>
>
> On 9 Aug 2019, at 13:25, Denis Garus wrote:
>
> Great!
> Could you please add sur
Hello, Mikhail!
Why do we need to avoid tough mapping GridRestCommand -> SecurityPermission?
Maybe it would be more transparent if we add to the GridRestCommand a field
that will contain SecurityPermission for this command?
ср, 11 сент. 2019 г. в 17:34, Mikhail Petrov :
> Igniters,
>
> I would
Hello, Igniters!
I ran two times the Examples suite [1] on the master branch today and get
different results. It looks like some tests become unstable after merging
of task IGNITE-12148 [2]. I think tests result depend on an Agent that
executes suite.
1.
https://ci.ignite.apache.org/buildConfigur
Examples
пт, 13 сент. 2019 г. в 20:25, Alexey Zinoviev :
> Dear @ Denis Garus
>
> Could you please what kind of tests became unstable?
> Because I have no troubles with examples (and run them of course before
> merging) and many builds have no troubles too
>
> Look at
>
ент. 2019 г. в 20:51, Alexey Zinoviev :
>
> > Thank you, I'll try to fix it, ticket is here
> > https://issues.apache.org/jira/browse/IGNITE-12168
> >
> > пт, 13 сент. 2019 г. в 20:41, Denis Garus :
> >
> >> Alexey, sure.
> >> My first build toda
;
> пт, 13 сент. 2019 г. в 21:16, Alexey Zinoviev :
>
> > Ok, got it, I've found a solution
> >
> > пт, 13 сент. 2019 г. в 21:09, Denis Garus :
> >
> >> Alexey, about agents was my assumption, and it looks like wrong.
> >> I didn
Igniters!
I would like to propose a few improvements for the P2P class loading
feature in Ignite.
These improvements have the aim to reduce the number of requests that may
be needing to get a class on a remote node.
a. We should send a request for a class to the node initiator firstly.
Currently,
Hello, Igniters!
Some events contain the subjectId method, for example, TaskEvent#subjectId.
The JavaDoc for this method is:
"Gets security subject ID initiated this task event, if available.
This property is not available for GridEventType#EVT_TASK_SESSION_ATTR_SET
task event.
Subject ID will be
part of
> Ignite 3.0 to remove certain limitations? How about linking all the P2P
> tasks together and create either an IEP or an umbrella ticket.
>
> -
> Denis
>
>
> On Tue, Sep 24, 2019 at 12:55 AM Denis Garus wrote:
>
> > Igniters!
> >
> > I would like to
.@gmail.com>
> wrote:
>
> > Hi.
> >
> > Anton Vinogradov,
> >
> > I want to fix 2-3-4 points under one ticket.
> >
> > The first was fixed in the ticket:
> > https://issues.apache.org/jira/browse/IGNITE-11094
> > Also, I aggry with you th
gt; >
> > -
> > Denis
> >
> >
> > On Tue, Sep 24, 2019 at 3:55 AM Denis Garus wrote:
> >
> > > Hello, Igniters!
> > >
> > > Some events contain the subjectId method, for example,
> TaskEvent#subjectId.
> > > The J
ntion that described behavior is confirmed by tests.
пн, 30 сент. 2019 г. в 13:11, Maksim Stepachev :
> Denis,
>
> I added it in my ticket and pull-request. Should I change the only first
> sentence or full comment?
>
> пн, 30 сент. 2019 г. в 11:27, Denis Garus :
>
>> Hello!
, we need to get rid of GridTaskThreadContextKey#TC_SUBJ_ID as
> duplication of IgnitSecurity responsibility.
> [2]Yes, we should rid of this. But in the next task, because I can't merge
> it since 18 Jul 19:)
>
> [1] I aggry with you.
>
>
> пт, 27 сент. 2019 г. в 11:42, Denis Garus
y with requests are made from
> GridRestProcessor (It isn't a client, I call it like a fake client). As a
> result, you can't load security on demand. If you want to do it, you
> should transmit HTTP session and backward address of a node which
> received REST request.
>
There is the #ignite-security Slack channel; we can use it for discussion.
вт, 1 окт. 2019 г. в 09:14, Anton Vinogradov :
> Folks,
>
> Could you please create a slack channel to discuss this in an effective
> way?
>
> On Mon, Sep 30, 2019 at 5:36 PM Denis Garus wrote:
>
&
Hello Igniters!
I have found some confusing behavior of atomic partitioned cache with
`PRIMARY_SYNC` write synchronization mode.
Node with a primary partition sends a message to remote nodes with backup
partitions via `GridDhtAtomicAbstractUpdateFuture#sendDhtRequests`.
If during of sending o
-5e5bfb73bd917d85f56a05552b1d014aR26
2018-06-05 17:35 GMT+03:00 Denis Garus :
> Hello Igniters!
>
>
>
> I have found some confusing behavior of atomic partitioned cache with
> `PRIMARY_SYNC` write synchronization mode.
>
> Node with a primary partition sends a message to
Hello, Igniters!
If an error occurred during of creation dynamic cache, the
CacheAffinitySharedManager#processCacheStartRequests method will try to
rollback cache start routine.
```
try {
if (startCache) {
cctx.cache().prepareCacheStart(req.startCacheConfiguration(),
hese changes will fix your reproducer.
>
> Hope, it helps you.
>
> [1] https://github.com/apache/ignite/pull/4487/files
>
>
> On Fri, 3 Aug 2018 at 14:54 Denis Garus wrote:
>
> > Hello, Igniters!
> >
> >
> > If an error occurred during of creation dy
dDhtPartitionsExchangeFuture#onCacheChangeRequest(boolean crd) method.
> (please take a look at this JIRA ticket:
> https://issues.apache.org/jira/browse/IGNITE-1094)
>
> Best regards,
> Slava.
>
>
> пт, 3 авг. 2018 г. в 14:54, Denis Garus :
>
> > Hello, Igniters!
>
gt; CacheAffinitySharedManager#processCacheStartRequests method
> Looks like a plan :)
>
> Thanks,
> S.
>
> вт, 7 авг. 2018 г. в 16:42, Denis Garus :
>
> > Hello, Slava!
> >
> > Yes, I agree with you. If we get rid of this catch block, everything
> works
> > well.
>
Hi, Igniters!
Currently, errors of creation dynamic caches on server nodes and client
nodes are different.
If an error occurs on a server node, all cache nodes should revert the
changes [1].
If an error occurred on a client node, the client reverts the changes,
servers nodes start cache.
In tha
Ivan,
there are some questions related to ticket IGNITE-8162:
1. deleting a file of cache configuration leads to successfuly getting cache
clonfiguration. But, is there guarantee that cache will work correctly?
2. if deleting a file of cache configuration is enough to get cache able to
work, ca
Denis Garus created IGNITE-14179:
Summary: The GridDhtTxFinishFuture has the redundant interface
declaration 'GridCacheFuture'
Key: IGNITE-14179
URL: https://issues.apache.org/jira/browse/IG
Denis Garus created IGNITE-14317:
Summary: IgniteCache.removeAsync(key,val) fails inside an
optimistic transaction
Key: IGNITE-14317
URL: https://issues.apache.org/jira/browse/IGNITE-14317
Project
Denis Garus created IGNITE-12282:
Summary: Access restriction to the internal package of Ignite
Key: IGNITE-12282
URL: https://issues.apache.org/jira/browse/IGNITE-12282
Project: Ignite
Denis Garus created IGNITE-12283:
Summary: Access restriction to IgniteKernal
Key: IGNITE-12283
URL: https://issues.apache.org/jira/browse/IGNITE-12283
Project: Ignite
Issue Type: Task
Denis Garus created IGNITE-12300:
Summary: ComputeJob#cancel executes with wrong SecurityContext
Key: IGNITE-12300
URL: https://issues.apache.org/jira/browse/IGNITE-12300
Project: Ignite
Denis Garus created IGNITE-12341:
Summary: Sandbox: Adding tests for ComputeJob#cancel
Key: IGNITE-12341
URL: https://issues.apache.org/jira/browse/IGNITE-12341
Project: Ignite
Issue Type
Denis Garus created IGNITE-12342:
Summary: Continuous Queries: Remote filter and transformer have to
run with appropriate SecurityContext.
Key: IGNITE-12342
URL: https://issues.apache.org/jira/browse/IGNITE-12342
Denis Garus created IGNITE-12343:
Summary: Remote filter and transformer of ContinuousQueries have
to run inside the Ignite Sandbox
Key: IGNITE-12343
URL: https://issues.apache.org/jira/browse/IGNITE-12343
Denis Garus created IGNITE-12344:
Summary: Remote listener of IgniteMessaging has to run with
appropriate SecurityContext.
Key: IGNITE-12344
URL: https://issues.apache.org/jira/browse/IGNITE-12344
Denis Garus created IGNITE-12345:
Summary: Remote listener of IgniteMessaging has to run inside the
Ignite Sandbox.
Key: IGNITE-12345
URL: https://issues.apache.org/jira/browse/IGNITE-12345
Project
Denis Garus created IGNITE-12443:
Summary: Document the Ignite Sandbox
Key: IGNITE-12443
URL: https://issues.apache.org/jira/browse/IGNITE-12443
Project: Ignite
Issue Type: Task
Denis Garus created IGNITE-12500:
Summary: IgniteProxy should be injected into non-system types only.
Key: IGNITE-12500
URL: https://issues.apache.org/jira/browse/IGNITE-12500
Project: Ignite
Denis Garus created IGNITE-12529:
Summary: Getting local ignite instance inside ComputeJob#cancel
Key: IGNITE-12529
URL: https://issues.apache.org/jira/browse/IGNITE-12529
Project: Ignite
Denis Garus created IGNITE-12533:
Summary: Remote security context tests refactoring.
Key: IGNITE-12533
URL: https://issues.apache.org/jira/browse/IGNITE-12533
Project: Ignite
Issue Type
1 - 100 of 122 matches
Mail list logo
