Can writeSynchronizationMode be modified online?

2018-01-24 Thread gunman524 
Hi there,

A simple question, can writeSynchronizationMode be modified online?  As my
cache currently in 'full_sync" mode, can it be modified to 'primary_sync'
online?  like by restful or  visor?

BTW, the cache I created by DDL
CREATE TABLE IF NOT EXISTS person ( id int,orgId LONG, name VARCHAR, salary
LONG ,PRIMARY KEY (id) ) WITH "TEMPLATE=PARTITIONED,backups=1,
affinityKey=id, value_type=MyPerson"

why writeSynchronizationMode  be set as full_sync? I think the default value
is "primary_sync". 



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: “Failed to communicate with Ignite cluster" error when using JDBC Thin driver

2017-12-22 Thread gunman524 
We are using mybatis to manage connection, is that matters?

BTW, I check the code in JdbcThinTcpIo method sendRequest 
 
JdbcResponse sendRequest(JdbcRequest req) throws IOException {
int cap = guessCapacity(req);

BinaryWriterExImpl writer = new BinaryWriterExImpl(null, new
BinaryHeapOutputStream(cap), null, null);

req.writeBinary(writer);

send(writer.array());

BinaryReaderExImpl reader = new BinaryReaderExImpl(null, new
BinaryHeapInputStream(read()), null, null, false);

JdbcResponse res = new JdbcResponse();

res.readBinary(reader);

return res;
}

After send() execute,  run read() immediately. Is that might introduce
synchronized issue?  The msg not come back from server when read it from
client out? As in our test env, the insert action has big chance to success
after several times retry. 



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: “Failed to communicate with Ignite cluster" error when using JDBC Thin driver

2017-12-20 Thread gunman524 
It could not be a version issue, the thin driver and cluster version are
exactly same.

It can happened on any query but can not be reproduce 100%, it only happened
"some times".

In Log, I found  "Caused by: java.io.IOException: Failed to read incoming
message (not enough 
data). "
  
Firstly I guess the passing parms does not match with what defined in SQL,
but it not the case after double check.

So, any idea about it?



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

“Failed to communicate with Ignite cluster" error when using JDBC Thin driver

2017-12-20 Thread gunman524 
Hi guys,

When I use ignite jdbc thin driver connect Ignite cluster, sometimes will
meet the errors below. Do you have any idea what cause this error?  many
thanks!


org.springframework.dao.DataAccessResourceFailureException: 
### Error updating database.  Cause: java.sql.SQLException: Failed to
communicate with Ignite cluster.
### The error may involve defaultParameterMap
### The error occurred while setting parameters
### SQL: MERGE INTO
L_ISUP_APP_DRAFT_RESULT_HISTORY_T(ID,DRAFT_ID,USER_ID,APP_ID,DATA_STRUCTURE,PROJECT_ID,RESULT_ID,RESULT_URL,PROCESS_TYPE,STEP_ID,DRAFT_NAME,STATUS,DELETE_FLAG,CREATE_TIME,LAST_UPDATE_TIME,RDC_CODE,APP_DEPLOY_RDC,FROM_RDC,PARAM_STATUS)

VALUES(?,?,?,?,?,?,?,?,  '1',?,?,   
?,   ?, ?,?,?,?,?,?);
### Cause: java.sql.SQLException: Failed to communicate with Ignite cluster.
; SQL []; Failed to communicate with Ignite cluster.; nested exception is
java.sql.SQLException: Failed to communicate with Ignite cluster.
at
org.springframework.jdbc.support.SQLStateSQLExceptionTranslator.doTranslate(SQLStateSQLExceptionTranslator.java:105)
at
org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:73)
at
org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:81)
at
org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:81)
at
org.mybatis.spring.MyBatisExceptionTranslator.translateExceptionIfPossible(MyBatisExceptionTranslator.java:75)
at
org.mybatis.spring.SqlSessionTemplate$SqlSessionInterceptor.invoke(SqlSessionTemplate.java:447)
at com.sun.proxy.$Proxy1462.insert(Unknown Source)
at
org.mybatis.spring.SqlSessionTemplate.insert(SqlSessionTemplate.java:279)
at org.apache.ibatis.binding.MapperMethod.execute(MapperMethod.java:56)
at org.apache.ibatis.binding.MapperProxy.invoke(MapperProxy.java:53)
at com.sun.proxy.$Proxy1466.igniteCreateDraftInfo(Unknown Source)
at
com.huawei.isup.service.connect.serviceignite.IgniteAsyncService.igniteCreateDraftInfo(IgniteAsyncService.java:54)
at
com.huawei.isup.service.connect.serviceignite.IgniteAsyncService$$FastClassBySpringCGLIB$$25701ede.invoke()
at 
org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
at
org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:720)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
at
org.springframework.aop.interceptor.AsyncExecutionInterceptor$1.call(AsyncExecutionInterceptor.java:108)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.sql.SQLException: Failed to communicate with Ignite cluster.
at
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:681)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:130)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinPreparedStatement.executeWithArguments(JdbcThinPreparedStatement.java:252)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinPreparedStatement.execute(JdbcThinPreparedStatement.java:240)
at
org.apache.tomcat.dbcp.dbcp2.DelegatingPreparedStatement.execute(DelegatingPreparedStatement.java:197)
at
org.apache.tomcat.dbcp.dbcp2.DelegatingPreparedStatement.execute(DelegatingPreparedStatement.java:197)
at
org.apache.ibatis.executor.statement.PreparedStatementHandler.update(PreparedStatementHandler.java:46)
at
org.apache.ibatis.executor.statement.RoutingStatementHandler.update(RoutingStatementHandler.java:74)
at
org.apache.ibatis.executor.SimpleExecutor.doUpdate(SimpleExecutor.java:50)
at org.apache.ibatis.executor.BaseExecutor.update(BaseExecutor.java:117)
at
org.apache.ibatis.executor.CachingExecutor.update(CachingExecutor.java:76)
at
org.apache.ibatis.session.defaults.DefaultSqlSession.update(DefaultSqlSession.java:198)
at
org.apache.ibatis.session.defaults.DefaultSqlSession.insert(DefaultSqlSession.java:185)
at sun.reflect.GeneratedMethodAccessor1403.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.mybatis.spring.SqlSessionTemplate$SqlSessionInterceptor.invoke(SqlSessionTemplate.java:434)
... 15 more
Caused by:

