date:20170502

Re: Distributed Closures VS Executor Service

2017-05-02 Thread Sergi Vladykin

Actually H2 can use index for IN operator, but using JOIN instead of IN may
be still useful.

Sergi

2017-05-01 12:40 GMT+03:00 Nikolai Tikhonov :

> Hi,
>
> The page [1] contains also workaround for IN operation. You can use JOIN
> instead of IN.
>
> Sergi,
>
> Will this tip actual for 2.0 version yet?
>
> 1. https://apacheignite.readme.io/docs/sql-performance-and-debugging#sql-
> performance-and-usability-considerations
>
> On Sun, Apr 30, 2017 at 1:50 PM, kmandalas  iriworldwide.com> wrote:
>
>> After investigation more I run into the following:
>>
>> https://apacheignite.readme.io/docs/sql-performance-and-debu
>> gging#sql-performance-and-usability-considerations
>>
>> So, cause my query has IN clause no indexing will be used anyway.
>>
>> Could you please elaborate more on this topic and if/what will change at
>> version 2.0? Should I open a different topic better?
>>
>>
>>
>> --
>> View this message in context: http://apache-ignite-users.705
>> 18.x6.nabble.com/Distributed-Closures-VS-Executor-Service-t
>> p11192p12314.html
>> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>>
>
>

Re: Distributed Closures VS Executor Service

2017-05-02 Thread kmandalas

Hello,

I don't know about H2, I sent you link from apacheignite.readme.io which
describes that IN clause does not support Indexes when run on Ignite. Also
at my previous post I have sent a simply query using IN clause that has very
poor performance on Ignite even run only on local mode with less than 2
million entries.

So could you please provide a concrete feedback? 



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Distributed-Closures-VS-Executor-Service-tp11192p12335.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Write-behind Flush Size

2017-05-02 Thread Ricky Nauvaldy Ruliputra

Hello,
Currently, I'm trying to do a write-behind caching depending on the flush
size (I set the writeBehindFlushSize to a number, and set the
writeBehindFlushFrequency to 0). I read the documentation [1], and it said
that the default writeBehindFlushSize is 10240. What is this number
actually? Is it in bytes? When will the cache actually be flushed? My data
is the same as the one in [2]. I tried to put some inputs, and nothing
happened. But when I stop the node by calling /Ignite.stop(true)/, the data
in the cache is written to the store. Did I miss something? 

FYI I already suceeded the write behind using writeBehindFlushFrequency, but
this is another case. I also want to use write behind using
writeBehindFlushSize so I might use it in another case. Do I only need to
change the writeBehindFlushFrequency and writeBehindFlushSize from the
previous case?

Thanks for any help that you can provide.

[1] https://apacheignite.readme.io/docs/persistent-store
[2]
http://apache-ignite-users.70518.x6.nabble.com/How-to-do-write-behind-caching-td12138.html



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Write-behind-Flush-Size-tp12336.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

CacheStore's Performance Drops Dramatically - Why?

2017-05-02 Thread Matt

Hi all,

I have two questions for you!

*QUESTION 1*

I'm following the example in [1] (a mix between "jdbc transactional" and
"jdbc bulk operations") and I've enabled write behind, however after the
first 10k-20k insertions the performance drops *dramatically*.

Based on prints I've added to the CacheStore, I've noticed what Ignite is
doing is this:

- writeAll called with 512 elements (Ignites buffers elements, that's good)
- openConnection with autocommit=true is called each time inside writeAll
(since session is not stored in atomic mode)
- writeAll is called with 512 elements a few dozen times, each time it
opens a new JDBC connection as mentioned above
- ...
- writeAll called with ONE element (for some reason Ignite stops buffering
elements)
- writeAll is called with ONE element from here on, each time it opens a
new JDBC connection as mentioned above
- ...

Things to note:

- All config values are the defaults ones except for write through and
write behind which are both enabled.
- I'm running this as a server node (only one node on the cluster, the
application itself).
- I see the problem even with a big heap (ie, Ignite is not nearly out of
memory).
- I'm using PostgreSQL for this test (it's fine ingesting around 40k rows
per second on this computer, so that shouldn't be a problem)

What is causing Ignite to stop buffering elements after calling writeAll()
a few dozen times?

*QUESTION 2*

I've read on the docs that using ATOMIC mode (default mode) is better for
performance, but I'm not getting why. If I'm not wrong using TRANSACTIONAL
mode would cause the CacheStore to reuse connections (not call
openConnection(autocommit=true) on each writeAll()).

Shouldn't it be better to use transactional mode?

Regards,
Matt

[1]
https://apacheignite.readme.io/docs/persistent-store#section-cachestore-example

Continuous Query remote listener misses some events or respond really late

2017-05-02 Thread begineer

Hi,
I am currently facing intermittent issue with continuous query. Cant really
reproduce it but if any one faced this issue, please do let me know
My application is deployed on 12 nodes with 5-6 services are used to detect
respective events using continuous query. 
Lets say I have a cache of type 
Cache where Trade is like this
class Trade{
int pkey,
String type

TradeState state;//enum
}
CQ detects the new entry to cache(with updated state) and checks if trade
has the state which matches its remote filter criteria.
A Trade moves from state1-state5. each CQ listens to one stage and do some
processing and move it to next state where next CQ will detect it and act
accordingly.
Problem is sometimes, trade get stuck in some state and does not move. I
have put logs in remote listener Predicate method(which checks the filter
criteria) but these logs don't get printed on console. Some times CQ detect
events after 4-5 hours.
I am using ignite 1.8.2
Does any one seen this behavior, I will be grateful for help extended



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Continuous-Query-remote-listener-misses-some-events-or-respond-really-late-tp12338.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: With same load Ignite is not able to respond after enabling SSL

2017-05-02 Thread Anton Vinogradov

Hi,

I see that code from stack trace you provided was refactored at 1.9,
possible this will fix your issue.

On Fri, Apr 21, 2017 at 3:00 PM, Ankit Singhai  wrote:

> igniteClient.gz
>  n12149/igniteClient.gz>
> server1.gz
> 
> server2.gz
> 
> server3.gz
> 
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/With-same-load-Ignite-is-not-able-to-
> respond-after-enabling-SSL-tp12146p12149.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Ignite SQL Indexing Performance problems

2017-05-02 Thread kmandalas

Hello,

I have a cache in REPLICATED mode populated with the contents of a single DB
table having ~2 million rows.

I am running a simple SQL query like:
select * from simulation_initial_values
where category_id in (1,2,3,4,5,6)
and geo_channel_id in (3,4,5,6) 
and type_id=3 
and week between 1888 and 1939;

I have indexes at all the above fields and the queries are of course
executed in local mode (since I have REPLICATED cache of read-only nature).
The performance of the query is poor, I get warnings in the log and I see
that no indexing is used.

I saw the 
https://apacheignite.readme.io/docs/sql-performance-and-debugging#sql-performance-and-usability-considerations

  
where it says that if a query contains IN operators  then this query will
not use indexes. I followed the alternative approach proposed by replacing
the IN clause with JOIN but still the same poor results. I paste log below:

