Vasiliy Sisko created IGNITE-11635:
--
Summary: Wrong type of setter argument for
TcpDiscoverySpi#reconDelay
Key: IGNITE-11635
URL: https://issues.apache.org/jira/browse/IGNITE-11635
Project: Ignite
Sergey, yes, the close is something like silent rollback. But we can
also implement this on the client side, just using rollback and ignoring
errors in the response.
ср, 27 мар. 2019 г. в 00:04, Sergey Kozlov :
> Nikolay
>
> Am I correctly understand you points:
>
>- close: rollback
>- co
Folks, thanks for sharing details and inputs. This is helpful. As long as I
spend a lot of time working with Ignite users, I'll look into this topic in
a couple of days to propose some changes. In the meantime, here is a fresh
one report on the user list:
http://apache-ignite-users.70518.x6.nabble.
Roman Guseinov created IGNITE-11634:
---
Summary: SQL delete query failed to deserialize
DmlStatementsProcessor$ModifyingEntryProcessor
Key: IGNITE-11634
URL: https://issues.apache.org/jira/browse/IGNITE-11634
Nikolay
Am I correctly understand you points:
- close: rollback
- commit, close: do nothing
- rollback, close: do what? (I suppose nothing)
Also you assume that after commit/rollback we may need to free some
resources on server node(s)or just do on client started TX?
On Tue, Mar 26,
Sergey, we have the close() method in the thick client, it's behavior is
slightly different than rollback() method (it should rollback if the
transaction is not committed and do nothing if the transaction is already
committed). I think we should support try-with-resource semantics in the
thin clien
Hello, Alex.
We also have suspend and resume operations.
I think we should support them
вт, 26 марта 2019 г., 22:07 Sergey Kozlov :
> Hi
>
> Looks like I missed something but why we need OP_TX_CLOSE operation?
>
> Also I suggest to reserve a code for SAVEPOINT operation which very useful
> to un
Hi
Looks like I missed something but why we need OP_TX_CLOSE operation?
Also I suggest to reserve a code for SAVEPOINT operation which very useful
to understand where transaction has been rolled back
On Tue, Mar 26, 2019 at 6:07 PM Alex Plehanov
wrote:
> Hello Igniters!
>
> I want to pick up t
Hi,
I've cherry-picked this commit. It seems it is critical because it also
fixes storage corruption.
Sincerely,
Dmitriy Pavlov
вт, 26 мар. 2019 г. в 14:14, Zhenya Stanilovsky :
> I suppose this ticket [1] : is very useful too.
>
>
> [1] https://issues.apache.org/jira/browse/IGNITE-10873 [
> Co
Hello.
Yes, locally this test seems to pass. However, no luck on TC. Maybe my
commit is positioned on top of especially unlucky HEAD.
Anyway, my point was thatTcpDiscoverySslTrustedUntrustedTest (or any other
intra-node SSL test) is a sufficient test for IGNITE-11299.
It will very reliably hang
CleanupWorker termination can lead to the following effects:
- Queries can retrieve data that have to expired so application will
behave incorrectly.
- Memory and/or disc can be overflowed because entries weren't expired.
- Performance degradation is possible due to unmanageable data set grows.
O
Igniters,
1. First of all, I want to remind you why failure handles were
implemented. Please take a look to IEP-14 [1] and corresponding
discussion on dev-list [2] (quite emotional discussion). This sources
also answer on some questions from previous posts of this topic.
2. Note that the followin
Alexey Goncharuk created IGNITE-11633:
-
Summary: Fix errors in WAL disabled archive mode documentation
Key: IGNITE-11633
URL: https://issues.apache.org/jira/browse/IGNITE-11633
Project: Ignite
Hello Igniters!
I want to pick up the ticket IGNITE-7369 and add transactions support to
our thin client implementation.
I've looked at our current implementation and have some proposals to
support transactions:
Add new operations to thin client protocol:
OP_TX_GET, 4000, Get current transac
Stepachev Maksim created IGNITE-11632:
-
Summary: Node can't start if WAL is corrupted and the wal archiver
disabled.
Key: IGNITE-11632
URL: https://issues.apache.org/jira/browse/IGNITE-11632
Proje
Vyacheslav, if you are talking about this particular case I described, I
believe it has no influence on PME. What could happen is having CleanupWorker
thread dead (which is not good too).But I believe we are talking in a wider
scope.
-- Roman
On Tuesday, March 26, 2019, 10:23:30 p.m. GMT
Sergey Antonov created IGNITE-11631:
---
Summary: Server node with PDS and SSL fails on start with NPE
Key: IGNITE-11631
URL: https://issues.apache.org/jira/browse/IGNITE-11631
Project: Ignite
Vladimir Ozerov created IGNITE-11630:
Summary: Document changes to SQL views
Key: IGNITE-11630
URL: https://issues.apache.org/jira/browse/IGNITE-11630
Project: Ignite
Issue Type: Task
In general I agree with Andrey, the handler is very usefull itself. It
allows us to become know that ‘GridDhtInvalidPartitionException’ is not
processed properly in PME process by worker.
Nikolay, look at the code, if Failure Handler hadles an exception - this
means that while-true loop in worker’
I do believe failure handling is useful, but it has to be revisited (including
above-mentioned suggestions) because what we have now is not what Ignite
promises to do. Disabling it can be a temporal measure until it is
improved.Andrey, when you say "hiding", I kind of understand you (even if I
Ilya Kasnacheev created IGNITE-11629:
Summary: Cassandra dependencies missing from deliverable
Key: IGNITE-11629
URL: https://issues.apache.org/jira/browse/IGNITE-11629
Project: Ignite
Is
Denis Mekhanikov created IGNITE-11628:
-
Summary: Document the possibility to use JAR files in
UriDeploymentSpi
Key: IGNITE-11628
URL: https://issues.apache.org/jira/browse/IGNITE-11628
Project: Ig
Nikolay,
Feel free to suggest better error messages to indicate internal/critical
failures. User actions in response to critical failures are rather limited:
mail to user-list or maybe file an issue. As for repetitive warnings, it
makes sense, but requires additional stuff to deliver such signals,
I suppose this ticket [1] : is very useful too.
[1] https://issues.apache.org/jira/browse/IGNITE-10873 [ CorruptedTreeException
during simultaneous cache put operations ]
>
>
>--- Forwarded message ---
>From: "Alexey Goncharuk" < alexey.goncha...@gmail.com >
>To: dev < dev@ignite.apache
Hello Ilya,
I do not see any issues with the mentioned test. I see the following output
in the logs:
[21:41:44] : [Step 4/5] [2019-03-22 21:41:44,970][INFO ][main][root] >>>
Stopping test:
TcpDiscoveryCoordinatorFailureTest#testCoordinatorFailedNoAddFinishedMessageStartOneNode
in 37768 ms <<<
[21
Andrey.
> the thread can be made non-critical, and we can restart it every time it
dies
Why we can't restart critical thread?
What is the root difference between critical and non critical threads?
> It's much simpler to catch and handle all exceptions in critical threads
I don't agree with you
Anton Kalashnikov created IGNITE-11627:
--
Summary: Test
CheckpointFreeListTest.testRestoreFreeListCorrectlyAfterRandomStop always fails
in DiskCompression suite
Key: IGNITE-11627
URL: https://issues.apache.or
Hello!
If you ask me I vote +0,5 either, I am not entirely confident but I answer
a huge volume of questions on userlist which boil down to prematory
SYSTEM_WORKER_TERMINATION.
Regards,
--
Ilya Kasnacheev
вт, 26 мар. 2019 г. в 11:24, Dmitriy Pavlov :
> +0.5 from me from release point of view.
Hello!
This looked sensible to me so I went forward and merged this change.
Regards,
--
Ilya Kasnacheev
пн, 25 мар. 2019 г. в 17:59, Denis Mekhanikov :
> Folks,
>
> I prepared a patch for the second ticket:
> https://github.com/apache/ignite/pull/6177
> Ilya is concerned, that if you had some
Nikolay,
> Why we can't restart some thread?
Technically, we can. It's just matter of design: the thread can be made
non-critical, and we can restart it every time it dies. But such design
looks poor to me. It's much simpler to catch and handle all exceptions in
critical threads. Failure handling
+0.5 from me from release point of view. If community agrees with solution,
I can cherry pick fix later.
вт, 26 мар. 2019 г., 8:59 Roman Shtykh :
> Andrey, hmm, I don't think putting back the behavior (if it's safe) we
> used to have with all those exceptions being logged etc. is hiding. I would
Andrey.
> As for SYSTEM_WORKER_TERMINATION, it's unrecoverable, there is no use to wait
> for dead thread's magical resurrection.
Why is it unrecoverable?
Why we can't restart some thread?
Is there some kind of nature limitation to not restart system thread?
Actually, distributed systems are de
By default, SYSTEM_WORKER_BLOCKED failure type is not handled. I don't like
this behavior, but it may be useful sometimes: "frozen" threads have a
chance to become active again after load decreases. As for
SYSTEM_WORKER_TERMINATION, it's unrecoverable, there is no use to wait for
dead thread's magi
33 matches
Mail list logo
