Dmitriy, the probability of having nodes down with these bugs under heavy load
conditions is pretty high. Good candidate for cherry-picking.
[1] https://issues.apache.org/jira/browse/IGNITE-9803[2]
https://issues.apache.org/jira/browse/IGNITE-11127
-- Roman
On Wednesday, March 27, 2019, 2
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
Hi dudes,
I'm Payam Mohammadi, a CS student from Iran.
I don't know many things about database internals and I'm still learning
the basics. I used many databases in some enterprise projects but I have no
deep understanding of their internals.
I'm following Andy Pavlo's works (http://www.cs.cmu.edu
Hello,
I am Percy Ashu a computer engineering student in Buea, Cameroon.
I am very passionate about technology and will love to participate in this
project and learn new things.
At your service.
Ivan,
I've already point to problem place. So we just have to fix it.
On Wed, Mar 27, 2019 at 10:16 PM Павлухин Иван wrote:
>
> Andrey,
>
> There is no method JavaNioAccess.newDirectByteBuffer which is used in
> our code caused the problem.
>
> > We are going in the similar way:
>
> Our way is s
Andrey,
There is no method JavaNioAccess.newDirectByteBuffer which is used in
our code caused the problem.
> We are going in the similar way:
Our way is similar, but it does not work in java 12.
I think it is for separate thread. Let's stop live coding =)
ср, 27 мар. 2019 г. в 22:15, Andrey Gu
>>> I believe we should just add export of jdk.internal.access package to
our scripts and TC configurations.
Unfortunately it isn't enough! We have to modify
GridUnsafe#javaNioAccessObject method.
On Wed, Mar 27, 2019 at 10:08 PM Andrey Gura wrote:
>
> It seems that SharedSecrets is moved to jdk
>> Just a thought regarding a particular error, we can borrow some ideas
from netty.
We are going in the similar way:
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/util/GridUnsafe.java#L1467
On Wed, Mar 27, 2019 at 9:38 PM Павлухин Иван wrote:
It seems that SharedSecrets is moved to jdk.internal.access package.
See PR for OpenJ9 [1].
I believe we should just add export of jdk.internal.access package to
our scripts and TC configurations.
[1] https://github.com/eclipse/openj9/pull/3824
On Wed, Mar 27, 2019 at 8:33 PM Dmitriy Pavlov wro
Dmitry,
It seems that a lunch becomes more and more expensive =(
Just a thought regarding a particular error, we can borrow some ideas
from netty [1].
[1]
https://github.com/netty/netty/blob/b2eaab092b68f3c61f1e14f39e38c964e5095dd7/common/src/main/java/io/netty/util/internal/PlatformDependent0.
Alexey Goncharuk created IGNITE-11644:
-
Summary: Get rid of old exchange protocol
Key: IGNITE-11644
URL: https://issues.apache.org/jira/browse/IGNITE-11644
Project: Ignite
Issue Type: Imp
I've played with 2.7.5-RC-1 and Java 12, and unfortunately, Ignite can't
start without changes:
Exception in thread "main" java.lang.ExceptionInInitializerError
at
org.apache.ignite.internal.util.IgniteUtils.(IgniteUtils.java:795)
at org.apache.ignite.internal.IgnitionEx.(IgnitionEx.java:209)
at o
I see no other dependencies for IGNITE-10003.
Best regards,
Andrey Kuznetsov.
ср, 27 марта 2019, 18:25 Andrey Gura ag...@apache.org:
> What do you think about including patches [1] and [2] to Ignite 2.7.5?
> It's all about default failure handler behavior in cases of
> SYSTEM_WORKER_BLOCKED and
What do you think about including patches [1] and [2] to Ignite 2.7.5?
It's all about default failure handler behavior in cases of
SYSTEM_WORKER_BLOCKED and SYSTEM_CRITICAL_OPERATION_TIMEOUT.
Andrey Kuznetsov, could you please check, does IGNITE-10003 depend on
other issue that isn't included into
Vladislav Pyatkov created IGNITE-11643:
--
Summary: Optimize GC pressure on
GridDhtPartitionTopologyImpl#updateRebalanceVersion
Key: IGNITE-11643
URL: https://issues.apache.org/jira/browse/IGNITE-11643
Hello!
So after rebasing I was actually able to get it to pass:
https://ci.ignite.apache.org/viewLog.html?buildId=3431647&buildTypeId=IgniteTests24Java8_SpiWindows
- Java 11, passed
https://ci.ignite.apache.org/viewLog.html?buildId=3431619&buildTypeId=IgniteTests24Java8_SpiWindows
- Java 11 withou
Alexey Platonov created IGNITE-11642:
Summary: [ML] Umbrella: API for Feature/Label extracting (part 2)
Key: IGNITE-11642
URL: https://issues.apache.org/jira/browse/IGNITE-11642
Project: Ignite
Dmitriy Govorukhin created IGNITE-11641:
---
Summary: Server node copies a lot of WAL files in WAL archive
after restart
Key: IGNITE-11641
URL: https://issues.apache.org/jira/browse/IGNITE-11641
Pr
Vyacheslav Koptilin created IGNITE-11640:
Summary: IgnitePdsPageEvictionDuringPartitionClearTest sometimes
hangs on node stop
Key: IGNITE-11640
URL: https://issues.apache.org/jira/browse/IGNITE-11640
Vladimir,
About current tx: ok, then we don't need tx() method in the interface at
all (the same cached transaction info user can store by himself).
About decoupling transactions from threads on the server side: for now, we
can start with thread-per-connection approach (we only can support one
ac
Vyacheslav Koptilin created IGNITE-11639:
Summary: GridCachePartitionedOptimisticTxNodeRestartTest hangs on
TeamCity
Key: IGNITE-11639
URL: https://issues.apache.org/jira/browse/IGNITE-11639
P
Andrey Novikov created IGNITE-11638:
---
Summary: Web console: 'Export All' in query result table doesn't
work
Key: IGNITE-11638
URL: https://issues.apache.org/jira/browse/IGNITE-11638
Project: Ignite
Ivan Fedotov created IGNITE-11637:
-
Summary: Remove class loader initilization in GridSpiAbstractTest
Key: IGNITE-11637
URL: https://issues.apache.org/jira/browse/IGNITE-11637
Project: Ignite
Hi Alex,
My comments was only about the protocol. Getting current info about
transaction should be handled by the client itself. It is not protocl's
concern. Same about other APIs and behavior in case another transaction is
attempted from the same thread.
Putting protocol aside, transaction suppo
Vladimir, what if we want to get current transaction info (tx() method)?
Does close() method mapped to TX_END(rollback)?
For example, this code:
try(tx = txStart()) {
tx.commit();
}
Will produce:
TX_START
TX_END(commit)
TX_END(rollback)
Am I understand you right?
About xid. There is yet a
Pavel Konstantinov created IGNITE-11636:
---
Summary: Web console: incorrect value is restored after Refresh
Key: IGNITE-11636
URL: https://issues.apache.org/jira/browse/IGNITE-11636
Project: Ignite
As far as SUSPEND/RESUME/SAVEPOINT - we do not support them yet, and adding
them in future should not conflict with simple START/END infrastructure.
On Wed, Mar 27, 2019 at 11:00 AM Vladimir Ozerov
wrote:
> Hi Alex,
>
> I am not sure we need 5 commands. Wouldn't it be enough to have only two?
>
Hi Alex,
I am not sure we need 5 commands. Wouldn't it be enough to have only two?
START - accepts optional parameters, returns transaction info
END - provides commit flag, returns void
Vladimir.
On Wed, Mar 27, 2019 at 8:26 AM Alex Plehanov
wrote:
> Sergey, yes, the close is something like s
28 matches
Mail list logo