[14:36:53,479][WARN ][pub-#86%ppsp-cluster-IV%][IgniteH2Indexing] Query
execution is too long [time=7133 ms, sql='select * from
SimulationInitialValues siv  join table(id bigint = ?) c on siv.categoryId =
c.id  join table(id bigint = ?) g on siv.geoChannelId = g.id  and siv.type =
? and siv.week between ? and ?', plan=
SELECT
SIV._KEY,
SIV._VAL,
SIV.ID,
SIV.CATEGORYID,
SIV.GEOCHANNELID,
SIV.GEOID,
SIV.PRODUCTID,
SIV.PPGID,
SIV.TYPE,
SIV.WEEK,
C.ID,
G.ID
FROM "PPSP-IMDG-CACHE".SIMULATIONINITIALVALUES SIV
/* "PPSP-IMDG-CACHE"."type_idx": TYPE = ?3 */
/* WHERE (SIV.TYPE = ?3)
AND ((SIV.WEEK >= ?4)
AND (SIV.WEEK <= ?5))
*/
INNER JOIN TABLE(ID BIGINT=?1) C
/* function: ID = SIV.CATEGORYID
AND ID = SIV.CATEGORYID
 */
ON 1=1
/* WHERE SIV.CATEGORYID = C.ID
*/
INNER JOIN TABLE(ID BIGINT=?2) G
/* function: ID = SIV.GEOCHANNELID
AND ID = SIV.GEOCHANNELID
 */
ON 1=1
WHERE (SIV.CATEGORYID = C.ID)
AND (((SIV.WEEK >= ?4)
AND (SIV.WEEK <= ?5))
AND ((SIV.TYPE = ?3)
AND (SIV.GEOCHANNELID = G.ID)))
, parameters=[[Ljava.lang.Object;@7346a49b, [Ljava.lang.Object;@5458bfc9, 2,
1888, 1939]]

   



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Ignite-SQL-Indexing-Performance-problems-tp12342.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Nodes hanging when accessing queue

2017-05-02 Thread jpmoore40

Hi,

I've been having a couple of issues with a shared IgniteQueue which seem to
occur sporadically. I have a single publisher process which pushes data onto
a queue, and several worker processes that pull the data from the queue and
perform some processing. However these nodes are part of a larger qrid
containing other nodes that submit and process IgniteCallables. I partition
these using an environment variable clusterName=xxx so the IgniteCallables
are only computed on a particular cluster group. This seemed like the best
way of doing things as I am using the TcpDiscoveryJdbcIpFinder and didn't
want to set up a different database for each discrete grid. 

Several times I have found that the publishers and workers accessing the
IgniteQueue stop processing and there seem to be two separate problems
occurring.

The first was that I would get an exception such as the following when a
node was stopped:

java.lang.IllegalStateException: Cache has been stopped: datastructures_0
  at
org.apache.ignite.internal.processors.cache.GridCacheGateway.checkStatus(GridCacheGateway.java:85)
  at
org.apache.ignite.internal.processors.cache.GridCacheGateway.enter(GridCacheGateway.java:68)
  at
org.apache.ignite.internal.processors.datastructures.GridCacheQueueProxy.contains(GridCacheQueueProxy.java:160)
  at
my.com.CrossFxCurvePubService.addToQueue(CrossFxCurvePubService.java:267)
  ...

This I think I solved (i.e. it hasn't happened since) by ensuring that the
CollectionConfiguration was initialised with backups, though if anyone can
confirm that would be helpful. 

However the second problem (which also causes the queue publisher and
workers to stop processing) is accompanied by repeated blocks of messages
such as the following:

2017-04-28 14:08:05,468 WARN  [grid-nio-worker-2-#11%null%] java.JavaLogger
(JavaLogger.java:278) - Failed to process selector key (will close):
GridSelectorNioSessionImpl [selectorIdx=2, queueSize=0,
writeBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
readBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
recovery=GridNioRecoveryDescriptor [acked=9, resendCnt=0, rcvCnt=8,
sentCnt=9, reserved=true, lastAck=8, nodeLeft=false, node=TcpDiscoveryNode
[id=c91ce074-964e-4497-ac77-a3828b301ed3, addrs=[0:0:0:0:0:0:0:1,
10.127.197.150, 127.0.0.1], sockAddrs=[/0:0:0:0:0:0:0:1:0,
/10.127.197.150:0, /127.0.0.1:0], discPort=0, order=161, intOrder=84,
lastExchangeTime=1493384810687, loc=false, ver=1.8.0#20161205-sha1:9ca40dbe,
isClient=true], connected=true, connectCnt=1, queueLimit=5120,
reserveCnt=1], super=GridNioSessionImpl [locAddr=/10.127.246.164:60985,
rmtAddr=/10.127.197.150:47100, createTime=1493384812272, closeTime=0,
bytesSent=73469, bytesRcvd=1053, sndSchedTime=1493384869270,
lastSndTime=1493384831058, lastRcvTime=1493384869270, readsPaused=false,
filterChain=FilterChain[filters=[GridNioCodecFilter
[parser=o.a.i.i.util.nio.GridDirectParser@1b4d47c, directMode=true],
GridConnectionBytesVerifyFilter], accepted=false]]

2017-04-28 14:08:05,470 WARN  [grid-nio-worker-2-#11%null%] java.JavaLogger
(JavaLogger.java:278) - Closing NIO session because of unhandled exception
[cls=class o.a.i.i.util.nio.GridNioException, msg=An existing connection was
forcibly closed by the remote host]

2017-04-28 14:08:14,279 WARN  [disco-event-worker-#20%null%] java.JavaLogger
(JavaLogger.java:278) - Node FAILED: TcpDiscoveryNode
[id=c91ce074-964e-4497-ac77-a3828b301ed3, addrs=[0:0:0:0:0:0:0:1,
10.127.197.150, 127.0.0.1], sockAddrs=[/0:0:0:0:0:0:0:1:0,
/10.127.197.150:0, /127.0.0.1:0], discPort=0, order=161, intOrder=84,
lastExchangeTime=1493384810687, loc=false, ver=1.8.0#20161205-sha1:9ca40dbe,
isClient=true]
2017-04-28 14:08:14,287 INFO  [disco-event-worker-#20%null%] java.JavaLogger
(JavaLogger.java:273) - Topology snapshot [ver=162, servers=6, clients=0,
CPUs=24, heap=3.5GB]
2017-04-28 14:08:14,295 INFO  [exchange-worker-#24%null%] java.JavaLogger
(JavaLogger.java:273) - Skipping rebalancing (nothing scheduled)
[top=AffinityTopologyVersion [topVer=162, minorTopVer=0], evt=NODE_FAILED,
node=c91ce074-964e-4497-ac77-a3828b301ed3]

2017-04-28 14:08:35,853 WARN  [grid-timeout-worker-#7%null%] java.JavaLogger
(JavaLogger.java:278) - Found long running cache future
[startTime=14:06:52.182, curTime=14:08:35.828,
fut=GridPartitionedSingleGetFuture [topVer=AffinityTopologyVersion
[topVer=161, minorTopVer=0], key=UserKeyCacheObjectImpl
[val=GridCacheQueueItemKey
[queueId=9c0396aab51-f5c26da7-4123-4ba7-aa40-857ccd042342,
queueName=cross-fx-curves, idx=519195], hasValBytes=true], readThrough=true,
forcePrimary=false, futId=c8ca4a5cb51-f5c26da7-4123-4ba7-aa40-857ccd042342,
trackable=true, subjId=efe9e46d-6dbd-4ca1-b7fb-7ace46d37571, taskName=null,
deserializeBinary=true, skipVals=false, expiryPlc=null, canRemap=true,
needVer=false, keepCacheObjects=false, node=TcpDiscoveryNode
[id=1bbf12c4-74b7-490d-b3fc-d8b3ef713ac0, addrs=[0:0:0:0:0:0:0:1,
10.127.246.74, 127.0.0.1], sockAddrs=[/0:0:0:0:0:0:0

Re: HDP, Hive + Ignite

2017-05-02 Thread Alena Melnikova

Hi Ivan,

I have some progress)

*1. TEZ on Ignite (with IGFS, without Ignite MR)*
I could run Hive queries on TEZ and Ignite with next settings:
$IGNITE_HOME/bin/ignite.sh -v -J"-Xms10g -Xmx10g -XX:MaxMetaspaceSize=4g"
(every server has RAM 16Gb )
beeline  --hiveconf fs.default.name=igfs://dev-dn1:10500 --hiveconf
ignite.job.shared.classloader=false
set tez.use.cluster.hadoop-libs = true; (to avoid
"java.lang.ClassNotFoundException: Class
org.apache.ignite.hadoop.fs.v1.IgniteHadoopFileSystem not found")
ignite.job.shared.classloader = false; 
hive.rpc.query.plan = true;
hive.execution.engine = tez;
select calday, count(*) from price.toprice where calday between '2017-03-01'
and '2017-03-21' group by calday order by calday;

I run this query 8 times on TEZ+Ingnite and 8 times just on TEZ (without
IGFS), threw out the best and worst result and calculated average.
Results are:
Average execution time TEZ+Ignite: 25 sec
Average execution time just TEZ: 23 sec

Then I run more complex analytical query with joins on the same conditions.
Results are:
Average execution time TEZ+Ignite: 312 sec
Average execution time just TEZ: 313 sec

Results are mostly identical, so I guess IGFS is not used. 
May be I should explicitly tell Hive to cache data in IGFS?
Is there any way to understand that Ignite is used besides measuring
execution time?


*2. Ignite MR (with IGFS, with Ignite MR)*
I could run Hive queries on Ignite MR with next settings: 
$IGNITE_HOME/bin/ignite.sh -v -J"-Xms10g -Xmx10g -XX:MaxMetaspaceSize=4g"
(every server has RAM 16Gb )
beeline  --hiveconf fs.default.name=igfs://dev-dn1:10500 --hiveconf
ignite.job.shared.classloader=false
ignite.job.shared.classloader = false; 
mapreduce.jobtracker.address=dev-dn1.co.vectis.local:11211;
hive.rpc.query.plan = true;
hive.execution.engine = mr;
select calday, count(*) from price.toprice where calday between '2017-03-01'
and '2017-03-21' group by calday order by calday;

If I use one ignite node it returns correct answer but much slower - 80 sec
vs 23 sec on TEZ.
If I run this query on two or more nodes then result is not correct. As I
can see there are no any errors in logs.
What is wrong?
ignite-node-dn1.log

  
ignite-node-dn2.log

  

3. When I start ignite nodes on different servers sometimes they do not see
each other. I have to rerun a node a few times, after that they connect in
one cluster. Is it normal?




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

Re: tcp-disco-ip-finder-cleaner

2017-05-02 Thread Andrey Mashenkov

Hi,

Looks like a bug. Here is a ticket [1].


[1] https://issues.apache.org/jira/browse/IGNITE-5117

On Thu, Apr 27, 2017 at 4:01 PM, gatorjh  wrote:

> Here is the ignite config
>
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/tcp-disco-ip-finder-cleaner-tp12249p12293.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>



-- 
Best regards,
Andrey V. Mashenkov

Re: CacheStore's Performance Drops Dramatically - Why?

2017-05-02 Thread Jessie Lin

Hello Matt, thank you for posting. I've noticed similar behavior.

Would be curious to see the response from the engineering team.

Best,
Jessie

On Tue, May 2, 2017 at 1:03 AM, Matt  wrote:

> Hi all,
>
> I have two questions for you!
>
> *QUESTION 1*
>
> I'm following the example in [1] (a mix between "jdbc transactional" and
> "jdbc bulk operations") and I've enabled write behind, however after the
> first 10k-20k insertions the performance drops *dramatically*.
>
> Based on prints I've added to the CacheStore, I've noticed what Ignite is
> doing is this:
>
> - writeAll called with 512 elements (Ignites buffers elements, that's good)
> - openConnection with autocommit=true is called each time inside writeAll
> (since session is not stored in atomic mode)
> - writeAll is called with 512 elements a few dozen times, each time it
> opens a new JDBC connection as mentioned above
> - ...
> - writeAll called with ONE element (for some reason Ignite stops buffering
> elements)
> - writeAll is called with ONE element from here on, each time it opens a
> new JDBC connection as mentioned above
> - ...
>
> Things to note:
>
> - All config values are the defaults ones except for write through and
> write behind which are both enabled.
> - I'm running this as a server node (only one node on the cluster, the
> application itself).
> - I see the problem even with a big heap (ie, Ignite is not nearly out of
> memory).
> - I'm using PostgreSQL for this test (it's fine ingesting around 40k rows
> per second on this computer, so that shouldn't be a problem)
>
> What is causing Ignite to stop buffering elements after calling writeAll()
> a few dozen times?
>
> *QUESTION 2*
>
> I've read on the docs that using ATOMIC mode (default mode) is better for
> performance, but I'm not getting why. If I'm not wrong using TRANSACTIONAL
> mode would cause the CacheStore to reuse connections (not call
> openConnection(autocommit=true) on each writeAll()).
>
> Shouldn't it be better to use transactional mode?
>
> Regards,
> Matt
>
> [1] https://apacheignite.readme.io/docs/persistent-
> store#section-cachestore-example
>

Re: Distributed Closures VS Executor Service

2017-05-02 Thread kmandalas

Dear all,

I have created a new Topic: "Ignite SQL Indexing Performance problems" since
the conversation has deviate a lot form the original subject.



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Distributed-Closures-VS-Executor-Service-tp11192p12347.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: "object not serializable " when initializing igniteContext with Zookeeper Configuration

2017-05-02 Thread Andrey Mashenkov

Hi,

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

Seems, you provide anonymous class to IgniteContext that has implicit
reference to its non-serializable parent.
Try to make this "() => igcf" static.

-- 
Best regards,
Andrey V. Mashenkov

Re: CacheStore's Performance Drops Dramatically - Why?

2017-05-02 Thread Matt

I'm stuck with that. No matter what config I use (flush size, write
threads, etc) this is the behavior I always get. It's as if Ignite internal
buffer is full and it's trying to write and get rid of the oldest (one)
element only.

Any idea people? What is your CacheStore configuration to avoid this?

On Tue, May 2, 2017 at 11:50 AM, Jessie Lin 
wrote:

> Hello Matt, thank you for posting. I've noticed similar behavior.
>
> Would be curious to see the response from the engineering team.
>
> Best,
> Jessie
>
> On Tue, May 2, 2017 at 1:03 AM, Matt  wrote:
>
>> Hi all,
>>
>> I have two questions for you!
>>
>> *QUESTION 1*
>>
>> I'm following the example in [1] (a mix between "jdbc transactional" and
>> "jdbc bulk operations") and I've enabled write behind, however after the
>> first 10k-20k insertions the performance drops *dramatically*.
>>
>> Based on prints I've added to the CacheStore, I've noticed what Ignite is
>> doing is this:
>>
>> - writeAll called with 512 elements (Ignites buffers elements, that's
>> good)
>> - openConnection with autocommit=true is called each time inside writeAll
>> (since session is not stored in atomic mode)
>> - writeAll is called with 512 elements a few dozen times, each time it
>> opens a new JDBC connection as mentioned above
>> - ...
>> - writeAll called with ONE element (for some reason Ignite stops
>> buffering elements)
>> - writeAll is called with ONE element from here on, each time it opens a
>> new JDBC connection as mentioned above
>> - ...
>>
>> Things to note:
>>
>> - All config values are the defaults ones except for write through and
>> write behind which are both enabled.
>> - I'm running this as a server node (only one node on the cluster, the
>> application itself).
>> - I see the problem even with a big heap (ie, Ignite is not nearly out of
>> memory).
>> - I'm using PostgreSQL for this test (it's fine ingesting around 40k rows
>> per second on this computer, so that shouldn't be a problem)
>>
>> What is causing Ignite to stop buffering elements after calling
>> writeAll() a few dozen times?
>>
>> *QUESTION 2*
>>
>> I've read on the docs that using ATOMIC mode (default mode) is better for
>> performance, but I'm not getting why. If I'm not wrong using TRANSACTIONAL
>> mode would cause the CacheStore to reuse connections (not call
>> openConnection(autocommit=true) on each writeAll()).
>>
>> Shouldn't it be better to use transactional mode?
>>
>> Regards,
>> Matt
>>
>> [1] https://apacheignite.readme.io/docs/persistent-store#
>> section-cachestore-example
>>
>
>

Re: CacheStore's Performance Drops Dramatically - Why?

2017-05-02 Thread Jessie Lin

I noticed that behavior when any cache.remove operation is involved. I keep
putting stuff in cache seems to be working properly.

Do you use remove operation?

On Tue, May 2, 2017 at 9:57 AM, Matt  wrote:

> I'm stuck with that. No matter what config I use (flush size, write
> threads, etc) this is the behavior I always get. It's as if Ignite internal
> buffer is full and it's trying to write and get rid of the oldest (one)
> element only.
>
> Any idea people? What is your CacheStore configuration to avoid this?
>
> On Tue, May 2, 2017 at 11:50 AM, Jessie Lin 
> wrote:
>
>> Hello Matt, thank you for posting. I've noticed similar behavior.
>>
>> Would be curious to see the response from the engineering team.
>>
>> Best,
>> Jessie
>>
>> On Tue, May 2, 2017 at 1:03 AM, Matt  wrote:
>>
>>> Hi all,
>>>
>>> I have two questions for you!
>>>
>>> *QUESTION 1*
>>>
>>> I'm following the example in [1] (a mix between "jdbc transactional" and
>>> "jdbc bulk operations") and I've enabled write behind, however after the
>>> first 10k-20k insertions the performance drops *dramatically*.
>>>
>>> Based on prints I've added to the CacheStore, I've noticed what Ignite
>>> is doing is this:
>>>
>>> - writeAll called with 512 elements (Ignites buffers elements, that's
>>> good)
>>> - openConnection with autocommit=true is called each time inside
>>> writeAll (since session is not stored in atomic mode)
>>> - writeAll is called with 512 elements a few dozen times, each time it
>>> opens a new JDBC connection as mentioned above
>>> - ...
>>> - writeAll called with ONE element (for some reason Ignite stops
>>> buffering elements)
>>> - writeAll is called with ONE element from here on, each time it opens a
>>> new JDBC connection as mentioned above
>>> - ...
>>>
>>> Things to note:
>>>
>>> - All config values are the defaults ones except for write through and
>>> write behind which are both enabled.
>>> - I'm running this as a server node (only one node on the cluster, the
>>> application itself).
>>> - I see the problem even with a big heap (ie, Ignite is not nearly out
>>> of memory).
>>> - I'm using PostgreSQL for this test (it's fine ingesting around 40k
>>> rows per second on this computer, so that shouldn't be a problem)
>>>
>>> What is causing Ignite to stop buffering elements after calling
>>> writeAll() a few dozen times?
>>>
>>> *QUESTION 2*
>>>
>>> I've read on the docs that using ATOMIC mode (default mode) is better
>>> for performance, but I'm not getting why. If I'm not wrong using
>>> TRANSACTIONAL mode would cause the CacheStore to reuse connections (not
>>> call openConnection(autocommit=true) on each writeAll()).
>>>
>>> Shouldn't it be better to use transactional mode?
>>>
>>> Regards,
>>> Matt
>>>
>>> [1] https://apacheignite.readme.io/docs/persistent-store#sec
>>> tion-cachestore-example
>>>
>>
>>
>

Re: CacheStore's Performance Drops Dramatically - Why?

2017-05-02 Thread Matt

No, only with inserts, I haven't tried removing at this rate yet but it may
have the same problem.

I'm debugging Ignite internal code and I may be onto something. The thing
is Ignite has a cacheMaxSize (aka, WriteBehindFlushSize) and
cacheCriticalSize (which by default is cacheMaxSize*1.5). When the cache
reaches that size Ignite starts writing elements SYNCHRONOUSLY, as you can
see in [1].

I think this makes things worse since only one single value is flushed at a
time, it becomes much slower forcing Ignite to do more synchronous writes.

Anyway, I'm still not sure why the cache reaches that level when the
database is clearly able to keep up with the insertions. I'll check if it
has to do with the number of open connections or what.

Any insight on this is very welcome!

[1]
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/store/GridCacheWriteBehindStore.java#L620

On Tue, May 2, 2017 at 2:17 PM, Jessie Lin 
wrote:

> I noticed that behavior when any cache.remove operation is involved. I
> keep putting stuff in cache seems to be working properly.
>
> Do you use remove operation?
>
> On Tue, May 2, 2017 at 9:57 AM, Matt  wrote:
>
>> I'm stuck with that. No matter what config I use (flush size, write
>> threads, etc) this is the behavior I always get. It's as if Ignite internal
>> buffer is full and it's trying to write and get rid of the oldest (one)
>> element only.
>>
>> Any idea people? What is your CacheStore configuration to avoid this?
>>
>> On Tue, May 2, 2017 at 11:50 AM, Jessie Lin > > wrote:
>>
>>> Hello Matt, thank you for posting. I've noticed similar behavior.
>>>
>>> Would be curious to see the response from the engineering team.
>>>
>>> Best,
>>> Jessie
>>>
>>> On Tue, May 2, 2017 at 1:03 AM, Matt  wrote:
>>>
 Hi all,

 I have two questions for you!

 *QUESTION 1*

 I'm following the example in [1] (a mix between "jdbc transactional"
 and "jdbc bulk operations") and I've enabled write behind, however after
 the first 10k-20k insertions the performance drops *dramatically*.

 Based on prints I've added to the CacheStore, I've noticed what Ignite
 is doing is this:

 - writeAll called with 512 elements (Ignites buffers elements, that's
 good)
 - openConnection with autocommit=true is called each time inside
 writeAll (since session is not stored in atomic mode)
 - writeAll is called with 512 elements a few dozen times, each time it
 opens a new JDBC connection as mentioned above
 - ...
 - writeAll called with ONE element (for some reason Ignite stops
 buffering elements)
 - writeAll is called with ONE element from here on, each time it opens
 a new JDBC connection as mentioned above
 - ...

 Things to note:

 - All config values are the defaults ones except for write through and
 write behind which are both enabled.
 - I'm running this as a server node (only one node on the cluster, the
 application itself).
 - I see the problem even with a big heap (ie, Ignite is not nearly out
 of memory).
 - I'm using PostgreSQL for this test (it's fine ingesting around 40k
 rows per second on this computer, so that shouldn't be a problem)

 What is causing Ignite to stop buffering elements after calling
 writeAll() a few dozen times?

 *QUESTION 2*

 I've read on the docs that using ATOMIC mode (default mode) is better
 for performance, but I'm not getting why. If I'm not wrong using
 TRANSACTIONAL mode would cause the CacheStore to reuse connections (not
 call openConnection(autocommit=true) on each writeAll()).

 Shouldn't it be better to use transactional mode?

 Regards,
 Matt

 [1] https://apacheignite.readme.io/docs/persistent-store#sec
 tion-cachestore-example

>>>
>>>
>>
>

Re: Failed to send datagram message to remote node

2017-05-02 Thread Nikolai Tikhonov

Hi,

Seems that you did correct rules. Did you try disable firewall, is it
works? Can you check the ports by iperf?

On Mon, May 1, 2017 at 1:48 PM, Nikolai Tikhonov 
wrote:

> Hi,
>
> Are you sure that you allowed to send UDP message through this port?
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Failed-to-send-datagram-message-to-
> remote-node-tp12316p12320.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: Combined off heap size?

2017-05-02 Thread Swetad90

Hi,

I have a physical 8x32 server and I am using 4 data nodes in one cluster
group(G1)

I have the below config:
 






 





So basically I am assigning 40GB of off-heap memory. I know that this is
just assigned, nodes will use that memory as and when data comes in. Based
on this scenario -

1. What will happen once I have exhausted 32 GB of memory. I don't have SWAP
memory configured. How will Ignite behave?

2. If I have a separate cluster group of another 3 nodes(G2) on the same
server being used by another application. They will also be affected as the
current 4 nodes(in G1) will utilize all the memory of the server. Is there
any other workaround/ best practices to handle such multi tenancy in ignite?

3. When it comes to this memory allocation, has OS anything to with it or
everything is taken care by the JVM/ignite instance only.

Thanks.



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Combined-off-heap-size-tp7137p12353.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Ignite .NET vs Java

2017-05-02 Thread Humphrey

I'm trying to do the following in .NET with C# using lambda expression and I
can't figure out how to do the same thing I can do with Java.

In Java I can do the following:

List listOfWords = Arrays.asList("How many characters are
there?".split(" "));
Collection res = ignite.compute().apply((String word) ->
word.length(), listOfWords);

Now I'm trying to do the same in .NET with C#:

ICollection words = "Count characters using
closure".Split().ToList();
var res = ignite.GetCompute().Apply((string x) => x.Length,
words);

It looks like it is trying to invoke the following method:
TRes Apply(IComputeFunc clo, TArg arg);

Instead I want it to invoke the following method:
ICollection Apply(IComputeFunc clo,
IEnumerable args);

Both apply overloaded method have the same amount of paramters, so how do I
specify it to use the correct apply method? I don't want to create an
implementation of the IComputeFunction but want to use lambda like I can do
in Java.

I have tried different combination of the <> after Apply, for example
Apply or without the <>.
The complete code (using implementation of the IComputeFunction) is in the
.NET examples of ignite. I'm trying to find out the equivalent lambda way in
C#.

Humphrey



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

Re: HDP, Hive + Ignite

2017-05-02 Thread Ivan Veselovsky

1. Please make sure IGFS is really used: e.g. you may explicitly locate some
table data on IGFS, and run the queries upon. IGFS statistics can partially
be observed through Visor. 
Also please note, that upon node(s) start IGFS is empty. In case of dual
modes it caches the data upon file reading. In case of primary mode you need
to put some data onto the file system before you can use it. So, data read
performance boost can be seen only when some data are already cached in
IGFS, and read from there rather than from disk. 

2. Can you specify data and the query , so that we could reproduce the
issue? (E.g. you can use some publicly available sample data from Hive
examples.)

3. No. The nodes should connect without additional effort. Can you please
attach full logs of all nodes where this situation happens?



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

Re: Ignite .NET vs Java

2017-05-02 Thread Pavel Tupitsyn

You have to implement IComputeFunc.
Ignite.NET does not have overloads for anonymous functions & lambdas.
We have plans to add them in future versions.

On Tue, May 2, 2017 at 9:46 PM, Humphrey  wrote:

> I'm trying to do the following in .NET with C# using lambda expression and
> I
> can't figure out how to do the same thing I can do with Java.
> 
> In Java I can do the following:
>
> List listOfWords = Arrays.asList("How many characters are
> there?".split(" "));
> Collection res = ignite.compute().apply((String word) ->
> word.length(), listOfWords);
> 
> Now I'm trying to do the same in .NET with C#:
>
> ICollection words = "Count characters using
> closure".Split().ToList();
> var res = ignite.GetCompute().Apply((string x) => x.Length,
> words);
> 
> It looks like it is trying to invoke the following method:
> TRes Apply(IComputeFunc clo, TArg arg);
>
> Instead I want it to invoke the following method:
> ICollection Apply(IComputeFunc clo,
> IEnumerable args);
>
> Both apply overloaded method have the same amount of paramters, so how do I
> specify it to use the correct apply method? I don't want to create an
> implementation of the IComputeFunction but want to use lambda like I can do
> in Java.
>
> I have tried different combination of the <> after Apply, for example
> Apply or without the <>.
> The complete code (using implementation of the IComputeFunction) is in the
> .NET examples of ignite. I'm trying to find out the equivalent lambda way
> in
> C#.
>
> Humphrey
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Ignite-NET-vs-Java-tp12354.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Volatile Kubernetes Node Discovery

2017-05-02 Thread keinproblem

Dear Apache Ignite Users Community,

This may be a well-known problem, although the currently available
information does not provide enough help for solving this issue.

Inside my service I'm using a IgniteCache in /Replicated/ mode from Ignite
1.9.
Some replicas of this service run inside Kubernetes in form of Pods (1
Container/Pod).
I'm using the 
/org.apache.ignite.spi.discovery.tcp.ipfinder.kubernetes.TcpDiscoveryKubernetesIpFinder/
for the Node Discovery.
As I understood: each Pod is able to make an API Call to the Kubernetes API
and retrieve the list of currently available nodes. This works properly.
Even though the Pod's own IP will also be retrieved, which produces a
somehow harmless 

Here is how I get my /IgniteCache/ the used /IgniteConfiguration/
information:

public IgniteCache getCacheInstance(){
final CacheConfiguration cacheConfiguration = new
CacheConfiguration<>();
cacheConfiguration.setName("MyObjectCache");
return ignite.getOrCreateCache(cacheConfiguration);
}

public static IgniteConfiguration getDefaultIgniteConfiguration(){
final IgniteConfiguration cfg = new IgniteConfiguration();
cfg.setGridLogger(new Slf4jLogger(log));
cfg.setClientMode(false);

final TcpDiscoveryKubernetesIpFinder kubernetesPodIpFinder = new
TcpDiscoveryKubernetesIpFinder();
   
kubernetesPodIpFinder.setServiceName(SystemDataProvider.getServiceNameEnv);
final TcpDiscoverySpi tcpDiscoverySpi = new TcpDiscoverySpi();


tcpDiscoverySpi.setIpFinder(kubernetesPodIpFinder);
tcpDiscoverySpi.setLocalPort(47500);//using a static port,
to decrease potential failure causes
cfg.setFailureDetectionTimeout(9);
cfg.setDiscoverySpi(tcpDiscoverySpi);
return cfg;
}



The initial node will start up properly every time.

In most cases, the ~ 3rd node trying to connect will fail and gets restarted
by Kubernetes after some time. Sometimes this node will succeed in
connecting to the cluster after a few restarts, but the common case is that
the nodes will keep restarting forever.

But the major issue is that when a new node fails to connect to the cluster,
the cluster seems to become unstable: the number of nodes increases for a
very short time, then drops to the previous count or even lower.
I am not sure if those are the new connecting nodes loosing the connection
immediately again, or if the previous successfully connected nodes loose
connection.


I also deployed the bare Ignite Docker Image including a configuration for
the 
 /TcpDiscoveryKubernetesIpFinder/ as described here 
https://apacheignite.readme.io/docs/kubernetes-deployment
  . 
Even with this minimal setup, I've experienced the same behavior.

There is no load on the Ignite Nodes and the network usage is very low.

Using another Kubernetes instance on another infrastructure showed the same
results, hence I assume this to be an Ignite related issue.

What I also tried is, increasing the specific time-outs like /ackTimeout/,
/sockTimeout/ etc.

Also using the /TcpDiscoveryVmIpFinder/ did not help. Where I got all the
endpoints via DNS.
Same behavior as described inb4.

Please find attached a log file providing information on WARN level. Please
let me know if DEBUG level is desired.



Kind regards and thanks in advance,
keinproblem



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Volatile-Kubernetes-Node-Discovery-tp12357.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Volatile Kubernetes Node Discovery

2017-05-02 Thread keinproblem

Providing the previously promised log-file. ignite_dmp.txt
  
- Please excuse the DP



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Volatile-Kubernetes-Node-Discovery-tp12357p12358.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Serializer

2017-05-02 Thread javastuff....@gmail.com

Hi

We have multiple off-heap caches defined.  We have implemented Binarylizable
for each cache object. So far so good.

We have a requirement we have to store List or Map of Binarylizable objects
in a cache. How do I attempt to write serializer for List and Map? 

These List and Map are extended object with some extra logic on top of basic
ArrayList or LinkedHashMap. 

Thanks,
-Sam






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

Grid is in invalid state to perform this operation

2017-05-02 Thread javastuff....@gmail.com

Hi,

My application was working and later laptop went into sleep/standBy mode.
After awake got below exception. Looks like grid is stopped. Is there a way
to handle this?

/java.lang.IllegalStateException: Grid is in invalid state to perform this
operation. It either not started yet or has already being or have stopped
[gridName=grid.cfg, state=STOPPED]
org.apache.ignite.internal.GridKernalGatewayImpl.illegalState(GridKernalGatewayImpl.java:190)
org.apache.ignite.internal.GridKernalGatewayImpl.readLock(GridKernalGatewayImpl.java:90)
org.apache.ignite.internal.IgniteKernal.guard(IgniteKernal.java:3300)
org.apache.ignite.internal.IgniteKernal.cache(IgniteKernal.java:2548)
/

Thanks,
-Sam



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Grid-is-in-invalid-state-to-perform-this-operation-tp12360.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

IGFS - Python and R clients

2017-05-02 Thread Sergey Semichev

My application needs to read / write data to a distributed memory FS.
The application is not Map/Reduce or Spark job. 
Let's say I need to run a docker orchestration pipeline, where each step is
a docker container, and I want to save the intermediate results of each step
and pass it to the next step. A docker container may use Java, Python, R or
C++ code to execute the logic. 

Is it possible to use Python and R to r /w directly to IGFS in primary mode
or in dual_sync mode?
Technically I can use for example ZeroMQ to implement IPC communication
between Java and Python and use IGFS Native API, but it will introduce
additional latency.

If I run IGFS as Hadoop accelerator on top of HDFS, can I use python HDFS
interfaces?
http://wesmckinney.com/blog/python-hdfs-interfaces/

Thanks



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/IGFS-Python-and-R-clients-tp12361.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Ignite TLS with TrustStore

2017-05-02 Thread Swetad90

Hi,
I referred to the Ignite docs on TLS:
https://apacheignite.readme.io/docs/ssltls.

I have the below set in my config XML file for TLS:
 

 
 
 
  
 
  

 

and the below for Discovery:









10.17.XX.XXX:49500..49520
10.17.XX.XXX:49500..49520






 





However when I start my nodes, they don't discover one another.
Node1-
[16:18:24] Topology snapshot [ver=1, servers=1, clients=0, CPUs=8,
heap=1.0GB]
[16:18:29] Failed to initialize connection (missing SSL configuration on
remote node?) [rmtAddr=/10.17.XX.XXX]

Node2-
[16:18:30] Topology snapshot [ver=1, servers=1, clients=0, CPUs=8,
heap=1.0GB]


I have checked both my keystore and truststore and they are fine.Also, they
are not self-signed certificates.
But it works with disabled trust managers.

Is there anything I am missing in setting up TLS communication here?





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

NoSuchMethodError: org.apache.curator.framework.api.CreateBuilder.creatingParentContainersIfNeeded()

2017-05-02 Thread baozipu

Hello, I got this error but I couldn't solve it.

===
java.lang.NoSuchMethodError:
org.apache.curator.framework.api.CreateBuilder.creatingParentContainersIfNeeded()Lorg/apache/curator/framework/api/ProtectACLCreateModePathAndBytesable;
at
org.apache.curator.x.discovery.details.ServiceDiscoveryImpl.internalRegisterService(ServiceDiscoveryImpl.java:222)
at
org.apache.curator.x.discovery.details.ServiceDiscoveryImpl.registerService(ServiceDiscoveryImpl.java:188)
at
org.apache.ignite.spi.discovery.tcp.ipfinder.zk.TcpDiscoveryZookeeperIpFinder.registerAddresses(TcpDiscoveryZookeeperIpFinder.java:237)
at
org.apache.ignite.spi.discovery.tcp.ipfinder.TcpDiscoveryIpFinderAdapter.initializeLocalAddresses(TcpDiscoveryIpFinderAdapter.java:61)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoveryImpl.registerLocalNodeAddress(TcpDiscoveryImpl.java:294)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:334)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1850)
at
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:268)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:685)
at
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1626)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:924)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1799)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1602)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:569)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:530)
at org.apache.ignite.Ignition.getOrStart(Ignition.java:414)
at org.apache.ignite.spark.IgniteContext.ignite(IgniteContext.scala:143)
at
org.apache.ignite.spark.IgniteContext$$anonfun$1.apply(IgniteContext.scala:54)
at
org.apache.ignite.spark.IgniteContext$$anonfun$1.apply(IgniteContext.scala:54)
at
org.apache.spark.rdd.RDD$$anonfun$foreachPartition$1$$anonfun$apply$29.apply(RDD.scala:925)
at
org.apache.spark.rdd.RDD$$anonfun$foreachPartition$1$$anonfun$apply$29.apply(RDD.scala:925)
at
org.apache.spark.SparkContext$$anonfun$runJob$5.apply(SparkContext.scala:1944)
at
org.apache.spark.SparkContext$$anonfun$runJob$5.apply(SparkContext.scala:1944)
at org.apache.spark.scheduler.ResultTask.runTask(ResultTask.scala:87)
at org.apache.spark.scheduler.Task.run(Task.scala:99)
at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:282)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)

