Yes, some queries will be long running, they are unavoidable.
Query slow is acceptable, but the cluster jammed is a bit of trouble.
I will be grateful if IGNITE-4105 can be solved as soon as possible.
--
View this message in context:
Below is an example of a test case that simulates the problem we are
experiencing.
After we put data to a cache and unlock it if we read the value immediately
after unlock
we randomly get the previous value prior to the update. We are utilizing
locks
to prevent data being overwritten between our
Hi Val,
that means it depends a lot on the OS and if/how it handles virtual
memory-pages.
So why do you plan to change that?
Thanks,
Peter
2017-01-25 0:14 GMT+01:00 vkulichenko :
> Random means anywhere in empty memory space. When you create an entry, a
> new
>
Lukas,
Check that nodes can connect to each other (i.e. there are no network
issues, no firewall or ports are opened, etc.). Another possible reason is
GC - make sure that you have enough heap memory.
-Val
--
View this message in context:
Random means anywhere in empty memory space. When you create an entry, a new
block is create for this value only. If you remove an entry, memory is
released. Once removed, it can be used by any application including Ignite.
Basically, the actual location where memory is allocated is defined by OS.
Thanks for the explanation. Support your intention than, let’s make the
exceptions-based approach default one and leave an ability to fallback to
error-codes if required.
—
Denis
> On Jan 24, 2017, at 3:01 AM, Igor Sapego wrote:
>
> I've read through the old discussion.
Thankx. That did it!
Lukas Lentner, B. Sc.
St.-Cajetan-Straße 13
81669 München
Deutschland
Fon: +49 / 89 / 71 67 44 96
Mobile: +49 / 176 / 24 77 09 22
E-Mail: kont...@lukaslentner.de
Website: www.LukasLentner.de
IBAN:DE41 7019 0002 1125 58
BIC: GENODEF1M01
I managed to get a cluster of servers set up using docker in bridge mode by
supplying an AddressResolver for both discovery and communications. I only
did this in the servers. Intuitively it doesn't seem necessary to do this in
clients since I'm assuming connection initiation is done from the
Hi!
Are you sure that you copied /libs/optional/ignite-rest-http to /libs
folder?
On Tue, Jan 24, 2017 at 8:57 PM, minisoft_rm
wrote:
> dear experts:
>
> I am using ignite 1.8 with agent 1.7.4
>
> after start the agent with default properties, I can import local db
While trying Appache Ignite 1.7.0 for Web Session Caching for a Groovy
Application, we seem to have hit issue with
'Failed to unmarshal object with optimized marshaller'
or
'Failed to serialize object: ' with
JdkMarshaller that points to 'Caused by: java.io.NotSerializableException:
Hi Mikhail,
With 1-st approach
1. Underlying storage can be changed without rewiring its code to add
indexing support.
2. IndexSPI will updated in writeThrough(false) mode, however CacheStore
won't.
With 2-nd
1. You should bother about transaction handling (implementing
CacheStore.sessionEnd()
Hello Ignite-Community!
I just found IGNITE-3477 and esp.
"Continuous put/remove operations with OFFHEAP_TIERED mode lead to
uncontrollable memory fragmentation"
How does Ignite handle OFFHEAP_TIERED caches currently (= how does it store
the data)?
I just tried to create some tests to get an
I have some questions of deploying IGFS as a cache layer given that ignite
could be deployed both as a key-value store and as a file system
1. How does IGFS behave when deployed in standalone mode? I wanted to
confirm that there is no durability in this mode. Assuming I persist a
parquet file on
dear experts:
I am using ignite 1.8 with agent 1.7.4
after start the agent with default properties, I can import local db schema
things into webconsole.
but... the "monitoring clusters" function doesn't work. like below:
in command line:
[21:50:56,754][INFO ][EventThread][RestHandler] Failed
Hello Andrey/Saurabh,
I could get it working with following additions in the jetty configuration :
/
Access-Control-Allow-Origin
*
/
Access-Control-Allow-Methods
GET,POST
Basically had to add "Access-Control-Allow-Methods" too.
Thanks,
Gaurav
On Mon, Jan 23,
+1 for ditching non-throwing methods.
On Tue, Jan 24, 2017 at 2:01 PM, Igor Sapego wrote:
> I've read through the old discussion. It seems that I was not yet
> a part of the community back there thats why I could not find it.
>
> Denis, error code approach is more a C way,
Very good! Please keep us up to date.
--Yakov
2017-01-24 9:30 GMT+03:00 hitendrapratap <
hitendrapratapsingh.si...@target.com>:
> I has been resolved when increased "ignite.failure.detection.timeout" to
> 60sec from 10sec.
>
>
>
> --
> View this message in context: http://apache-ignite-users.
>
17 matches
Mail list logo