Hello,
I am Phani, currently working as an Engineer; interested in distributed
systems, caches, persistent stores. I am looking forward to be part of this
wonderful Ignite community and contribute. My jira user: psadusumilli.
Please let me know if you need any information to add me to the group.
Aleksey Plekhanov created IGNITE-13106:
--
Summary: Java thin client: Race between response and notification
for compute tasks
Key: IGNITE-13106
URL: https://issues.apache.org/jira/browse/IGNITE-13106
Hello ignite folks.
I noticed that there is a staging repo on repository.apache.org, it's url
is here:
https://repository.apache.org/content/repositories/orgapacheignite-1249
I had to address some data integrity issues on repository.apache.org and
that staging repo may have been a casualty.
Hi Alexey,
Let me answer the second question first
How would you change ICache interface which has this member?
We will keep the key-value interface at least for backward compatibility.
Plus, it might be preferred by those who use caching APIs only. So, this
method will stay as-is.
What
Hello, Kirill!
I'd prefer to don't create a new implementation of a failure handler. We
already have 4 different failure handlers. We will have 6 FH (StopNodeFH
with exit code, StopNodeOrHaltFH with exit code), if we go your way. It
won't make our product simpler and easier.
I think, we must
Alexey Kuznetsov created IGNITE-13105:
-
Summary: Spring data 2.0
IgniteRepositoryQuery#transformQueryCursor contains cursor leak
Key: IGNITE-13105
URL: https://issues.apache.org/jira/browse/IGNITE-13105
Alexey Kuznetsov created IGNITE-13104:
-
Summary: Spring data 2.0 IgniteRepositoryImpl#deleteAllById
contains wrong code
Key: IGNITE-13104
URL: https://issues.apache.org/jira/browse/IGNITE-13104
I think that [1] and [2] should not be changed, because we can kill another
client code in this jvm.
I suggest for these purposes to create a new [3] which will be like [1] but
with a call [4] after node stop.
Objections or comments?
[1] - org.apache.ignite.failure.StopNodeFailureHandler
[2] -
Ilya Kasnacheev created IGNITE-13103:
Summary: Investigate marshalling errors when changing fields of
lambda's capturingClass
Key: IGNITE-13103
URL: https://issues.apache.org/jira/browse/IGNITE-13103
Sergey Antonov created IGNITE-13102:
---
Summary: IgniteCache#isClosed() returns false on server node even
if the cache had closed before.
Key: IGNITE-13102
URL: https://issues.apache.org/jira/browse/IGNITE-13102
Alexey Goncharuk created IGNITE-13101:
-
Summary: Metastore may leave uncompleted write futures during node
stop
Key: IGNITE-13101
URL: https://issues.apache.org/jira/browse/IGNITE-13101
Project:
Hi Ivan,
I have an idea about suggested maintenance mode.
First of all, I agree with your ideas about discovery restrictions: node
should not join topology when performing defragmentation.
At the same time I haven't heard about requests for this mode from users,
so we don't know much about
Alexey Goncharuk created IGNITE-13100:
-
Summary: ClassCastException in cache group metrics on client nodes
Key: IGNITE-13100
URL: https://issues.apache.org/jira/browse/IGNITE-13100
Project: Ignite
david created IGNITE-13099:
--
Summary: .net thin client - node selection on start up incorrect -
wrong node chosen in ClientFailoverSocket GetNextSocket
Key: IGNITE-13099
URL:
14 matches
Mail list logo