===

My SBT file only includes Ignite related

== SBT   
libraryDependencies += ("org.apache.ignite" % "ignite-spark" % "1.9.0")
  .exclude("org.scalatest", "scalatest_2.10")
  .exclude("com.twitter", "chill_2.10")
  .exclude("org.apache.spark", "spark-unsafe_2.10")
  .exclude("org.apache.spark", "spark-tags_2.10")

libraryDependencies += "org.apache.ignite" % "ignite-zookeeper" % "1.9.0"
===


I have no problem on launching it on my local through IDEA. However, when I
submit the jar file on my server cluster, it reports such error.

= submit command =

spark-submit --packages
org.apache.ignite:ignite-spark:1.9.0,org.apache.ignite:ignite-zookeeper:1.9.0 
--conf 'spark.mesos.coarse=true' ignitemaster_2.11-1.0.jar

==

I think this command has included everything, but I don't know where is the
conflict.

Could you please provide steps that I should check one by one? Thanks,











--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/NoSuchMethodError-org-apache-curator-framework-api-CreateBuilder-creatingParentContainersIfNeeded-tp12363.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Concurrent job execution and FifoQueueCollisionSpi.parallelJobsNumber=1

2017-05-02 Thread Ryan Ripken


Please let me know if I can help in any way.

On 4/13/2017 2:18 AM, vkulichenko wrote:

