Re: Tuning parameters for performance of ignite Persistence store

[rishi007bansod]

Hi,
 I have tried settings you have mentioned for WAL, it improves
performance in case of WAL write. But when check pointing process
starts(default - after 3 mins), caching process slows down(almost stops). Is
there any way by which we can write checkpoint to disk in background, so
that caching throughput is improved?
 Also, though I have connected 3 disks to my machine only 1 is getting
used while writing, is there any way by which I can use all 3 of them?  

Thanks,
Rishikesh



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Tuning-parameters-for-performance-of-ignite-Persistence-store-tp16051p16072.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

OOM in Heap though offHeap is available/free

[Amit Pundir]

Hi,

I am using onHeap along with the default offHeap memory in my Ignite 2.0
server nodes. I am getting out of memory error even though there is enough
memory available offHeap.

My understanding (based on my earlier posts) is that onHeap is just a cache
for offHeap. If that's how it works then the heap space should never fill up
if there is space available offHeap.

Could you please help me understand how these 2 memories work with each
other. The exception I have got is pasted below.


Thanks


[19:30:14,582][SEVERE][grid-nio-worker-tcp-comm-2-#23%NRO%][GridDirectParser]
Failed to read message [msg=GridIoMessage [plc=0, topic=null, topicOrd=-1,
ordered=false, timeout=0, skipOnTimeout=false, msg=null],
buf=java.nio.DirectByteBuffer[pos=176 lim=20272 cap=32768],
reader=DirectMessageReader [state=DirectMessageState [pos=0,
stack=[StateItem [stream=DirectByteBufferStreamImplV2
[buf=java.nio.DirectByteBuffer[pos=176 lim=20272 cap=32768],
baseOff=139667108316592, arrOff=-1, tmpArrOff=0, tmpArrBytes=0,
msgTypeDone=true, msg=GridDhtTxPrepareRequest [nearNodeId=null, futId=null,
miniId=0, topVer=null, invalidateNearEntries=null, nearWrites=null,
owned=null, nearXidVer=null, subjId=null, taskNameHash=0, preloadKeys=null,
super=GridDistributedTxPrepareRequest [threadId=164,
concurrency=PESSIMISTIC, isolation=REPEATABLE_READ,
writeVer=GridCacheVersion [topVer=113311658, order=1501950546676,
nodeOrder=6], timeout=56261, reads=null, writes=null, dhtVers=null,
txSize=0, plc=2, txState=null, flags=onePhaselast,
super=GridDistributedBaseMessage [ver=GridCacheVersion [topVer=113311658,
order=1501950546597, nodeOrder=6], committedVers=null, rolledbackVers=null,
cnt=0, super=GridCacheMessage [msgId=1294187, depInfo=null, err=null,
skipPrepare=false, cacheId=0, cacheId=0, mapIt=null, it=null, arrPos=-1,
keyDone=false, readSize=-1, readItems=0, prim=0, primShift=0, uuidState=0,
uuidMost=0, uuidLeast=0, uuidLocId=0, lastFinished=true], state=0],
StateItem [stream=DirectByteBufferStreamImplV2
[buf=java.nio.DirectByteBuffer[pos=176 lim=20272 cap=32768],
baseOff=139667108316592, arrOff=-1, tmpArrOff=0, tmpArrBytes=0,
msgTypeDone=true, msg=IgniteTxEntry [key=BinaryObjectImpl [arr= true,
ctx=false, start=0], cacheId=1593518529, txKey=null, val=[op=NOOP,
val=null], prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null],
entryProcessorsCol=null, ttl=-1, conflictExpireTime=-1, conflictVer=null,
explicitVer=null, dhtVer=null, filters=null, filtersPassed=false,
filtersSet=false, entry=null, prepared=0, locked=false, nodeId=null,
locMapped=false, expiryPlc=null, transferExpiryPlc=false, flags=0,
partUpdateCntr=0, serReadVer=null, xidVer=null], mapIt=null, it=null,
arrPos=-1, keyDone=false, readSize=1, readItems=0, prim=0, primShift=0,
uuidState=0, uuidMost=0, uuidLeast=0, uuidLocId=0, lastFinished=true],
state=0], StateItem [stream=DirectByteBufferStreamImplV2
[buf=java.nio.DirectByteBuffer[pos=176 lim=20272 cap=32768],
baseOff=139667108316592, arrOff=-1, tmpArrOff=0, tmpArrBytes=0,
msgTypeDone=true, msg=[op=UPDATE, val=null], mapIt=null, it=null, arrPos=-1,
keyDone=false, readSize=-1, readItems=0, prim=0, primShift=0, uuidState=0,
uuidMost=0, uuidLeast=0, uuidLocId=0, lastFinished=true], state=0],
StateItem [stream=DirectByteBufferStreamImplV2
[buf=java.nio.DirectByteBuffer[pos=176 lim=20272 cap=32768],
baseOff=139667108316592, arrOff=-1, tmpArrOff=0, tmpArrBytes=0,
msgTypeDone=true, msg=BinaryObjectImpl [arr= false, ctx=false, start=0],
mapIt=null, it=null, arrPos=-1, keyDone=false, readSize=-1, readItems=0,
prim=0, primShift=0, uuidState=0, uuidMost=0, uuidLeast=0, uuidLocId=0,
lastFinished=true], state=0], StateItem [stream=DirectByteBufferStreamImplV2
[buf=java.nio.DirectByteBuffer[pos=176 lim=20272 cap=32768],
baseOff=139667108316592, arrOff=-1, tmpArrOff=0, tmpArrBytes=0,
msgTypeDone=false, msg=null, mapIt=null, it=null, arrPos=-1, keyDone=false,
readSize=-1, readItems=0, prim=0, primShift=0, uuidState=0, uuidMost=0,
uuidLeast=0, uuidLocId=0, lastFinished=true], state=0], null, null, null,
null, null]], lastRead=true], ses=GridSelectorNioSessionImpl
[worker=DirectNioClientWorker [super=AbstractNioClientWorker
[selector=sun.nio.ch.EPollSelectorImpl@31cec787, idx=2,
bytesRcvd=428406858156, bytesSent=278366, bytesRcvd0=0, bytesSent0=0,
select=true, super=GridWorker [name=grid-nio-worker-tcp-comm-2,
igniteInstanceName=NRO, finished=false, hashCode=426420385,
interrupted=false, runner=grid-nio-worker-tcp-comm-2-#23%NRO%]]],
writeBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
readBuf=java.nio.DirectByteBuffer[pos=176 lim=20272 cap=32768],
inRecovery=GridNioRecoveryDescriptor [acked=0, resendCnt=0, rcvCnt=139784,
sentCnt=0, reserved=true, lastAck=139776, nodeLeft=false,
node=TcpDiscoveryNode [id=02c2d1ae-3676-4c21-a953-60d81a41c47d,
addrs=[10.120.249.50, 127.0.0.1], sockAddrs=[/127.0.0.1:47500,
/10.120.249.50:47500], discPort=47500, order=6, intOrder=6,
lastExchangeTime=1501831543578, loc=false, 

Re: Platform updates

[vkulichenko]

Hi Luqman,

I meant the service deployment. Most likely, you will do this in init()
method - just call Class.forName() and create the instance of the class.

Makes sense?

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Platform-updates-tp15998p16069.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Query about running SQL with durable memory

[Dmitriy Setrakyan]

On Sat, Aug 5, 2017 at 10:17 PM, iostream  wrote:

> Suppose I have 10 Person entries in the disk, out of which only 5 are
> in-memory. Now if I run a SQL query which is expected to count the number
> of
> entries in Person cache, will the query run only on the disk or RAM or will
> it run on both?
>

The SQL query will simply run over the total data set, which is 10 persons,
but it will obviously process the data that is cached in-memory faster. You
can also speed up SQL queries by indexing the data.


>
> If the query will run on both the disk and RAM, will the count be 10 or 15
> (10 on disk + 5 in RAM)? Does the SQL processor know which entries are
> present in-memory to resolve duplicates?
>
>
If I understand your example correctly, then the super-set of data is 10
Persons (right?). In this case, the total count returned by Ignite will be
10.


>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Query-about-running-SQL-with-
> durable-memory-tp16015.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: Caused by: org.h2.jdbc.JdbcSQLException: General error: "java.lang.IllegalMonitorStateException: Attempted to release write lock while not holding it

[Neelesh]

java 1.7.0_67 definitely has this issue with ignite 1.9, 2.0 and 2.1. We do
not see this issue with java 8

On Tue, Aug 8, 2017 at 6:56 AM, Evgenii Zhuravlev 
wrote:

> I tried your code with java 1.7.0_80-b15 and everything works fine.
>
> Also, check that you use right config file - you provided a file with name
> ignite-config.xml.xml, but in the code, you use ignite-config-login.xml.
>
> Evgenii
>
> 2017-08-08 16:44 GMT+03:00 Evgenii Zhuravlev :
>
>> Yes, It's possible to check the last update of java 1.7
>>
>> Evgenii
>>
>> 2017-08-08 16:42 GMT+03:00 Ankit Singhai :
>>
>>> Even disabling TLS/SSL doesn't have any effect. Moving to Java 1.8 is
>>> not an
>>> option as we have other dependencies which are incompatible with 1.8.
>>>
>>> Any other suggestion?
>>>
>>> Regards,
>>> Ankit Singhai
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context: http://apache-ignite-users.705
>>> 18.x6.nabble.com/Caused-by-org-h2-jdbc-JdbcSQLException-Gene
>>> ral-error-java-lang-IllegalMonitorStateException-Attemptet-t
>>> p15684p16054.html
>>> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>>>
>>
>>
>

Re: Streaming test

[vkulichenko]

Jessie,

What do you mean by "stuck"? Did you check thread dumps? Is it possible you
have memory/GC issues?

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Streaming-test-tp14039p16066.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Ignite behaving strange with Spark SharedRDD in AWS EMR Yarn Client Mode

[vkulichenko]

IgniteContext does not create any executors, Spark does. And frankly I don't
know why you have so many, I was not able to reproduce it myself.

As for large number of tasks, only assumption I can make is that your cache
doesn't actually have any data, which forces Spark to scan ALL partitions to
find 5 elements, and default number of partitions is 1024. However, in this
case issue should've gone away when you decreased number of partitions.

May be you can provide a self contained project that can be ran to reproduce
the issue?

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Ignite-behaving-strange-with-Spark-SharedRDD-in-AWS-EMR-Yarn-Client-Mode-tp16011p16065.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: GA Grid (Beta): Genetic Algorithm component for Ignite is here!

[Dmitriy Setrakyan]

Thanks, Turik, very interesting!

On Mon, Aug 7, 2017 at 8:58 PM, techbysample  wrote:

> Igniters,
>
> Check out the new GA Grid(Beta) project here:
>
> https://github.com/techbysample/gagrid
>
> GA Grid (Beta) is a distributive in memory Genetic Algorithm (GA) component
> for Apache Ignite.
> A GA is a method of solving optimization problems by simulating the process
> of biological evolution.
>
> GAs are excellent for searching through large and complex data sets for an
> optimal solution.
> Real world applications of GAs include:  automotive design, computer
> gaming,
> robotics, investments,
> traffic/shipment routing and more.
>
>
>  GAGrid_Overview.png>
>
> Best,
> Turik Campbell
>
>
>
>
> --
> View this message in context: http://apache-ignite-users.705
> 18.x6.nabble.com/GA-Grid-Beta-Genetic-Algorithm-component-
> for-Ignite-is-here-tp16041.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: Streaming test

[Jessie Lin]

Val, I replace atomicSequence with atomicLong and used the method below.
I need to specify an initial value, start, according to requirement.

return ignite.atomicLong(
"id", //  name.
start,   // Initial value
true // Create if it does not exist.
);

But the process got stuck as well.
Shall I do something differently? Appreciate your advice.

Best,
Jessie

On Tue, Jul 25, 2017 at 7:55 PM, Jessie Lin 
wrote:

> Thank you Val. I'll give it a try.
>
> On Tue, Jul 25, 2017 at 5:16 PM, vkulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
>> Jessie,
>>
>> atomicLong() method will do this for you automatically. It either creates
>> new instance or returns existing one. There is no need for separate
>> initialization step.
>>
>> -Val
>>
>>
>>
>> --
>> View this message in context: http://apache-ignite-users.705
>> 18.x6.nabble.com/Streaming-test-tp14039p15646.html
>> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>>
>
>

Re: Tuning parameters for performance of ignite Persistence store

[vkulichenko]

When you add persistence, latency of each individual updates gets bigger,
because you update disk as well. In case you test on the same amount of
parallel threads, throughput will obviously go down. However, if you
increase the load, i.e. execute more operations in parallel, throughput will
go back up as long as you're not running out of resources.

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Tuning-parameters-for-performance-of-ignite-Persistence-store-tp16051p16061.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Ignite behaving strange with Spark SharedRDD in AWS EMR Yarn Client Mode

[raksja]

Thanks for your reply Val.

We tried that, now it stopped spinning up several servers, all of those
became clients now (I still dont know the difference). But still just for a
single row rdd it takes several minutes to retrieve it. 

It still spins up 100s of executor even though i specify 1 executor 1 core.
When digged deeper, i think its creating way too many tasks, more than 1000,
so its making existing executor to backlog and making spark to spin up new
executors to process. 

If this is the expected behaviour, then I'm not sure Ignite SharedRDD is
tested enough and is functional.

Just for reference, i will create a bug as well on this behaviour and adding
code snippet of my consumer (Its slightly tweaked version of the SharedRDD
example in github).

val ccfg = new CacheConfiguration[Int, AssetWTag]()
ccfg.setName(args(0).toString)
ccfg.setIndexedTypes(classOf[Int], classOf[AssetWTag])
//ccfg.setCacheMode(CacheMode.REPLICATED)
//ccfg.setAtomicityMode(CacheAtomicityMode.ATOMIC)
//ccfg.setBackups(0)
//ccfg.setAffinity(new RendezvousAffinityFunction(false, 1));
igniteContext.ignite().addCacheConfiguration(ccfg)

// Retrieve sharedRDD back from the Cache.
val transformedValues: IgniteRDD[Int, SomeEntity] =
igniteContext.fromCache(ccfg)

println(">>> Transforming values stored in Ignite Shared RDD...")

// Filter out pairs which square roots are less than 100 and
// take the first five elements from the transformed IgniteRDD and print
them.
transformedValues.take(5).foreach(println) // THIS RETURNS 1 ROW AFTER
SPINNING UP 100 EXECUTORS, AROUND 1.5 mins

println(">>> Executing SQL query over Ignite Shared RDD...")

// Execute a SQL query over the Ignite Shared RDD.
val df = transformedValues.sql("select * from SomeEntity")

// Show ten rows from the result set.
df.show(10)  // THIS ALWAYS RETURNS EMPTY
vkulichenko wrote
> Looks like executors start additional server nodes, while they should be
> in client mode instead when standalone mode is used. I would recommend to
> explicitly provide clientMode=true property in the config provided to
> IgniteContext.
> 
> I also created a ticket for this:
> https://issues.apache.org/jira/browse/IGNITE-5981
> 
> -Val





--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Ignite-behaving-strange-with-Spark-SharedRDD-in-AWS-EMR-Yarn-Client-Mode-tp16011p16059.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Ignite suitable for jobs returning fairly large data sets ?

[afedotov]

Hello,

Please properly subscribe to the mailing list so that the community can
receive email notifications for your messages. To subscribe, send an empty
email to user-subscr...@ignite.apache.org and follow simple instructions in
the reply.

Ignite can cope with such cases but it's highly dependent on the total
amount of data being sent.
Depending on the load and the overall case, such kind of jobs may do the
work. Another option is storing the job results in a cache thus propagating
them to other nodes.


Kind regards,
Alex.

On Tue, Aug 8, 2017 at 5:43 PM, Guilherme [via Apache Ignite Users] <
ml+s70518n1605...@n6.nabble.com> wrote:

> Hello,
>
> Can Ignite handle jobs that return a few Mb to the task that spawned them
> ? I've searched for examples, but so far all I can find is jobs doing some
> simple computation like count words/letters and return an Integer. If you
> have jobs returning like say 2~10Mb worth of data, would the system be able
> to cope with that ?
>
> Can anyone point me to any example/resources that relate to this scenario
> ?
>
> Thanks.
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://apache-ignite-users.70518.x6.nabble.com/Ignite-
> suitable-for-jobs-returning-fairly-large-data-sets-tp16057.html
> To start a new topic under Apache Ignite Users, email
> ml+s70518n1...@n6.nabble.com
> To unsubscribe from Apache Ignite Users, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Ignite-suitable-for-jobs-returning-fairly-large-data-sets-tp16057p16058.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Caused by: org.h2.jdbc.JdbcSQLException: General error: "java.lang.IllegalMonitorStateException: Attempted to release write lock while not holding it

[Evgenii Zhuravlev]

I tried your code with java 1.7.0_80-b15 and everything works fine.

Also, check that you use right config file - you provided a file with name
ignite-config.xml.xml, but in the code, you use ignite-config-login.xml.

Evgenii

2017-08-08 16:44 GMT+03:00 Evgenii Zhuravlev :

> Yes, It's possible to check the last update of java 1.7
>
> Evgenii
>
> 2017-08-08 16:42 GMT+03:00 Ankit Singhai :
>
>> Even disabling TLS/SSL doesn't have any effect. Moving to Java 1.8 is not
>> an
>> option as we have other dependencies which are incompatible with 1.8.
>>
>> Any other suggestion?
>>
>> Regards,
>> Ankit Singhai
>>
>>
>>
>>
>> --
>> View this message in context: http://apache-ignite-users.705
>> 18.x6.nabble.com/Caused-by-org-h2-jdbc-JdbcSQLException-Gene
>> ral-error-java-lang-IllegalMonitorStateException-Attemptet-
>> tp15684p16054.html
>> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>>
>
>

Re: Caused by: org.h2.jdbc.JdbcSQLException: General error: "java.lang.IllegalMonitorStateException: Attempted to release write lock while not holding it

[Ankit Singhai]

Even disabling TLS/SSL doesn't have any effect. Moving to Java 1.8 is not an
option as we have other dependencies which are incompatible with 1.8.

Any other suggestion?

Regards,
Ankit Singhai




--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Caused-by-org-h2-jdbc-JdbcSQLException-General-error-java-lang-IllegalMonitorStateException-Attemptet-tp15684p16054.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Tuning parameters for performance of ignite Persistence store

[Alexey Kukushkin]

Hi,
You could try tuning persistence store update reliability vs. performance 
trade-opff by setting walMode to:
DEFAULT: every update is flushed to disk (sync). Least performant but survives 
power loss.
LOG_ONLY: OS-managed buffered output (write). Survives process crash but not OS 
crash.
BACKGROUND: updates are queued in-memory and flushed every 2 seconds.
For example, queue WAL updates in memory and flush them to disk every 5 
seconds:



LOG_ONLY could be a good trade-off.
Best regards, Alexey


On Tuesday, August 8, 2017, 4:19:37 PM GMT+3, rishi007bansod 
 wrote:

Hi,
    I am trying to use persistent store for my application, w/o persistent
store I am getting caching rate of about 280K msgs /sec (1 msg - 512 bytes).
Whereas when I use persistent store in Ignite 2.1.0 then throughput
decreases to 20 K msgs/sec. So,
1. what are tuning parameters that i can try to improve persistent store
efficiency(i have tried increasing checkpoint threads, checkpoint freq but
still performance is same)
2. Also in my set up I have 3 disks connected to machine, but persistent
store only uses one disk for writing, so how can I improve performance in
this case by utilizing all 3 disks?

 

As shown above only disk sda is used whereas sdb is idle all the time.

Thanks,
Rishikesh



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Tuning-parameters-for-performance-of-ignite-Persistence-store-tp16051.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Caused by: org.h2.jdbc.JdbcSQLException: General error: "java.lang.IllegalMonitorStateException: Attempted to release write lock while not holding it

[Evgenii Zhuravlev]

I would suggest updating to the last version of java and check if it will
work. I can't reproduce same behavior with your code, but I use java
1.8.0_121-b13.

Please share results after updating.

Evgenii

2017-08-08 15:28 GMT+03:00 Ankit Singhai :

> PFA log. No luck even by setting the flag for IPV4 = true.
> ignite-de5180fb.zip
>  n16050/ignite-de5180fb.zip>
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Caused-by-org-h2-jdbc-JdbcSQLException-
> General-error-java-lang-IllegalMonitorStateException-
> Attemptet-tp15684p16050.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: I am not able to read mxbean values of ignite

[slava.koptilin]

Hello,

The reason whyr mxbean is false that Apache Ignite "exports" its own beans
as DynamicBean.

I've tried logstash 5.5.1 with logstash-input-jmx 3.0.2 plugin
I've used the following jmx configuration that is gathering simple
statistics about MyTestCache, DiscoverySpi and CommunicationSpi:
{
"host" : "localhost",
"port" : ,
"queries" : [
  {
  "object_name" :
"org.apache:clsLdr=*,group=MyTestCache,name=org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl",
  "object_alias" : "CacheStatistics",
  "attributes" : ["StatisticsEnabled","Size"]
  },
  {
  "object_name" :
"org.apache:clsLdr=*,group=SPIs,name=TcpDiscoverySpi",
  "object_alias" : "TcpDiscoverySpi",
  "attributes" : ["Coordinator","IgniteHome","ClientMode"]
  },
  {
  "object_name" :
"org.apache:clsLdr=*,group=SPIs,name=TcpCommunicationSpi",
  "object_alias" : "TcpCommunicationSpi",
  "attributes" : ["ConnectTimeout","LocalNodeId","LocalPort"]
  } 
   ]
}

You have two options to specify JMX port:
1. set environment variable  IGNITE_JMX_PORT
2. pass the following system parameters to your JVM:
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port={preferred_port}
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false

And it works good:
[2017-08-08T14:25:45,614][INFO ][logstash.inputs.jmx  ] Loading
configuration files in path {:path=>"/home/slava/logstash-5.5.1/jmx"}
{
"metric_value_number" => 0,
   "path" => "/home/slava/logstash-5.5.1/jmx",
 "@timestamp" => 2017-08-08T11:25:45.630Z,
   "@version" => "1",
   "host" => "localhost",
"metric_path" =>
"localhost_49117.CacheStatistics.StatisticsEnabled_bool",
   "type" => "jmx"
}
{
"metric_value_number" => 0,
   "path" => "/home/slava/logstash-5.5.1/jmx",
 "@timestamp" => 2017-08-08T11:25:45.635Z,
   "@version" => "1",
   "host" => "localhost",
"metric_path" => "localhost_49117.CacheStatistics.Size",
   "type" => "jmx"
}
{
   "path" => "/home/slava/logstash-5.5.1/jmx",
 "@timestamp" => 2017-08-08T11:25:45.639Z,
   "@version" => "1",
   "host" => "localhost",
"metric_path" => "localhost_49117.TcpDiscoverySpi.Coordinator",
   "type" => "jmx",
"metric_value_string" => "f642dc26-3af0-4ba1-ba13-1fb361e7c6f5"
}
{
   "path" => "/home/slava/logstash-5.5.1/jmx",
 "@timestamp" => 2017-08-08T11:25:45.640Z,
   "@version" => "1",
   "host" => "localhost",
"metric_path" => "localhost_49117.TcpDiscoverySpi.IgniteHome",
   "type" => "jmx",
"metric_value_string" => "/projects/binaries/fabric.2.1.0"
}
{
"metric_value_number" => 0,
   "path" => "/home/slava/logstash-5.5.1/jmx",
 "@timestamp" => 2017-08-08T11:25:45.640Z,
   "@version" => "1",
   "host" => "localhost",
"metric_path" =>
"localhost_49117.TcpDiscoverySpi.ClientMode_bool",
   "type" => "jmx"
}
{
"metric_value_number" => 5000,
   "path" => "/home/slava/logstash-5.5.1/jmx",
 "@timestamp" => 2017-08-08T11:25:45.661Z,
   "@version" => "1",
   "host" => "localhost",
"metric_path" =>
"localhost_49117.TcpCommunicationSpi.ConnectTimeout",
   "type" => "jmx"
}
{
   "path" => "/home/slava/logstash-5.5.1/jmx",
 "@timestamp" => 2017-08-08T11:25:45.662Z,
   "@version" => "1",
   "host" => "localhost",
"metric_path" =>
"localhost_49117.TcpCommunicationSpi.LocalNodeId",
   "type" => "jmx",
"metric_value_string" => "f642dc26-3af0-4ba1-ba13-1fb361e7c6f5"
}
{
"metric_value_number" => 47100,
   "path" => "/home/slava/logstash-5.5.1/jmx",
 "@timestamp" => 2017-08-08T11:25:45.663Z,
   "@version" => "1",
   "host" => "localhost",
"metric_path" =>
"localhost_49117.TcpCommunicationSpi.LocalPort",
   "type" => "jmx"
}

Thanks,
Slava.



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/I-am-not-able-to-read-mxbean-values-of-ignite-tp16022p16049.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Caused by: org.h2.jdbc.JdbcSQLException: General error: "java.lang.IllegalMonitorStateException: Attempted to release write lock while not holding it

[ezhuravlev]

Hi,
I tried to run your code on Linux, but everything works fine for me. One
thing - I don't see SSL configuration in your config files, while your log
contains information that SSL was enabled. Is the same behavior reproducible
without SSL?

Also, I see that you use both ipv4 and ipv6, possibly it could lead to the
problem that was shown in the log - when a client was unable to connect to
the server at the first time. Try to run all nodes with
-Djava.net.preferIPv4Stack=true property.






--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Caused-by-org-h2-jdbc-JdbcSQLException-General-error-java-lang-IllegalMonitorStateException-Attemptet-tp15684p16046.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: ignite visor not workin in case ignite is started from a tomcat

[neerajbhatt]

Hi Alexey

Thanks, we found the issue. We were not giving port in config xml through
which we were connecting ignitevisor

Thanks



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/ignite-visor-not-workin-in-case-ignite-is-started-from-a-tomcat-tp16043p16045.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: ignite visor not workin in case ignite is started from a tomcat

[Alexey Kuznetsov]

Hi!

Can you prepare a simple project to reproduce the issue?
Also please specify versions of Ignite and Tomcat.

On Tue, Aug 8, 2017 at 1:18 PM, neerajbhatt 
wrote:

> Hi All
>
> We have a web application deployed in tomcat, from which we are starting
> ignite server
> It seems in this scenario ignite visor is not able to detect ignite
> instance.
>
> In case we start ignite from a java class(not through tomcat), ignite visor
> is able to connect to ignite and give cache details
>
> Please suggest how we can use ignite visor (in case ignite s started from a
> tomcat)
>
> Thanks
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/ignite-visor-not-workin-in-case-
> ignite-is-started-from-a-tomcat-tp16043.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>



-- 
Alexey Kuznetsov

ignite visor not workin in case ignite is started from a tomcat

[neerajbhatt]

Hi All

We have a web application deployed in tomcat, from which we are starting
ignite server
It seems in this scenario ignite visor is not able to detect ignite
instance.

In case we start ignite from a java class(not through tomcat), ignite visor
is able to connect to ignite and give cache details

Please suggest how we can use ignite visor (in case ignite s started from a
tomcat)

Thanks



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/ignite-visor-not-workin-in-case-ignite-is-started-from-a-tomcat-tp16043.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: I am not able to read mxbean values of ignite

[neerajbhatt]

mxbean in MBeaninfo of a particluar cache is coming as false, because of
which logstash jmx plugin is not able to get data.

I am also facing the same problem

we have used
cacheCfg.setStatisticsEnabled(true);
cacheCfg.setManagementEnabled(true);

Attributes values are coming in jconsole but probably becuase in MBeaninfo
mxbean is false we are not able to fetch values in logstash



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/I-am-not-able-to-read-mxbean-values-of-ignite-tp16022p16042.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.