Re: Register Contentious query quit slow

2017-12-07 Thread gunman524 
Denis,

Thanks for your reply and the code as well 

I'll try what you suggested. Thanks again

BR.
Jin



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Register Contentious query quit slow

2017-12-04 Thread gunman524 
Denis，

I can understand the meta data need to be updated when the CQ has initial
query(IQ) or remote filter(RF). But my understading is only the object
within IQ and RF need to be updated and the stuff in Local listeners does
not.

In my case, the logic in IQ and RF is simple string compare
  e.getValue(). field("FROM_RDC")).equals(localRDC)
and those can be update to cluster if necessary and does make scene.  But
the object in local listener and all object it referenced does not need to
be update to cluster. 

Fact is after I commented out IQ, RF and keep local listeners exists, no
more meta data update happened and the program still work. Seems it proved
my guess.

I didn't go through Ignite code carefully for this part, but it feels like
current logic will check whether IQ or RF is exists. If yes, will update the
meta data of whole CQ instead of just IQ and RF part.

Can we do this enhancement that do not update meta data in Local listener to
cluster?  Or is there has technical issue?

Thanks,

Jin



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: JDBC thin client load balancing and failover support

2017-11-27 Thread gunman524 
That's exactly what I expected  



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Register Contentious query quit slow

2017-11-27 Thread gunman524 
Denis,

For this cross region case, I've some thought to share and please help
verify whether they are  already here.

1. Two DC,   A ---corss region--- B
2. A have several ignite node, A1,A2,A3   and B have several ignite
node, B1,B2,B3 ..., there are in a same cluster
3. In ingite, A1,A2, A3 can belongs to same group, says A' and B1,B2,B3 can
be B'

So, can Ignite do this way
1. For data deployed in A' and B' by REPLICATED mode and within A' using
PARTITION mode
2. The Continuous Query can only register in A'

In this way:
1. As within A', all node in same DC, every action can be performed fast, 
2 .meanwhile, as A' B' have some data, so we should not missing any event
3. As data in A',B' deployed in PARTITION mode, each node do not need to
hold a hug memory.

Thanks,
Jin





--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Register Contentious query quit slow

2017-11-27 Thread gunman524 
Dennis,

Sorry for my misleading.  The slow thing is register CQ but not connect to
cluster (this might take round 1 min). 

Thanks for your remind and after removed intial query, the whole process
become very quick and there is no more "binary metadata update messages".

So if there do have initial query and remotefilter, does it means those meta
data info need exchange among the whole ignite cluster?

I'm sorry for security reason, I cannot upload the full log here but I tried
to show some code structure here

public abstract class AbstractIgniteListeningService
{
public void registerCache() throws IgniteException
{
try
{

final IgniteCache cache =
ignite.cache("SQL_PUBLIC_" +
 getTableName()).withKeepBinary();
final ContinuousQuery qry = new
ContinuousQuery();
//   qry.setInitialQuery(new ScanQuery(new
IgniteBiPredicate()
//{
//@Override
//public boolean apply(Object key, BinaryObject val)
//{
//return !(val.field("FROM_RDC")).equals(localRDC);
//}
//}));
// qry.setRemoteFilterFactory(new
Factory>()
// {
// @Override
// public CacheEntryEventFilter create()
// {
// return new CacheEntryEventFilter()
// {
// @Override
// public boolean evaluate(CacheEntryEvent e)
// {
// return !(e.getValue().
field("FROM_RDC")).equals(localRDC);
// }
// };
// }
// });
qry.setLocalListener(new CacheEntryUpdatedListener()
{
@Override
public void onUpdated(Iterable> evts)
{
List resultList = new ArrayList(0);
int length = 0;
for (CacheEntryEvent e : evts)
{
resultList.add(buildObject(e));
}
writeObject(assemblyObject(resultList));
}
});
if (REAL_TIME_SYNC.contains(getTableName()))
{
qry.setTimeInterval(1000L);
}
else
{
qry.setTimeInterval(30L);
qry.setPageSize(1000);
}
cache.query(qry);
}
}

Basically,  1. intial query and remotefilter have same logic and just filter
some record according field value
2. in locallisnter,  writeObject() using mybatis write data to local DB. 
All class shows in "binary metadata update messages" actually in
writeObject() method, so why those stuff need to exchange among cluster?