Hi Ryan,

I will take a look at your sample in the next few days.

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Concurrent-job-execution-and-FifoQueueCollisionSpi-parallelJobsNumber-1-tp8697p11935.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: CacheStore's Performance Drops Dramatically - Why?

2017-05-02 Thread Denis Magda

Matt,

Cross-posting to the dev list.

Yes, Ignite switches to the synchronous mode once the buffer is exhausted. 
However, I do agree that it would be a right solution to flush multiple entries 
rather than one in the synchronous mode. *Igniters*, I was sure we had a ticket 
for that optimization but unable to find it.  Does anybody know the ticket 
name/number?

To omit the performance degradation you have to tweak the following parameters 
so that the write-behind store can keep up with you updates:
- setWriteBehindFlushThreadCount
- setWriteBehindFlushFrequency
- setWriteBehindBatchSize
- setWriteBehindFlushSize

Usually it helped all the times to Apache Ignite users.

> QUESTION 2
> 
> I've read on the docs that using ATOMIC mode (default mode) is better for 
> performance, but I'm not getting why. If I'm not wrong using TRANSACTIONAL 
> mode would cause the CacheStore to reuse connections (not call 
> openConnection(autocommit=true) on each writeAll()).
> 
> Shouldn't it be better to use transactional mode?

Transactional mode enables 2 phase commit protocol: 
https://apacheignite.readme.io/docs/transactions#two-phase-commit-2pc

