Igniters,
I've got following situation:
1) Start Ignite node.
2) Start load from store via cache.loadCache(null)
3) From java client (org.apache.ignite.internal.client.GridClient) start
SCAN query on this cache.
4) SCAN query blocked until load is not finished.
Is this expected behavior?
I
I take thread dump and found the following:
"ignite-#80%rest-jdbc.CacheJdbcPortableStoreSelfTest%" prio=6
tid=0x0e6bd800 nid=0x21e4 in Object.wait() [0x1662d000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/80
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is
GitHub user agura opened a pull request:
https://github.com/apache/ignite/pull/177
ignite-1745 GridCacheIoManager should send correct response in case of
cache query error
You can merge this pull request into a Git repository by running:
$ git pull
I am using El Capitan, no issues so far.
D.
On Tue, Oct 27, 2015 at 10:34 AM, Sergi Vladykin
wrote:
> Is it safe? Did anyone try?
>
> Sergi
>
Vasiliy Sisko created IGNITE-1799:
-
Summary: Preview mark as changed on first switch of XML/Java type.
Key: IGNITE-1799
URL: https://issues.apache.org/jira/browse/IGNITE-1799
Project: Ignite
How about we check that dashcode is not 0 when storing portable keys in
cache?
On Tue, Oct 27, 2015 at 8:42 PM, Alexey Kuznetsov
wrote:
> Andrey, thanks.
>
> Actually I use this not well documented method to solve my problem.
>
> And I'm proposed to at least add more
Igniters,
I'm working on [1] "IGNITE-1753 Rework CacheJdbcPojoStore to new API."
And one of subtasks is to support portable objects with JDBC store.
I implemented this and during tests found a huge performance drop when I
have PortableObject as key.
After some debugging I found that all my