Thanks,
Jin.



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Register Contentious query quit slow

2017-11-25 Thread gunman524 
Denis， thanks for your explain. 

I debugged the client side and found after I run cache.query(qry), the
client seems to deserialize all classes my code references to

[2017-11-25T15:47:50,347][DEBUG][disco-event-worker-#36][GridCachePartitionExchangeManager]
Do not start exchange for discovery event: DiscoveryCustomEvent
[customMsg=MetadataUpdateAcceptedMessage
[id=20d0058ef51-04f9942d-cf48-445a-8508-05c6d1e821bb, typeId=-1677406589,
acceptedVer=166, duplicated=false], affTopVer=AffinityTopologyVersion
[topVer=250, minorTopVer=0], super=DiscoveryEvent [evtNode=TcpDiscoveryNode
[id=e95753b3-7be4-498f-9dbe-87d197cfe355, addrs=[10.41.91.200, 127.0.0.1],
sockAddrs=[/10.41.91.200:47500, /127.0.0.1:47500], discPort=47500, order=19,
intOrder=11, lastExchangeTime=1511596050492, loc=false,
ver=2.3.0#20171028-sha1:8add7fd5, isClient=false], topVer=250,
nodeId8=7776ddf7, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1511596070347]]
[2017-11-25T15:47:50,347][DEBUG][main][CacheObjectBinaryProcessorImpl]
Requesting metadata update for -77171844
[2017-11-25T15:47:50,379][DEBUG][tcp-client-disco-sock-reader-#3][TcpDiscoverySpi]
Message has been received: TcpDiscoveryCustomEventMessage [msg=null,
super=TcpDiscoveryAbstractMessage
[sndNodeId=e95753b3-7be4-498f-9dbe-87d197cfe355,
id=1943522ff51-7776ddf7-c511-41d5-a566-5107d2d6f966,
verifierNodeId=e95753b3-7be4-498f-9dbe-87d197cfe355, topVer=250,
pendingIdx=0, failedNodes=null, isClient=false]]
[2017-11-25T15:47:50,379][DEBUG][tcp-client-disco-msg-worker-#4][TcpDiscoverySpi]
Discovery notification [node=TcpDiscoveryNode
[id=7776ddf7-c511-41d5-a566-5107d2d6f966, addrs=[0:0:0:0:0:0:0:1, 1.2.3.4,
127.0.0.1, 192.168.56.1], sockAddrs=[/0:0:0:0:0:0:0:1:0, /127.0.0.1:0,
/192.168.56.1:0, HOST_NAME.XXX..com/1.2.3.4:0], discPort=0, order=250,
intOrder=0, lastExchangeTime=1511596049874, loc=true,
ver=2.3.0#20171028-sha1:8add7fd5, isClient=true], type=DISCOVERY_CUSTOM_EVT,
topVer=250]
[2017-11-25T15:47:50,379][DEBUG][disco-event-worker-#36][GridCachePartitionExchangeManager]
Do not start exchange for discovery event: DiscoveryCustomEvent
[customMsg=MetadataUpdateProposedMessage
[id=1943522ff51-3f3ccb92-e4d9-44c0-b178-854b90dbfbf9,
origNodeId=7776ddf7-c511-41d5-a566-5107d2d6f966, metadata=BinaryMetadata
[typeId=-77171844, typeName=org.apache.ibatis.session.Configuration,
fields={logImpl=BinaryFieldMetadata [fieldId=342344548, typeId=32],
autoMappingUnknownColumnBehavior=BinaryFieldMetadata [fieldId=-333850733,
typeId=28], lazyLoadingEnabled=BinaryFieldMetadata [fieldId=-1856534791,
typeId=8], logPrefix=BinaryFieldMetadata [fieldId=-1514679594, typeId=9],
aggressiveLazyLoading=BinaryFieldMetadata [fieldId=-1718584124, typeId=8],
mapUnderscoreToCamelCase=BinaryFieldMetadata [fieldId=-286817803, typeId=8],
mappedStatements=BinaryFieldMetadata [fieldId=1731452759, typeId=103],
languageRegistry=BinaryFieldMetadata [fieldId=-940446827, typeId=103],
useGeneratedKeys=BinaryFieldMetadata [fieldId=-101509668, typeId=8],
incompleteResultMaps=BinaryFieldMetadata [fieldId=900998162, typeId=103],
reflectorFactory=BinaryFieldMetadata [fieldId=500612010, typeId=103],
cacheEnabled=BinaryFieldMetadata [fieldId=-1267415681, typeId=8],
caches=BinaryFieldMetadata [fieldId=-1368047311, typeId=103],
callSettersOnNulls=BinaryFieldMetadata [fieldId=-289605417, typeId=8],
incompleteStatements=BinaryFieldMetadata [fieldId=1257025730, typeId=103],
incompleteMethods=BinaryFieldMetadata [fieldId=841112724, typeId=103],
useColumnLabel=BinaryFieldMetadata [fieldId=926720375, typeId=8],
safeRowBoundsEnabled=BinaryFieldMetadata [fieldId=1691167967, typeId=8],
typeAliasRegistry=BinaryFieldMetadata [fieldId=1228666259, typeId=103],
autoMappingBehavior=BinaryFieldMetadata [fieldId=-1192801391, typeId=28],
jdbcTypeForNull=BinaryFieldMetadata [fieldId=1461105531, typeId=28],
vfsImpl=BinaryFieldMetadata [fieldId=380866659, typeId=32],
mapperRegistry=BinaryFieldMetadata [fieldId=1261051262, typeId=103],
incompleteCacheRefs=BinaryFieldMetadata [fieldId=1157355812, typeId=103],
defaultStatementTimeout=BinaryFieldMetadata [fieldId=1303620947, typeId=3],
lazyLoadTriggerMethods=BinaryFieldMetadata [fieldId=2058678228, typeId=103],
objectFactory=BinaryFieldMetadata [fieldId=-1947780885, typeId=103],
resultMaps=BinaryFieldMetadata [fieldId=-571115468, typeId=103],
loadedResources=BinaryFieldMetadata [fieldId=-310590528, typeId=103],
safeResultHandlerEnabled=BinaryFieldMetadata [fieldId=1128633633, typeId=8],
multipleResultSetsEnabled=BinaryFieldMetadata [fieldId=-459661949,
typeId=8], cacheRefMap=BinaryFieldMetadata [fieldId=1431520747, typeId=103],
defaultExecutorType=BinaryFieldMetadata [fieldId=-1339727026, typeId=28],
variables=BinaryFieldMetadata [fieldId=-82477705, typeId=103],
keyGenerators=BinaryFieldMetadata [fieldId=741028767, typeId=103],
defaultFetchSize=BinaryFieldMetadata [fieldId=-1429234534, typeId=3],
objectWrapperFactory=BinaryFieldMetadata [fieldId=-137856490, typeId=103],
databaseId=BinaryFieldMetadata

Re: Initial query resent the data when client got reconnect

2017-11-22 Thread gunman524 
Voted. Appreciated and looking for it.



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Register Contentious query quit slow

2017-11-22 Thread gunman524 
2 After I copied jar file to Ignite libs and start my app, the log on server
side shows:

[2017-11-22T08:14:17,585][INFO
][tcp-disco-msg-worker-#3][GridDeploymentLocalStore] Class locally deployed:
class
org.apache.ignite.configuration.CacheConfiguration$IgniteAllNodesPredicate
[2017-11-22T08:14:17,586][INFO
][tcp-disco-msg-worker-#3][GridDeploymentPerLoaderStore] Class was deployed
in Private or Isolated mode: class
org.apache.ignite.configuration.CacheConfiguration$IgniteAllNodesPredicate
[2017-11-22T08:14:17,588][INFO
][tcp-disco-msg-worker-#3][GridDeploymentLocalStore] Class locally deployed:
class com.aaa.bbb.service.ignite.service.AbstractIgniteListeningService$2
[2017-11-22T08:14:17,588][INFO
][tcp-disco-msg-worker-#3][GridDeploymentPerLoaderStore] Class was deployed
in Private or Isolated mode: class
com.aaa.bbb.service.ignite.service.AbstractIgniteListeningService$2
[2017-11-22T08:14:29,572][WARN ][query-#116][GridCacheDeploymentManager]
Ignoring deployment in PRIVATE or ISOLATED mode
[sndId=19d2e782-413c-4cbb-9c01-1a0fc6f3e1df,
ldrId=b45a011ef51-19d2e782-413c-4cbb-9c01-1a0fc6f3e1df, userVer=0,
mode=PRIVATE, participants=null, daemon=false]
[2017-11-22T08:14:29,574][INFO ][query-#116][GridDeploymentLocalStore] Class
locally deployed: class
com.aaa.bbb.service.ignite.service.AbstractIgniteListeningService$1
[2017-11-22T08:14:29,574][INFO ][query-#116][GridDeploymentLocalStore] Class
locally deployed: class
com.aaa.bbb.service.ignite.service.DraftShareUserService
[2017-11-22T08:14:29,575][INFO ][query-#116][GridDeploymentLocalStore] Class
locally deployed: interface com.aaa.bbb.service.ignite.dao.DraftShareUserDao
[2017-11-22T08:14:29,575][INFO ][query-#116][GridDeploymentLocalStore] Class
locally deployed: class org.apache.ibatis.binding.MapperProxy
[2017-11-22T08:14:29,575][INFO ][query-#116][GridDeploymentLocalStore] Class
locally deployed: class org.mybatis.spring.SqlSessionTemplate
[2017-11-22T08:14:29,576][INFO ][query-#116][GridDeploymentLocalStore] Class
locally deployed: class
org.apache.ibatis.session.defaults.DefaultSqlSessionFactory
[2017-11-22T08:14:29,576][INFO ][query-#116][GridDeploymentLocalStore] Class
locally deployed: class org.apache.ibatis.session.Configuration
[2017-11-22T08:14:29,576][INFO ][query-#116][GridDeploymentLocalStore] Class
locally deployed: class org.apache.ibatis.mapping.Environment
[2017-11-22T08:14:29,576][INFO ][query-#116][GridDeploymentLocalStore] Class
locally deployed: class
org.mybatis.spring.transaction.SpringManagedTransactionFactory
[2017-11-22T08:14:29,577][INFO ][query-#116][GridDeploymentLocalStore] Class
locally deployed: class org.apache.tomcat.jdbc.pool.DataSource
[2017-11-22T08:14:29,577][INFO ][query-#116][GridDeploymentLocalStore] Class
locally deployed: class org.apache.tomcat.jdbc.pool.PoolProperties
[2017-11-22T08:14:29,578][INFO ][query-#116][GridDeploymentLocalStore] Class
locally deployed: class org.apache.ibatis.session.LocalCacheScope
[2017-11-22T08:14:29,578][INFO ][query-#116][GridDeploymentLocalStore] Class
locally deployed: class org.apache.ibatis.type.JdbcType
[2017-11-22T08:14:29,578][INFO ][query-#116][GridDeploymentLocalStore] Class
locally deployed: class org.apache.ibatis.session.ExecutorType
[2017-11-22T08:14:29,578][INFO ][query-#116][GridDeploymentLocalStore] Class
locally deployed: class org.apache.ibatis.session.AutoMappingBehavior
[2017-11-22T08:14:29,579][INFO ][query-#116][GridDeploymentLocalStore] Class
locally deployed: class
org.apache.ibatis.session.AutoMappingUnknownColumnBehavior
[2017-11-22T08:14:29,579][INFO ][query-#116][GridDeploymentLocalStore] Class
locally deployed: class org.apache.ibatis.reflection.DefaultReflectorFactory
[2017-11-22T08:14:29,580][INFO ][query-#116][GridDeploymentLocalStore] Class
locally deployed: class
org.apache.ibatis.reflection.factory.DefaultObjectFactory
[2017-11-22T08:14:29,580][INFO ][query-#116][GridDeploymentLocalStore] Class
locally deployed: class
org.apache.ibatis.reflection.wrapper.DefaultObjectWrapperFactory
[2017-11-22T08:14:29,580][INFO ][query-#116][GridDeploymentLocalStore] Class
locally deployed: class org.apache.ibatis.binding.MapperRegistry
[2017-11-22T08:14:29,581][INFO ][query-#116][GridDeploymentLocalStore] Class
locally deployed: class org.apache.ibatis.binding.MapperProxyFactory
[2017-11-22T08:14:29,581][INFO ][query-#116][GridDeploymentLocalStore] Class
locally deployed: interface com.aaa.bbb.service.ignite.dao.IStepInstanceDao
[2017-11-22T08:14:29,581][INFO ][query-#116][GridDeploymentLocalStore] Class
locally deployed: interface com.aaa.bbb.service.ignite.dao.FaqDao
[2017-11-22T08:14:29,581][INFO ][query-#116][GridDeploymentLocalStore] Class
locally deployed: interface com.aaa.bbb.service.ignite.dao.KVRotationVODao
[2017-11-22T08:14:29,582][INFO ][query-#116][GridDeploymentLocalStore] Class
locally deployed: interface
com.aaa.bbb.service.ignite.dao.UserGuideSubClassVODao
[2017-11-22T08:14:29,582][INFO ][query-#116][GridDeploymentLocalStore] Class
locally

Re: Register Contentious query quit slow

2017-11-21 Thread gunman524 
1.  *For Ignite cluster initialization, here is the log *

[2017-11-22T08:01:56,975][INFO ][main][IgniteKernal] Non-loopback local IPs:
10.41.91.200
[2017-11-22T08:01:56,975][INFO ][main][IgniteKernal] Enabled local MACs:
286ED488CFC0
[2017-11-22T08:03:36,496][INFO ][tcp-disco-srvr-#2][TcpDiscoverySpi] TCP
discovery accepted incoming connection [rmtAddr=/1.2.3.4, rmtPort=3918]
[2017-11-22T08:03:36,509][INFO ][tcp-disco-srvr-#2][TcpDiscoverySpi] TCP
discovery spawning a new thread for connection [rmtAddr=/1.2.3.4,
rmtPort=3918]
[2017-11-22T08:03:36,510][INFO ][tcp-disco-sock-reader-#4][TcpDiscoverySpi]
Started serving remote node connection [rmtAddr=/1.2.3.4:3918, rmtPort=3918]
[2017-11-22T08:03:36,538][INFO ][tcp-disco-sock-reader-#4][TcpDiscoverySpi]
Finished serving remote node connection [rmtAddr=/1.2.3.4:3918, rmtPort=3918
[2017-11-22T08:03:41,681][INFO ][tcp-disco-srvr-#2][TcpDiscoverySpi] TCP
discovery accepted incoming connection [rmtAddr=/5.6.7.8, rmtPort=46327]
[2017-11-22T08:03:41,682][INFO ][tcp-disco-srvr-#2][TcpDiscoverySpi] TCP
discovery spawning a new thread for connection [rmtAddr=/5.6.7.8,
rmtPort=46327]
[2017-11-22T08:03:41,682][INFO ][tcp-disco-sock-reader-#5][TcpDiscoverySpi]
Started serving remote node connection [rmtAddr=/5.6.7.8:46327,
rmtPort=46327]
[2017-11-22T08:03:42,127][INFO ][tcp-disco-sock-reader-#5][TcpDiscoverySpi]
Finished serving remote node connection [rmtAddr=/5.6.7.8:46327,
rmtPort=46327
[2017-11-22T08:03:46,145][INFO ][tcp-disco-srvr-#2][TcpDiscoverySpi] TCP
discovery accepted incoming connection [rmtAddr=/5.6.7.8, rmtPort=36082]
[2017-11-22T08:03:46,145][INFO ][tcp-disco-srvr-#2][TcpDiscoverySpi] TCP
discovery spawning a new thread for connection [rmtAddr=/5.6.7.8,
rmtPort=36082]
[2017-11-22T08:03:46,146][INFO ][tcp-disco-sock-reader-#6][TcpDiscoverySpi]
Started serving remote node connection [rmtAddr=/5.6.7.8:36082,
rmtPort=36082]
[2017-11-22T08:03:46,540][INFO ][tcp-disco-sock-reader-#6][TcpDiscoverySpi]
Finished serving remote node connection [rmtAddr=/5.6.7.8:36082,
rmtPort=36082
[2017-11-22T08:03:48,934][INFO ][tcp-disco-srvr-#2][TcpDiscoverySpi] TCP
discovery accepted incoming connection [rmtAddr=/5.6.7.8, rmtPort=33224]
[2017-11-22T08:03:48,935][INFO ][tcp-disco-srvr-#2][TcpDiscoverySpi] TCP
discovery spawning a new thread for connection [rmtAddr=/5.6.7.8,
rmtPort=33224]
[2017-11-22T08:03:48,935][INFO ][tcp-disco-sock-reader-#7][TcpDiscoverySpi]
Started serving remote node connection [rmtAddr=/5.6.7.8:33224,
rmtPort=33224]
[2017-11-22T08:03:49,338][INFO ][tcp-disco-sock-reader-#7][TcpDiscoverySpi]
Finished serving remote node connection [rmtAddr=/5.6.7.8:33224,
rmtPort=33224
[2017-11-22T08:03:52,522][INFO ][tcp-disco-srvr-#2][TcpDiscoverySpi] TCP
discovery accepted incoming connection [rmtAddr=/5.6.7.8, rmtPort=33160]
[2017-11-22T08:03:52,522][INFO ][tcp-disco-srvr-#2][TcpDiscoverySpi] TCP
discovery spawning a new thread for connection [rmtAddr=/5.6.7.8,
rmtPort=33160]
[2017-11-22T08:03:52,524][INFO ][tcp-disco-sock-reader-#8][TcpDiscoverySpi]
Started serving remote node connection [rmtAddr=/5.6.7.8:33160,
rmtPort=33160]
[2017-11-22T08:03:52,954][INFO ][tcp-disco-sock-reader-#8][TcpDiscoverySpi]
Finished serving remote node connection [rmtAddr=/5.6.7.8:33160,
rmtPort=33160
[2017-11-22T08:03:56,974][INFO ][tcp-disco-srvr-#2][TcpDiscoverySpi] TCP
discovery accepted incoming connection [rmtAddr=/5.6.7.8, rmtPort=48364]
[2017-11-22T08:03:56,974][INFO ][tcp-disco-srvr-#2][TcpDiscoverySpi] TCP
discovery spawning a new thread for connection [rmtAddr=/5.6.7.8,
rmtPort=48364]
[2017-11-22T08:03:56,975][INFO ][tcp-disco-sock-reader-#9][TcpDiscoverySpi]
Started serving remote node connection [rmtAddr=/5.6.7.8:48364,
rmtPort=48364]
[2017-11-22T08:03:57,368][INFO ][tcp-disco-sock-reader-#9][TcpDiscoverySpi]
Finished serving remote node connection [rmtAddr=/5.6.7.8:48364,
rmtPort=48364
。
[2017-11-22T08:05:06,021][INFO
][disco-event-worker-#41][GridDiscoveryManager] Topology snapshot [ver=3,
servers=3, clients=0, CPUs=20, heap=16.0GB]

*I wondered why connecting so many port, as my configuration is like*

1.2.3.4:47500
  5.6.7.8:47500
 9.10.11.12:47500





--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Register Contentious query quit slow

2017-11-21 Thread gunman524 
BTW, the deployment mode I use is PRIVATE, does it matter?



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Register Contentious query quit slow

2017-11-21 Thread gunman524 
Hi there,

I have write an app with contentious query feature and pack as a single jar,
as depend on some 3rd party lib so it's quite big, 40M.

For local cluster, the app start quit fast and can be startup within 20
secs. But after add one more cross region node, this app need around 10 mins
to startup!!

I guess it because of peer class loading, so I copied that jar to every
ignit node
libs
├── annotations-13.0.jar
├── cache-api-1.0.0.jar
├── ignite-core-2.3.0.jar
├── ignite-indexing
├── ignite-log4j2
├── ignite-rest-http
├── ignite-shmem-1.0.0.jar
├── ignite-spring
├── my_app.jar
├── licenses
├── optional

After restart cluster, restart app, still need 10+ mins.
Is there something wrong here? Or need extra setting?



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Initial query resent the data when client got reconnect

2017-11-21 Thread gunman524 
Mike, double checked Mongodb way, their ObjectID only provide a unique ID,
sorry for my info.   But there is open source project provide the auto
increment feature for mongodb.  



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Failed to connect to address issue

2017-11-19 Thread gunman524 
Mikhail,

The log is not easy to get and I'll try to get it.

The top of my cluster looks like 
Hosts: 2
+==+
|   Int./Ext. IPs|   Node ID8(@)| Node Type |   OS  

| CPUs |   MACs| CPU Load |
+==+
| 0:0:0:0:0:0:0:1| 1: AF24846C(@n1) | Server| Windows 7 amd64 6.1   

| 4| 0A:00:27:00:00:0D | 0.00 %   |
| 10.xxx.xxx.205 |  |   |   

|  | 28:6E:D4:89:79:4E |  |
| 127.0.0.1  |  |   |   

|  |   |  |
| 192.168.56.1   |  |   |   

|  |   |  |
++--+---++--+---+--+
| 0:0:0:0:0:0:0:1%lo | 1: E0370B02(@n0) | Server| Linux amd64
3.13.0-107-generic | 8| 02:42:46:99:28:C9 | 0.07 %   |
| 10.xxx.xxx.196 |  |   |   

|  | 28:6E:D4:86:82:AD |  |
| 127.0.0.1  |  |   |   

|  | EE:9A:8A:04:24:36 |  |
| 172.17.0.1 |  |   |   

|  |   |  |
+--+

Is that normal?  only 10.xxx.xxx.205  and 10.xxx.xxx.196 is what i
configured but what about others?  Does ignite will try to connect other
IPs?



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Apache Ignite binary type invalidation

2017-11-19 Thread gunman524 
Alexey, that's cool. I'll try it out



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Scan query failed if set deploymentMode to Private

2017-11-19 Thread gunman524 
Thanks, Mikhail. 

It can be reproduce by using example code *CacheContinuousQueryExample.java*



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Initial query resent the data when client got reconnect

2017-11-19 Thread gunman524 
Thanks, Alexey. I think it's a valuable feature and ask for an enhancement. I
knew  AtomicSequence but in my case I might prefer to JDBC thin client for
data injecting, so might not able to use AtomicSequence 



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Failed to connect to address issue

2017-11-17 Thread gunman524 
Hi there,

My cluster always has the exception like below

at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1874)
[ignite-core-2.3.0.jar!/:2.3.0]
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1758)
[ignite-core-2.3.0.jar!/:2.3.0]
at
org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
[ignite-core-2.3.0.jar!/:2.3.0]
Caused by:
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$HandshakeException:
*Remote node ID is not as expected
*[expected=367d0c21-90d8-4717-a909-593392dd9ba1,
rcvd=4903508d-2b22-4fbc-88ad-01cd9f17f364]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.safeHandshake(TcpCommunicationSpi.java:3442)
~[ignite-core-2.3.0.jar!/:2.3.0]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3135)
~[ignite-core-2.3.0.jar!/:2.3.0]
... 94 more
*Suppressed: org.apache.ignite.IgniteCheckedException: Failed to connect
to address [addr=/127.0.0.1:47100, err=Remote node ID is not as expected
[expected=367d0c21-90d8-4717-a909-593392dd9ba1,
rcvd=4903508d-2b22-4fbc-88ad-01cd9f17f364]]*
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3293)
~[ignite-core-2.3.0.jar!/:2.3.0]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2839)
~[ignite-core-2.3.0.jar!/:2.3.0]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2726)
~[ignite-core-2.3.0.jar!/:2.3.0]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2587)
~[ignite-core-2.3.0.jar!/:2.3.0]

Why Ignite tried to connect 127.0.0.1 because I use static IP finder and my
config file looks like 

http://www.springframework.org/schema/beans;
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
   xsi:schemaLocation="
   http://www.springframework.org/schema/beans
   http://www.springframework.org/schema/beans/spring-beans.xsd;>



 
 
 
 























10.xxx.xxx.xxx:47500..47509
10.xxx.xxx.xxx:47500..47509












--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Scan query failed if set deploymentMode to Private

2017-11-16 Thread gunman524 
Hi there,

I found a issue that if we set deploymentMode  to Private and using
ScanQuery for in InitialQuery. The inital query will failed for *Class not
found* error. Meanwhile, the remoteFilter and LocalListener works fine. 

After change ScanQuery to SQLQuery, everything works fine.

Is this a bug for someting?  Ingite I use is version 2.3

Thanks,



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Using event to reconnect spring created cache client to server

2017-11-16 Thread gunman524 
guil, could you share your solution?

Many thanks



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Initial query resent the data when client got reconnect

2017-11-16 Thread gunman524 
Alexey, thanks for reply.

I wondered does Ignite will set a incremental value for incoming data so can
help people to do stuff like you said?

You know for isolate data pushers are not easy to generate a unique
incremental value. I know many distribute data store,like elastisearch,mango
has those  build-in field.

So, how about Ignite, does we already has one but just I don;t know? 

Thanks,

Gin



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Failed to run map query remotely

2017-11-16 Thread gunman524 
Hi, guys

I meet a error when using SQL to query cache. It happens when Ignite server
restart after OOEM issue.

Could you help me figure out why this happens? 

[2017-11-16T14:59:36,937][ERROR][client-connector-#45][JdbcRequestHandler]
Failed to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest
[schemaName=PUBLIC, pageSize=1024, maxRows=200, sqlQry=SELECT * FROM
A_USERGUIDE_T, args=[], stmtType=ANY_STATEMENT_TYPE]]
javax.cache.CacheException: Failed to run map query remotely.
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:748)
~[ignite-indexing-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1212)
~[ignite-indexing-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
~[ignite-core-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcQueryCursor.(JdbcQueryCursor.java:61)
~[ignite-core-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:311)
[ignite-core-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:164)
[ignite-core-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:137)
[ignite-core-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:39)
[ignite-core-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
[ignite-core-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
[ignite-core-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
[ignite-core-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
[ignite-core-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
[ignite-core-2.3.0.jar:2.3.0]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[?:1.8.0_74]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[?:1.8.0_74]
at java.lang.Thread.run(Thread.java:745) [?:1.8.0_74]
Caused by: javax.cache.CacheException: Failed to execute map query on the
node: 70079981-49c1-4613-9e41-b75fae988122, class
org.apache.ignite.IgniteCheckedException:Failed to execute SQL query.
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.fail(GridReduceQueryExecutor.java:274)
~[ignite-indexing-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.onFail(GridReduceQueryExecutor.java:264)
~[ignite-indexing-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.onMessage(GridReduceQueryExecutor.java:243)
~[ignite-indexing-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.sendError(GridMapQueryExecutor.java:854)
~[ignite-indexing-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest0(GridMapQueryExecutor.java:731)
~[ignite-indexing-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest(GridMapQueryExecutor.java:516)
~[ignite-indexing-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onMessage(GridMapQueryExecutor.java:214)
~[ignite-indexing-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$1.applyx(GridReduceQueryExecutor.java:153)
~[ignite-indexing-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$1.applyx(GridReduceQueryExecutor.java:151)
~[ignite-indexing-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
~[ignite-core-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.send(IgniteH2Indexing.java:2191)
~[ignite-indexing-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.send(GridReduceQueryExecutor.java:1420)
~[ignite-indexing-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:733)
~[ignite-indexing-2.3.0.jar:2.3.0]
... 15 more


Thanks,



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Initial query resent the data when client got reconnect

2017-11-15 Thread gunman524 
I tried to use contentious query to monitor a cache and set initial query,
LocalListener and RemoteFilter as example did.

The issue I met is when client reconnect to Ignite cluster, the initial
query will query the data from cache which the client might already got
before.

I tried to use unchanged ID or instance name

/cfg.setConsistentId("de01");
cfg.setIgniteInstanceName("test1");  /

but does not work.

*Is any way to solve this issue?*

Many thanks,



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Apache Ignite binary type invalidation

2017-11-15 Thread gunman524 
I've createted the binary type with the name 'someField' and the field type
is "String".
Now I want to change it from string to int. But I don't want to change the
name of the type, but I got an exception while cache populating:

javax.cache.CacheException:class 
org.apache.ignite.binary.Binary0bjectException:Binary type has different
field
types[typeName=com.xxx.service.ignite.vo.AnnounceProjectVO,fieldName=announceld,fieldTypeNamel=long,fieldTypeName2=String]

I tried to destroy the original cache, but does not work. Looks the meta
data had be cached, can it be refresh?

Thanks



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

"Duplicate field ID" Error when register a contentious query

2017-11-15 Thread gunman524 
Hi guys,

I met a issue that "Duplicate field ID" Error occurs when register a
contentious query.

Here is my case:

1. Start a jdbc client and use SQL to create table and insert record

2. Start  a another client and using contentious query to monitor table and
insert the income data to another Mysql DB using Mybatis in setLocalListener

But that error might  occur sometimes when data injecting and  Listener
registering 

javax·cach.Exception:clas,org.apach.ignite.binary.Binarvobl.ctException:Duplicat.fieldID:profil.SQL
 at
org.apache.ignite.internal.processors.cache.igniteCacheProxylmpl.query(ignitegcheProxyImpl.iava:597)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedcacheProxy.java:368)

After deep analyze, we fond mySQL jdbc driver has to method, profileSQL and
profileSql, and they will have same hascode after serialization

private com.mysql.jdbc.ConnectionPropertiesImpl$BooleanConnectionProperty
com.mysql.jdbc.ConnectionPropertiesImpl.profileSQL

My question is, why Ignite need  to serialize mysql driver? Does it mean the
code in setLocalListener need to send to Ignite cluster?  

How can we avoid this issue?

Many thanks





--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Can JAVA API SqlQuery query a cache create by SQL DDL?

2017-11-15 Thread gunman524 
vkulichenko， thanks for your advice。 It works, by setting value_type=person
during DDL, then running 
SqlQuery sql = new SqlQuery("person","id >? and id http://apache-ignite-users.70518.x6.nabble.com/

Can JAVA API SqlQuery query a cache create by SQL DDL?

2017-11-14 Thread gunman524 
Hi guys,

I use JDBC client driver to create a table,like:

stmt.executeUpdate("CREATE TABLE IF NOT EXISTS person ( id int,orgId LONG,
name VARCHAR, salary LONG ,PRIMARY KEY (id)) WITH \"backups=1,
affinityKey=id\"");

Could I use SqlQuery API to query this cache? I tried this way but does not
work

IgniteCache cache =
ignite.cache("SQL_PUBLIC_PERSON").withKeepBinary();
SqlQuery sql = new SqlQuery("SQL_PUBLIC_PERSON","id >? and id > cursor =
cache.query(sql.setArgs(5,10))) {
for (Map.Entry e : cursor)
System.out.println(e.getValue().toString());
}

Thanks



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/