This is why atomic operations are swifter in general.

—
Denis

> On May 2, 2017, at 10:40 AM, Matt  wrote:
> 
> No, only with inserts, I haven't tried removing at this rate yet but it may 
> have the same problem.
> 
> I'm debugging Ignite internal code and I may be onto something. The thing is 
> Ignite has a cacheMaxSize (aka, WriteBehindFlushSize) and cacheCriticalSize 
> (which by default is cacheMaxSize*1.5). When the cache reaches that size 
> Ignite starts writing elements SYNCHRONOUSLY, as you can see in [1].
> 
> I think this makes things worse since only one single value is flushed at a 
> time, it becomes much slower forcing Ignite to do more synchronous writes.
> 
> Anyway, I'm still not sure why the cache reaches that level when the database 
> is clearly able to keep up with the insertions. I'll check if it has to do 
> with the number of open connections or what.
> 
> Any insight on this is very welcome!
> 
> [1] 
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/store/GridCacheWriteBehindStore.java#L620
> 
> On Tue, May 2, 2017 at 2:17 PM, Jessie Lin  
> wrote:
> I noticed that behavior when any cache.remove operation is involved. I keep 
> putting stuff in cache seems to be working properly.
> 
> Do you use remove operation?
> 
> On Tue, May 2, 2017 at 9:57 AM, Matt  wrote:
> I'm stuck with that. No matter what config I use (flush size, write threads, 
> etc) this is the behavior I always get. It's as if Ignite internal buffer is 
> full and it's trying to write and get rid of the oldest (one) element only.
> 
> Any idea people? What is your CacheStore configuration to avoid this?
> 
> On Tue, May 2, 2017 at 11:50 AM, Jessie Lin  
> wrote:
> Hello Matt, thank you for posting. I've noticed similar behavior. 
> 
> Would be curious to see the response from the engineering team.
> 
> Best,
> Jessie
> 
> On Tue, May 2, 2017 at 1:03 AM, Matt  wrote:
> Hi all,
> 
> I have two questions for you!
> 
> QUESTION 1
> 
> I'm following the example in [1] (a mix between "jdbc transactional" and 
> "jdbc bulk operations") and I've enabled write behind, however after the 
> first 10k-20k insertions the performance drops *dramatically*.
> 
> Based on prints I've added to the CacheStore, I've noticed what Ignite is 
> doing is this:
> 
> - writeAll called with 512 elements (Ignites buffers elements, that's good)
> - openConnection with autocommit=true is called each time inside writeAll 
> (since session is not stored in atomic mode)
> - writeAll is called with 512 elements a few dozen times, each time it opens 
> a new JDBC connection as mentioned above
> - ...
> - writeAll called with ONE element (for some reason Ignite stops buffering 
> elements)
> - writeAll is called with ONE element from here on, each time it opens a new 
> JDBC connection as mentioned above
> - ...
> 
> Things to note:
> 
> - All config values are the defaults ones except for write through and write 
> behind which are both enabled.
> - I'm running this as a server node (only one node on the cluster, the 
> application itself).
> - I see the problem even with a big heap (ie, Ignite is not nearly out of 
> memory).
> - I'm using PostgreSQL for this test (it's fine ingesting around 40k rows per 
> second on this computer, so that shouldn't be a problem)
> 
> What is causing Ignite to stop buffering elements after calling writeAll() a 
> few dozen times?
> 
> QUESTION 2
> 
> I've read on the docs that using ATOMIC mode (default mode) is better for 
> performance, but I'm not getting why. If I'm not wrong using TRANSACTIONAL 
> mode would cause the CacheStore to reuse connections (not call 
> openConnection(autocommit=true) on each writeAll()).
> 
> Shouldn't it be better to use transactional mode?
> 
> Regards,
> Matt
> 
> [1] 
> https:/

