Do you have a log4j2.xml on your classpath?
Ralph
> On Dec 14, 2017, at 11:04 AM, sherryhw wrote:
>
> Thanks.
> However I checked the log4j 2 is in my pom and it is in my classpath. So I
> guess it is not this cause?
> Sherry
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabbl
Log4j 2 won’t find that because it is config/log4j2.xml and it is looking for
log4j2.xml on the classpath.
Ralph
> On Dec 14, 2017, at 11:07 AM, sherryhw wrote:
>
> It is in "target/classes/config/log4j2.xml"
> Is this what you mentioned?
>
>
>
> --
> Sent from: http://apache-ignite-users.7
to see if the
file is ever being configured.
Ralph
> On Dec 14, 2017, at 11:09 AM, Ralph Goers wrote:
>
> Log4j 2 won’t find that because it is config/log4j2.xml and it is looking for
> log4j2.xml on the classpath.
>
> Ralph
>
>> On Dec 14, 2017, at 11:07 AM, sherr
Did you add the status=“DEBUG”? I suspect that log4j is being initialized
before ignite starts and then Ignite is trying to reconfigure it. Previously
you had no log4j2.xml so the initial configuration failed but Ignite’s probably
worked. Once you moved the file the initial configuration worked
really doesn’t belong there.
Ralph
> On Dec 14, 2017, at 12:00 PM, Ralph Goers wrote:
>
> Did you add the status=“DEBUG”? I suspect that log4j is being initialized
> before ignite starts and then Ignite is trying to reconfigure it. Previously
> you had no log4j2.xml
We are running an application on 2 servers with each running Ignite in a
cluster. As the logs show below at some point the nodes had trouble
communicating with each other. What I would really like to know is why one of
the nodes seemed to recover and the other node did not. Is there something I
We didn’t have gc logging enabled. I can certainly enable it to for the future
but that still leaves me wondering why Ignite didn’t “re-discover” the node
once the garbage collection finished.
Ralph
> On Jan 17, 2018, at 10:35 AM, ilya.kasnacheev
> wrote:
>
> Hello!
>
> 2018-01-04 22:16:12
It seems we did have Splunk collection garbage collection stats via JMX. I see
no Full GCs happening at that time. There are minor GCs but they happen fairly
frequently and don’t use much CPU time.
Ralph
> On Jan 17, 2018, at 10:52 AM, Ralph Goers wrote:
>
> We didn’t have gc loggin
Thanks for the info.
JVM_RESTART won’t work for us because this a web application running in Tomcat
using Ignite for a distributed cache. JVM_RESTART is documented as only working
in a command line application.
The problem we experienced was bad since our load balancer didn’t realize one
of th
Also, I suppose another option would be to handle the event by telling our load
balancer to take the node out of the cluster but then have Ignite reattempt to
reconnect, but I have no idea how I could tell Ignite how to do that.
Ralph
> On Jan 18, 2018, at 9:10 AM, Ralph Goers wr
Yeah, that is wha I thought. But Ignite is wired with Spring so that would mean
restarting the whole ApplicationContext.
Ralph
> On Jan 18, 2018, at 10:37 AM, ilya.kasnacheev
> wrote:
>
> Hello Ralph!
>
> I imagine if your Ignite is running inside a web container, it is the
> responsibility
I have an application that is using Ignite for a clustered cache. Each member
of the cache will have connections open with a third party application. When a
cluster member stops its connections must be re-established on other cluster
members.
I can do this manually if I have a way of detectin
of cluster. Client node is isolated from data processing and not
> subject fail of load.
> Why are you connect each node with third party application instead of to do
> that only from client?
>
> On Sat, Apr 23, 2016 at 4:10 AM, Ralph Goers <mailto:ralph.go...@dslextreme.com&g
EVT_NODE_FAILED
to be considered local events, so I am a bit confused as to what the method
does.
Ralph
> On Apr 23, 2016, at 6:49 AM, Ralph Goers wrote:
>
> From what I understand in the documentation client mode will mean I will lose
> high availability, which is the point of using a distr
t remote node went down".
>
> Vladimir.
>
>> On Sat, Apr 23, 2016 at 5:48 PM, Ralph Goers
>> wrote:
>> Some more information that may be of help.
>>
>> Each user of a client application creates a “session” that is represented in
>> the distributed cache. Eac
u should not perform heavy and blocking
> operations in the callback as it might have adverse effects on nodes
> communication. Instead, it is better to move heavy operations into separate
> thread or thread pool.
>
> Vladimir.
>
> On Mon, Apr 25, 2016 at 2:54 PM, Ralph Goer
That is not strictly correct. You can do objective performance testing of
Ignite and compare that to other solutions, where it is allowed (which it
typically would be for other open source solutions). When you do this, it
should be done in a way that helps users understand how to best configure
17 matches
Mail list logo
