Hi Vladislav
Thanks for clarifying. However, we get an error when we try to use the
methods as documented (see below). Does this paradigm also apply to
IgniteMessaging?
Code:
IgniteMessaging rmtMsg = grid.message().withAsync();
rmtMsg.send(destination.topic, message)
Ok I added the debug statements:
https://github.com/dstieglitz/grails-ignite/blob/v0.4.x/src/java/org/grails/ignite/DistributedSchedulerServiceImpl.java
Let me know if you want me to report anything from our application.
--
View this message in context:
http://apache-ignite-users.70518.x6
If you look at the line below:
https://github.com/dstieglitz/grails-ignite/blob/v0.4.x/src/java/org/grails/ignite/IgniteCronDistributedRunnableScheduledFuture.java#L79
We're seeing the string "NULL EXECUTOR" in our status. But based on the way
the classes are initialized I d
Hi guys:
So, we've investigated this a bit further and we think the service is
actually working, but the issue is that our debug display is showing null
for some objects. We think this is because the service and those objects
live on another node, and we're seeing null because they are not seriali
We did find an exception in the remote job which seems to be related (stack
trace below).
There are try {} catch blocks to try and catch this exception but it always
appears in the logs. Is it possible to catch this?
I also noticed it is translated to a "null" IgniteException somewhere, I'm
not s
irmed that on topology change, the object is
properly re-initialized. However, after some period of time, for example,
overnight, the object "goes null."
Are we doing this correctly? Should we store the object in the cluster?
The schedule class is here:
https://github.com/dstieglitz/gra
Hi folks:
We're trying to deploy a clustered singleton service. In our Service
implementation object we have a reference to another object that is
initialized in the init() method.
We've observed that upon topology change, this object can go "null."
What is the correct way to initialize objects
Hi Val:
Thanks, we'll take a look at both of those approaches. We're on AWS, so we
can increase heap, but we are wary of long GC pauses.
Dan
On Tue, Feb 23, 2016 at 2:04 PM, vkulichenko [via Apache Ignite Users] <
ml-node+s70518n3158...@n6.nabble.com> wrote:
> Hi Dan,
>
> There was a bug, I fix
Hi folks:
We are trying to migrate our application's cache from an external cache like
ehcache or memcached to ignite. We store some decently-sized objects in our
cache (e.g., an 8MB file is not atypical).
We have an abstraction layer with pluggable cache providers and can switch
between provide
Hi Val:
Our test system has been locked down due to a business deliverable and I
can't restart it at the moment. I'm looking for a window to do so and hope
to be able to get you some logs. I'm also keen to get this solved so let's
sit tight for the time being.
Dan
--
View this message in conte
Hi Val:
Here's an updated link:
https://www.dropbox.com/s/rntvr0ua1etocx2/logs2.tar.gz?dl=0&s=sl
Dan
--
View this message in context:
http://apache-ignite-users.70518.x6.nabble.com/Hibernate-L2-cache-transactions-tp1460p1492.html
Sent from the Apache Ignite Users mailing list archive at Nabbl
Yeah, I noticed that. IgniteTxLocalAdapter did not log anything, I didn't
configure anything special for transactions. How would I configure
IgniteTxLocalAdapter?
--
View this message in context:
http://apache-ignite-users.70518.x6.nabble.com/Hibernate-L2-cache-transactions-tp1460p1490.html
Sen
Here's a link:
https://www.dropbox.com/s/vvg6suvdrhbmx2j/logs.tar.gz?dl=0&s=sl
--
View this message in context:
http://apache-ignite-users.70518.x6.nabble.com/Hibernate-L2-cache-transactions-tp1460p1487.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Here's the tail from one node after the issue occurred. I'm trying to gather
the full logs but they are quite large. Does this help at all?
2015-09-24 12:39:59,969 [http-nio-8080-exec-5] DEBUG
transactions.IgniteTxManager - Committed from TM
[locNodeId=be0d068c-f3c4-4b94-8bb0-1886b07b890f, tx=Gri
The transactions are managed by Spring via the Grails framework. I'm not sure
if they are explicit but I'm pretty sure Grails is using what ships with
Spring.
In this particular case, I believe there is actually a nested transaction
(at least one, possibly more) using PROPAGATION.REQUIRES_NEW.
Hi folks:
Here's a link to the full stack dump:
https://dl.dropboxusercontent.com/u/24404919/threaddump2.txt
Dan
--
View this message in context:
http://apache-ignite-users.70518.x6.nabble.com/Hibernate-L2-cache-transactions-tp1460p1474.html
Sent from the Apache Ignite Users mailing list arc
Hi guys:
Oh, sorry for the confusion. I do have it but it's nearly 1M in size so I
will try to get it to you offline.
Dan
--
View this message in context:
http://apache-ignite-users.70518.x6.nabble.com/Hibernate-L2-cache-transactions-tp1460p1473.html
Sent from the Apache Ignite Users mailing
Hi Val:
Here's the full stack trace. The thread is running from a
ScheduledExecutorService that we implemented on top of Ignite which you can
see in our Grails plugin source code:
https://github.com/dstieglitz/grails-ignite
After some time (the amount of time varies, sometimes hours, some
Hi Val:
Unfortunately it won't be possible to share a test case unless I get some
time to build a SSCCE. What does the stack trace indicate? Is that a lock on
a cache somewhere?
Dan
--
View this message in context:
http://apache-ignite-users.70518.x6.nabble.com/Hibernate-L2-cache-transactions
19 matches
Mail list logo