Re: Volatile Kubernetes Node Discovery

2017-05-02 Thread Denis Magda

> Inside my service I'm using a IgniteCache in /Replicated/ mode from Ignite
> 1.9.
> Some replicas of this service run inside Kubernetes in form of Pods (1
> Container/Pod).
> I'm using the 
> /org.apache.ignite.spi.discovery.tcp.ipfinder.kubernetes.TcpDiscoveryKubernetesIpFinder/
> for the Node Discovery.

Do you mean that a part of the cluster is running outside of Kubernetes? If 
it’s so this might be an issue because containerized Ignite nodes can’t get 
trough the network and reach out your nodes that are outside.

—
Denis

> On May 2, 2017, at 12:20 PM, keinproblem  wrote:
> 
> Dear Apache Ignite Users Community,
> 
> This may be a well-known problem, although the currently available
> information does not provide enough help for solving this issue.
> 
> Inside my service I'm using a IgniteCache in /Replicated/ mode from Ignite
> 1.9.
> Some replicas of this service run inside Kubernetes in form of Pods (1
> Container/Pod).
> I'm using the 
> /org.apache.ignite.spi.discovery.tcp.ipfinder.kubernetes.TcpDiscoveryKubernetesIpFinder/
> for the Node Discovery.
> As I understood: each Pod is able to make an API Call to the Kubernetes API
> and retrieve the list of currently available nodes. This works properly.
> Even though the Pod's own IP will also be retrieved, which produces a
> somehow harmless 
> 
> Here is how I get my /IgniteCache/ the used /IgniteConfiguration/
> information:
> 
>public IgniteCache getCacheInstance(){
>final CacheConfiguration cacheConfiguration = new
> CacheConfiguration<>();
>cacheConfiguration.setName("MyObjectCache");
>return ignite.getOrCreateCache(cacheConfiguration);
>}
> 
>public static IgniteConfiguration getDefaultIgniteConfiguration(){
>final IgniteConfiguration cfg = new IgniteConfiguration();
>cfg.setGridLogger(new Slf4jLogger(log));
>cfg.setClientMode(false);
> 
>final TcpDiscoveryKubernetesIpFinder kubernetesPodIpFinder = new
> TcpDiscoveryKubernetesIpFinder();
> 
> kubernetesPodIpFinder.setServiceName(SystemDataProvider.getServiceNameEnv);
>final TcpDiscoverySpi tcpDiscoverySpi = new TcpDiscoverySpi();
> 
> 
>tcpDiscoverySpi.setIpFinder(kubernetesPodIpFinder);
>tcpDiscoverySpi.setLocalPort(47500);//using a static port,
> to decrease potential failure causes
>cfg.setFailureDetectionTimeout(9);
>cfg.setDiscoverySpi(tcpDiscoverySpi);
>return cfg;
>}
> 
> 
> 
> The initial node will start up properly every time.
> 
> In most cases, the ~ 3rd node trying to connect will fail and gets restarted
> by Kubernetes after some time. Sometimes this node will succeed in
> connecting to the cluster after a few restarts, but the common case is that
> the nodes will keep restarting forever.
> 
> But the major issue is that when a new node fails to connect to the cluster,
> the cluster seems to become unstable: the number of nodes increases for a
> very short time, then drops to the previous count or even lower.
> I am not sure if those are the new connecting nodes loosing the connection
> immediately again, or if the previous successfully connected nodes loose
> connection.
> 
> 
> I also deployed the bare Ignite Docker Image including a configuration for
> the 
> /TcpDiscoveryKubernetesIpFinder/ as described here 
> https://apacheignite.readme.io/docs/kubernetes-deployment
>   . 
> Even with this minimal setup, I've experienced the same behavior.
> 
> There is no load on the Ignite Nodes and the network usage is very low.
> 
> Using another Kubernetes instance on another infrastructure showed the same
> results, hence I assume this to be an Ignite related issue.
> 
> What I also tried is, increasing the specific time-outs like /ackTimeout/,
> /sockTimeout/ etc.
> 
> Also using the /TcpDiscoveryVmIpFinder/ did not help. Where I got all the
> endpoints via DNS.
> Same behavior as described inb4.
> 
> Please find attached a log file providing information on WARN level. Please
> let me know if DEBUG level is desired.
> 
> 
> 
> Kind regards and thanks in advance,
> keinproblem
> 
> 
> 
> --
> View this message in context: 
> http://apache-ignite-users.70518.x6.nabble.com/Volatile-Kubernetes-Node-Discovery-tp12357.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Write-behind Flush Size

