This issue once reproduced in my productive with similar stack trace. During
sources analysis I saw the use unsafe of method
writeLock().isHeldByCurrentThread() for unlocking checkpoint. This may cause
thread to starvation. Problem no longer appeared after local fix.
I prepared pull request https:/
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.
>
Good day!
I want solve the issue https://issues.apache.org/jira/browse/IGNITE-6530.
Add me (Jira ID: gorchakov) to contributors please so that I can accept
this task on myself.
This issue once reproduced in my productive with similar stack trace. During
sources analysis I saw the use unsafe of method
writeLock().isHeldByCurrentThread() for unlocking checkpoint. This may cause
thread to starvation. Problem no longer appeared after local fix.
I prepared pull request https:/
This issue once reproduced in my productive with similar stack trace. During
sources analysis I saw the use unsafe of method
writeLock().isHeldByCurrentThread() for unlocking checkpoint. This may cause
thread to starvation. Problem no longer appeared after local fix.
I prepared pull request https:/
Hello, Dmitriy.
Do you have a reproducer? minimal application that can reproduce this specific
bug.
Can you, please, run a TC for your PR and get a TC bot visa?
> 25 февр. 2020 г., в 11:08, Dmitry Gorchakov
> написал(а):
>
> This issue once reproduced in my productive with similar stack trac
Hello Dmitry,
To be honest, I don't quite understand the proposed fix. Could you please
describe in detail the issue you are trying to fix?
By the way, please take a look at
GridCacheDatabaseSharedManager.checkpointReadLock:
@Override public void checkpointReadLock() {
if (checkpointL
Hi,
Can we have this behavior documented? This will help user to design their
caches appropriately.
*For Replicated Cache:*
Reference mail thread:
http://apache-ignite-users.70518.x6.nabble.com/Read-through-not-working-as-expected-in-case-of-Replicated-cache-td29990.html
read through for repli
Hello, Igniters.
I got a question what exactly IgniteServices#service(String name) is
supposed to return: reference to the object or a proxy for some reason like
IgniteServices#serviceProxy(…)? Vyacheslav D., can you tell me your opinion?
public interface MyService {
public void
Hi Dmitry,
Welcome to Apache Ignite Community!
I added a contributor role to your Jira account. Now you can assign
tickets to yourself. Do not hesitate to ask if you need any
assistance.
Please check this page out for commonly asked questions pertaining to
the contribution process:
https://ignit
Hello, Igniters.
Previous e-mail was with wrong topic 'daradu...@gmail.com' :)
I got a question what exactly IgniteServices#service(String name) is
supposed to return: reference to the object or a proxy for some reason like
IgniteServices#serviceProxy(…)? Vyacheslav D., can you tell me your opini
Wrong topic :). Sent another e-mail. Do not raise this one pls.
вт, 25 февр. 2020 г. в 14:59, Vladimir Steshin :
> Hello, Igniters.
>
>
>
> I got a question what exactly IgniteServices#service(String name) is
> supposed to return: reference to the object or a proxy for some reason like
> IgniteSe
Hi, Vladimir
The answer is in API docs: "Gets *locally deployed service* with specified
name." [1]
That means {IgniteServices#service(String name)} returns only locally
deployed instance or null.
{IgniteServices#serviceProxy(…)} returns proxy to call instances across the
cluster. Might be used f
Vyacheslav, Hi.
I see. But can we consider 'locally deployed service' is a proxy too, not
direct reference? What if I need to wrap it? This would be local service
working via proxy or null.
вт, 25 февр. 2020 г. в 16:03, Vyacheslav Daradur :
> Hi, Vladimir
>
> The answer is in API docs: "Gets *lo
{IgniteServices#service(String name)} returns direct reference in the
current implementation.
So, class casting should work for your example:
((MyServiceImpl)ignite.services().service(“myService”)).bar();
It is safer to use an interface instead of an implementation, there is no
guarantee that in
Vyacheslav, this is exactly what I found. I'm doing [1] (metrics for
services) and realized I have to wrap local calls by a proxy. Is it a
change of public API and should come with major release only? Or we can
declare usage of services without interfaces incorrect?
[1] https://issues.apache.org/ji
It is not a change of public API from my point of view.
Also, there is a check to allow getting proxy only for an interface, not
implementation.
Denis, what do you think?
вт, 25 февр. 2020 г. в 16:28, Vladimir Steshin :
> Vyacheslav, this is exactly what I found. I'm doing [1] (metrics for
> s
Write lock is an exclusive lock and no other threads can obtain read or
write lock while current thread holding write lock.
Why you think checking for current thread is lock-owner is not atomic?
A thread that already holds a write lock has no needs to obtain read locks
unless it releases the write
Agree with Andrey and Slava.
Your change could lead to exception in case when current thread does
not own read lock.
> Checking for a writе lock holding through method isHeldByCurrentThread is not
> atomic, so there is no certainty that this thread still owns a write lock.
What do you mean when
Pavel,
Can you assist me with preparing NuGet staging according to the
release steps [1]? I've double-checked everything related to the build
but suite [2] for preparing nuget package still fails (sorry for
running it multiple times).
I see some issues in the log which may be related to the file
Hi Prasad,
This is odd behavior and before changing the docs I would try to get to the
bottom. Let me join the user list conversation.
-
Denis
On Tue, Feb 25, 2020 at 3:46 AM Prasad Bhalerao <
prasadbhalerao1...@gmail.com> wrote:
> Hi,
>
> Can we have this behavior documented? This will help u
Ignite Dev team,
This sounds like an issue in our replicated cache implementation rather
than an expected behavior. Especially, if partitioned caches don't have
such a specificity.
Who can explain why write-through needs to be enabled for replicated caches
to reload an entry from an underlying da
Maxim, I did a quick fix for the script, but it did not work.
Investigating further, will get back to you later today.
On Tue, Feb 25, 2020 at 10:10 PM Maxim Muzafarov wrote:
> Pavel,
>
>
> Can you assist me with preparing NuGet staging according to the
> release steps [1]? I've double-checked e
23 matches
Mail list logo