2017-05-02 Thread rickynauvaldy

It turns out that the flush process is executed when there are "n+1" rows
that change. If I set writeBehindFlushSize = 2, then the writing process
will be executed on the third change in the table because "with the
write-behind approach, only the last update to an entry will be written to
the underlying storage" [1].

I hope that I get it right.
Thanks.

[1]
https://apacheignite.readme.io/docs/persistent-store#section-write-behind-caching



-
-- Ricky
--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Write-behind-Flush-Size-tp12336p12367.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: NoSuchMethodError: org.apache.curator.framework.api.CreateBuilder.creatingParentContainersIfNeeded()

2017-05-02 Thread Evgenii Zhuravlev

Hi,

First of all, I would highly recommend to use spark that built with scala
2.11 instead of 2.10, because you use ignite that built with scala 2.11.

Please double check that you moved all ZooKeeper module related libs from
“{apache_build}/libs/optional/ignite-zookeper” into “{apache_build}/libs/“
and start the nodes using ignite.sh using your configuration.

If you start the nodes from IDEA please make sure that there are no any
curator libs that are imported by your idea.

2017-05-03 2:53 GMT+03:00 baozipu :

> Hello, I got this error but I couldn't solve it.
>
> ===
> java.lang.NoSuchMethodError:
> org.apache.curator.framework.api.CreateBuilder.creatingParen
> tContainersIfNeeded()Lorg/apache/curator/framework/api/P
> rotectACLCreateModePathAndBytesable;
> at
> org.apache.curator.x.discovery.details.ServiceDiscoveryImpl.
> internalRegisterService(ServiceDiscoveryImpl.java:222)
> at
> org.apache.curator.x.discovery.details.ServiceDiscoveryImpl.
> registerService(ServiceDiscoveryImpl.java:188)
> at
> org.apache.ignite.spi.discovery.tcp.ipfinder.zk.TcpDiscovery
> ZookeeperIpFinder.registerAddresses(TcpDiscoveryZookeeperIpF
> inder.java:237)
> at
> org.apache.ignite.spi.discovery.tcp.ipfinder.TcpDiscoveryIpF
> inderAdapter.initializeLocalAddresses(TcpDiscoveryIpFinderAdapter.java:61)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoveryImpl.registe
> rLocalNodeAddress(TcpDiscoveryImpl.java:294)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(
> ServerImpl.java:334)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart
> (TcpDiscoverySpi.java:1850)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.start
> Spi(GridManagerAdapter.java:268)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryM
> anager.start(GridDiscoveryManager.java:685)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteK
> ernal.java:1626)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.
> java:924)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.
> start0(IgnitionEx.java:1799)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.
> start(IgnitionEx.java:1602)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java
> :1042)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:
> 569)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:
> 530)
> at org.apache.ignite.Ignition.getOrStart(Ignition.java:414)
> at org.apache.ignite.spark.IgniteContext.ignite(IgniteContext.
> scala:143)
> at
> org.apache.ignite.spark.IgniteContext$$anonfun$1.apply(
> IgniteContext.scala:54)
> at
> org.apache.ignite.spark.IgniteContext$$anonfun$1.apply(
> IgniteContext.scala:54)
> at
> org.apache.spark.rdd.RDD$$anonfun$foreachPartition$1$$anonfu
> n$apply$29.apply(RDD.scala:925)
> at
> org.apache.spark.rdd.RDD$$anonfun$foreachPartition$1$$anonfu
> n$apply$29.apply(RDD.scala:925)
> at
> org.apache.spark.SparkContext$$anonfun$runJob$5.apply(SparkC
> ontext.scala:1944)
> at
> org.apache.spark.SparkContext$$anonfun$runJob$5.apply(SparkC
> ontext.scala:1944)
> at org.apache.spark.scheduler.ResultTask.runTask(ResultTask.sca
> la:87)
> at org.apache.spark.scheduler.Task.run(Task.scala:99)
> at org.apache.spark.executor.Executor$TaskRunner.run(Executor.
> scala:282)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
> Executor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
> lExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
>
> ===
>
> My SBT file only includes Ignite related
>
> == SBT   
> libraryDependencies += ("org.apache.ignite" % "ignite-spark" % "1.9.0")
>   .exclude("org.scalatest", "scalatest_2.10")
>   .exclude("com.twitter", "chill_2.10")
>   .exclude("org.apache.spark", "spark-unsafe_2.10")
>   .exclude("org.apache.spark", "spark-tags_2.10")
>
> libraryDependencies += "org.apache.ignite" % "ignite-zookeeper" % "1.9.0"
> ===
>
>
> I have no problem on launching it on my local through IDEA. However, when I
> submit the jar file on my server cluster, it reports such error.
>
> = submit command =
>
> spark-submit --packages
> org.apache.ignite:ignite-spark:1.9.0,org.apache.ignite:ignit
> e-zookeeper:1.9.0
> --conf 'spark.mesos.coarse=true' ignitemaster_2.11-1.0.jar
>
> ==
>
> I think this command has included everything, but I don't know where is the
> conflict.
>
> Could you please provide steps that I should check one by one? Thanks,
>
>
>
>
>
>
>
>
>
>
>
> --
> View this message in context: http://apache-ignite-users.705
> 18.x6.nabble.com/NoSuchMethodError-org-apache-curator-
> framework-api-CreateB

Where can I find example-ignite.xml for ignite sink connector?

2017-05-02 Thread blasteralfred

Hi,

I am trying to fetch data from my Kafka topic, and insert it to Ignite
cache. I followed tutorial here
https://github.com/apache/ignite/tree/master/modules/kafka . At the end of
instructions, for ignite xml reference, it is written that "For a simple
cache configuration file example, see example-ignite.xml in tests." , but I
haven't found folder named "tests". Somebody kindly help me to figure out
this and get the xml file.

Thank you.





--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Where-can-I-find-example-ignite-xml-for-ignite-sink-connector-tp12370.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Where can I find example-ignite.xml for ignite sink connector?

2017-05-02 Thread blasteralfred

seen it here also https://apacheignite-mix.readme.io/v1.9/docs/kafka-streamer



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Where-can-I-find-example-ignite-xml-for-ignite-sink-connector-tp12370p12371.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: CacheStore's Performance Drops Dramatically - Why?

2017-05-02 Thread Matt

I'm writing to confirm I managed to fix my problem by fine tuning the
config params for the write behind cache until the performance was fine. I
still see single element inserts from time to time, but just a few of them
every now and then not like before. You should definitely avoid synchronous
single elements insertions, I hope that changes in future versions.

Regarding writeBehindBatchSize and writeBehindFlushSize, I don't see the
point of setting both values when batchSize < flushSize (default values are
512 and 10240 respectively). If I'm not wrong, the cache is flushed
whenever the its size is equal to min(batchSize, flushSize). Since
batchSize is less than flushSize, flushSize is never really used and the
size of the flush is controlled by the size of the cache itself only.

That is how it works by default, on the other hand if we swap their values
(ie, batchSize=10240 and flushSize=512) the behavior would be the same
(Ignite would call writeAll() with 512 elements each time), but the number
of elements flushed would be controlled by the correct variable (ie,
flushSize).

Were the default values supposed to be the other way around or am I missing
something?

On Tue, May 2, 2017 at 9:13 PM, Denis Magda  wrote:

> Matt,
>
> Cross-posting to the dev list.
>
> Yes, Ignite switches to the synchronous mode once the buffer is exhausted.
> However, I do agree that it would be a right solution to flush multiple
> entries rather than one in the synchronous mode. *Igniters*, I was sure we
> had a ticket for that optimization but unable to find it.  Does anybody
> know the ticket name/number?
>
> To omit the performance degradation you have to tweak the following
> parameters so that the write-behind store can keep up with you updates:
> - setWriteBehindFlushThreadCount
> - setWriteBehindFlushFrequency
> - setWriteBehindBatchSize
> - setWriteBehindFlushSize
>
> Usually it helped all the times to Apache Ignite users.
>
> > QUESTION 2
> >
> > I've read on the docs that using ATOMIC mode (default mode) is better
> for performance, but I'm not getting why. If I'm not wrong using
> TRANSACTIONAL mode would cause the CacheStore to reuse connections (not
> call openConnection(autocommit=true) on each writeAll()).
> >
> > Shouldn't it be better to use transactional mode?
>
> Transactional mode enables 2 phase commit protocol:
> https://apacheignite.readme.io/docs/transactions#two-phase-commit-2pc
>
> This is why atomic operations are swifter in general.
>
> —
> Denis
>
> > On May 2, 2017, at 10:40 AM, Matt  wrote:
> >
> > No, only with inserts, I haven't tried removing at this rate yet but it
> may have the same problem.
> >
> > I'm debugging Ignite internal code and I may be onto something. The
> thing is Ignite has a cacheMaxSize (aka, WriteBehindFlushSize) and
> cacheCriticalSize (which by default is cacheMaxSize*1.5). When the cache
> reaches that size Ignite starts writing elements SYNCHRONOUSLY, as you can
> see in [1].
> >
> > I think this makes things worse since only one single value is flushed
> at a time, it becomes much slower forcing Ignite to do more synchronous
> writes.
> >
> > Anyway, I'm still not sure why the cache reaches that level when the
> database is clearly able to keep up with the insertions. I'll check if it
> has to do with the number of open connections or what.
> >
> > Any insight on this is very welcome!
> >
> > [1] https://github.com/apache/ignite/blob/master/modules/
> core/src/main/java/org/apache/ignite/internal/processors/cache/store/
> GridCacheWriteBehindStore.java#L620
> >
> > On Tue, May 2, 2017 at 2:17 PM, Jessie Lin 
> wrote:
> > I noticed that behavior when any cache.remove operation is involved. I
> keep putting stuff in cache seems to be working properly.
> >
> > Do you use remove operation?
> >
> > On Tue, May 2, 2017 at 9:57 AM, Matt  wrote:
> > I'm stuck with that. No matter what config I use (flush size, write
> threads, etc) this is the behavior I always get. It's as if Ignite internal
> buffer is full and it's trying to write and get rid of the oldest (one)
> element only.
> >
> > Any idea people? What is your CacheStore configuration to avoid this?
> >
> > On Tue, May 2, 2017 at 11:50 AM, Jessie Lin <
> jessie.jianwei@gmail.com> wrote:
> > Hello Matt, thank you for posting. I've noticed similar behavior.
> >
> > Would be curious to see the response from the engineering team.
> >
> > Best,
> > Jessie
> >
> > On Tue, May 2, 2017 at 1:03 AM, Matt  wrote:
> > Hi all,
> >
> > I have two questions for you!
> >
> > QUESTION 1
> >
> > I'm following the example in [1] (a mix between "jdbc transactional" and
> "jdbc bulk operations") and I've enabled write behind, however after the
> first 10k-20k insertions the performance drops *dramatically*.
> >
> > Based on prints I've added to the CacheStore, I've noticed what Ignite
> is doing is this:
> >
> > - writeAll called with 512 elements (Ignites buffers elements, that's
> good)
> > - openConnection with autocommit=true is c

Re: Distributed Closures VS Executor Service

Re: Distributed Closures VS Executor Service

Write-behind Flush Size

CacheStore's Performance Drops Dramatically - Why?

Continuous Query remote listener misses some events or respond really late

Re: With same load Ignite is not able to respond after enabling SSL

Ignite SQL Indexing Performance problems

Nodes hanging when accessing queue

Re: HDP, Hive + Ignite

Re: tcp-disco-ip-finder-cleaner

Re: CacheStore's Performance Drops Dramatically - Why?

Re: Distributed Closures VS Executor Service

Re: "object not serializable " when initializing igniteContext with Zookeeper Configuration

Re: CacheStore's Performance Drops Dramatically - Why?

Re: CacheStore's Performance Drops Dramatically - Why?

Re: CacheStore's Performance Drops Dramatically - Why?

Re: Failed to send datagram message to remote node

Re: Combined off heap size?

Ignite .NET vs Java

Re: HDP, Hive + Ignite

Re: Ignite .NET vs Java

Volatile Kubernetes Node Discovery

Re: Volatile Kubernetes Node Discovery

Serializer

Grid is in invalid state to perform this operation

IGFS - Python and R clients

Ignite TLS with TrustStore

NoSuchMethodError: org.apache.curator.framework.api.CreateBuilder.creatingParentContainersIfNeeded()

Re: Concurrent job execution and FifoQueueCollisionSpi.parallelJobsNumber=1

Re: CacheStore's Performance Drops Dramatically - Why?

Re: Volatile Kubernetes Node Discovery

Re: Write-behind Flush Size

Re: NoSuchMethodError: org.apache.curator.framework.api.CreateBuilder.creatingParentContainersIfNeeded()

Where can I find example-ignite.xml for ignite sink connector?

Re: Where can I find example-ignite.xml for ignite sink connector?

Re: CacheStore's Performance Drops Dramatically - Why?

36 matches

Site Navigation

Mail list logo

Footer information