Re: JDBC store Date deserialization problem

[franck102]

Thanks Vasiliy, the transformer indeed still works fine.

I wasn't properly installed in the 2.2.0 test I used, my mistake.

Franck



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

Re: JDBC store Date deserialization problem

[franck102]

My bad, the issue is not resolved but my transformer workaround was not
properly installed.

Franck



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

Re: JDBC store Date deserialization problem

[franck102]

Hi Val,

Was this fixed in 2.2.0? It looks like my workaround doesn't work anymore
with that version...

SQL_TYPES now includes java.util.Date, however the type of my binary field
is ignored when serializing by the (very strange...) implementation of
org.apache.ignite.internal.binary.builder.BinaryValueWithType:
coming out of the store I have a nice instance with { val=;
type=11 }, and the writeTo method ignores the type field and lets the
context serialize the field (ctx.writeValue).

The context uses the Map below, which is missing java.util.Date :(





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

Re: Security question

[franck102]

Thanks Dmitry, that makes sense, we will make sure that client-side code is
trusted.

Franck



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

Re: Security question

[franck102]

Wow. That means any client who can get past node authentication on join can
do anything they like on all caches, including all admin commands.

The node validation logic won't help at all - the join request may claim
that a given security processor is used, but subsequent requests can
perfectly be contructed client-side without going through client-side
security.

Unless I am missing something this sounds like a pretty serious issue.

Franck



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

Security question

[franck102]

Hi all,

Stepping through the code during a cache.get() request from a client node to
a server node, I don't see that GridSecurityProcessor.authorize will ever be
called on the server node?

Authorize is called on the client node, but on the server node the code goes
straight to GridCacheAdapter#getAllAsync0 which skips the ctx.checkSecurity
call??

If that is the case any node which is able to connect can easily do anything
on a cache using custom client code to bypass client-side security... am I
missing something?

Thanks!
Franck



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

Re: Cache pre-loading question

[franck102]

IgniteCache has a loadCache method and that is what I am using currently, but
I have seen many recommendations here and in the docs to a streamer rather
than loadCache (because loadCache is not transactional, can lead to
out-of-sync data if the topology changes...), e.g.:

https://apacheignite.readme.io/docs/data-loading 
"Data streamers should be used to load large amount of data into caches at
any time, including pre-loading on startup."

I am currently using loadCache on a client node, which if I understand
correctly simply dispatches a loadCache task to all nodes in the cluster.
What I am trying to achieve is pretty simple - assuming for example a
10-node cluster with a partitioned cache with backups=1:
I want a client to send an instruction to the 2 relevant nodes (primary and
backup) to pre-load the cache, using logic & mappings defined in the cache
configuration; and I need some way to detect/recover from nodes failing in
the process.

I isn't very clear to me how I can achieve that though...

Franck



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

Re: Cache pre-loading question

[franck102]

Hi Alex, what do you mean by custom? 

I am indeed using a CacheJdbcPojoStore, it has the method I need 
(loadCache(final IgniteBiInClosure clo, @Nullable Object... args)) 

however I can't obtain a reference to the store from my ignite instance. 

I can try to build an instance of the store outside Ignite however that 
means (at best) maintaining its configuration separately from the rest of 
the Ignite config... 

What I'd like to do instead is: 


... however that loadCache method exists on the cache store, but not on the
cache :( 

Franck 




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

Re: Cache pre-loading question

[franck102]

Hi Alex, what do you mean by custom?

I am indeed using a CacheJdbcPojoStore, it has the method I need
(loadCache(final IgniteBiInClosure clo, @Nullable Object... args)) 

however I can't obtain a reference to the store from my ignite instance.

I can try to build an instance of the store outside Ignite however that
means (at best) maintaining its configuration separately from the rest of
the Ignite config... 

What I'd like to do instead is:



... however there is no IgniteCache.getStore API :(

Franck




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

Cache pre-loading question

[franck102]

Hi all, I am trying to figure out the best approach for pre-loading cache
entries from a SQL DB on startup.

I have read the recommendations to use a client node and a data streamer to
pre-load cache data on startup.

One issue I see with the approach however, compared with cache.loadCache(),
is that I can't seem to easily reuse the CacheStore.loadCache
implementations - is there any way to do so?

My (JDBC) cache store configuration contains logic to map the DB schema to
the cache schema; it seems that I would need to replicate that logic in the
loader client in order to call streamer.addData()?

Thanks!
Franck



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

Re: Authentication

[franck102]

Hi all,

I am reviving this thread because as far as I can tell the initial question
was not answered, and I am hitting the same problem:
"* when a node starts up it needs to fetch the local password and store it
in it's own configuration "

... and I can't figure out how to do that?? The only place where the TCP SPI
reads credentials from when creating its join request is from the
org.apache.ignite.security.cred, which as mentioned cannot be set because
the key name is reserved??

Franck



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

Re: Custom SecurityCredentialsProvider and SecurityCredentials

[franck102]

What is even more confusing is that SecurityCredentialsProvider is in fact
only used in GridClient and GridTcpRouter configurations. If I understans
correctly GridClient is in turn only used by the cmd line client, and by the
deprecated legacy jdbc connection.

So, what is the proper strategy for supplying custom credentials or better a
custom credential provider for a client node?
The only way I see is to get locNode.attributes to contain a
org.apache.ignite.security.cred  key however that can't even be set from
user attributes in the configuration...

Franck



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

Re: Confused about QueryEntity configuration

[franck102]

Hi Val,

I am able to use _key sucessfully, that is acceptable.

I tried defining an alias, using all combinations of _key/DB name and all
orders, and I couldn't get that to work.

Looking through the code it seems to me that aliases are only used to map
result column names to binary object field names; they are not used to
"rewrite" the query to replace java names with SQL names that the SQL engine
would understand - so aliases probably cannot help here.

Franck



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

Re: Custom SecurityCredentialsProvider and SecurityCredentials

[franck102]

I can implement my own flavor of SecurityCredentialsProvider yes.
But the Ignite code will not use it no matter what I do - unless I missed
something.

Franck



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

Re: Confused about QueryEntity configuration

[franck102]

Thanks Val, I meant #1 indeed. Using _key works.

What I'd like to achieve is for users to be able to use javaNames in their
queries, rather than "_key" or databaseFieldName: I consider the javaName as
a public API, whereas "_key" or the database field name are implementation
details that are subject to change.

But if I understand correctly there is no way to achieve that with aliases,
unless I duplicate the key in the value object which I would rather not
do...
The aliases it seems are not used to "rewrite" incoming SQL queries, they
are used to map to the binary object after the query has been executed,
right?

Franck



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

Custom SecurityCredentialsProvider and SecurityCredentials

[franck102]

Hi all,

I can't figure out how to install a custom security credentials provider?
The javadoc says 


... however GridClientConfiguration hardcodes an instance of
SecurityCredentialsBasicProvider, and ServerImpl directly gets credentials
from node.attributes(IgniteNodeAttributes.ATTR_SECURITY_CREDENTIALS).

Am I missing something, is it possible to install a custom provider that
uses a subclass of SecurityContext?

Thanks!
Franck



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

Re: Confused about QueryEntity configuration

[franck102]

Thanks Vasiliy!

#1 works fine, I can go with that

I can't get #2 to work, with this configuration:



I get the exception below:





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

Re: JDBC store Date deserialization problem

[franck102]

Thanks Val!



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/JDBC-store-Date-deserialization-problem-tp16276p16355.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Failure to deserialize simple model object

[franck102]

Awesome, thanks!

Franck



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Failure-to-deserialize-simple-model-object-tp15440p16333.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: JDBC store Date deserialization problem

[franck102]

BTW, if I remember correctly the server write -2 as a type ID because
java.util.Date is not in this array:

org.apache.ignite.internal.processors.query.QueryUtils#SQL_TYPES

If I use java.sql.Date in the Ignite configuration I get a different
exception (Wrong value has been set).

Franck



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/JDBC-store-Date-deserialization-problem-tp16276p16331.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: JDBC store Date deserialization problem

[franck102]

I understand for the store implementation, thanks.

I have attached a sample project, simply run this test (Ignite and DB are
embedded):

ignite-binary-sample.zip

  

org.apache.ignite.sample.test.ServerTests#loadItem

... and you get the exception below:

javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
Unexpected field type [pos=24, expected=Date, actual=-2]

at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1312)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.cacheException(IgniteCacheProxy.java:2630)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.get(IgniteCacheProxy.java:1188)
at 
org.apache.ignite.sample.test.ServerTests.loadItem(ServerTests.java:92)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at 
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: class org.apache.ignite.IgniteCheckedException: Unexpected field
type [pos=24, expected=Date, actual=-2]
at 
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7229)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:258)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:189)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:139)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4499)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4480)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1324)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.get(IgniteCacheProxy.java:1181)
... 25 more
Caused by: class org.apache.ignite.binary.BinaryObjectException: Unexpected
field type [pos=24, expected=Date, actual=-2]
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.checkFlagNoHandles(BinaryReaderExImpl.java:1676)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readDate(BinaryReaderExImpl.java:1169)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readDate(BinaryReaderExImpl.java:1164)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.readFixedType(BinaryFieldAccessor.java:757)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:679)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:164)
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:843)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
   

Re: Confused about QueryEntity configuration

[franck102]

empNo is in fact the key. 

I have attached a small sample project that demonstrates the problem; I can
in fact make the query work normally if I add keyFieldName=empNo to the
queryEntity configuration.
I don't see why this is required, for example with another cache that uses a
composite key:
TitlesCache: keyFields: { empNo, date_from }

... I can perfectly execute "select empNo from Titles" and I get non-null
values.

To reproduce the problem:
- mvn clean install
- Run the org.apache.ignite.sample.test.ServerTests#queryKey test

The configuration is in ignite-server/src/main/resources/ignite-server.xml

Franck

ignite-binary-sample.zip

  



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

Re: Confused about QueryEntity configuration

[franck102]

After some experimentation I have one answer, and more questions :)

I guess QueryEntity.keyType is only used to identify which objects will be
considered in the queries - I had forgotten that a cache can contain objects
of multiple types.

I am still struggling to configure queries for a JDBC store though. With
this store configuration:



...and this QueryEntity:



... running 
returns the expected number of results, but the single value inside the
result is null.

If I copy the JdbcTypeField from keyFields and add it to valueFields then
the query works as expected... so question is, are SQL field queries only
able to extract values from valueFields?

I also wonder what the aliases are for? I would prefer to use "SELECT empNo
..." in my queries, but I can't figure out how to configure that?

Thanks!
Franck



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

Confused about QueryEntity configuration

[franck102]

Hi all,

Despite reading the doc many times I can't quite figure out how SQL queries
should be configured. In particular what is query.keyType used for in that
context?
The key type doesn't seem to have any impact on what SQL queries I can
execute on the cache?
Does it simply have to match the cache key type for things to work
internally?

Say for example I have this (pseudo-code) CacheConfiguration:


... what can I / should I use for a keyType in the QueryEntities I define on
the cache? And what will the impact be on the SQL queries I can execute
agains the cache?

Thanks!
Franck




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

Re: JDBC store Date deserialization problem

[franck102]

Here is a related issue: if I install a custom JdbcTypesTransformer on my
JDBC store, I have to make that transformer class available on client nodes
- else discovery fails with the exception below.

It would be nice if client nodes didn't have to have dependencies on cache
store implementations, you would expect a client to never have to deal with
the cache store?

Franck

org.apache.ignite.IgniteCheckedException: Failed to find class with given
class loader for unmarshalling (make sure same versions of all classes are
available on all nodes or enable peer-class-loading)
[clsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2,
cls=com.fico.dmp.data.registry.jdbc.DateAwareTransformer]
at
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:124)
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
at
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:143)
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
at
org.apache.ignite.spi.discovery.tcp.internal.DiscoveryDataPacket.unmarshalData(DiscoveryDataPacket.java:274)
at
org.apache.ignite.spi.discovery.tcp.internal.DiscoveryDataPacket.unmarshalGridData(DiscoveryDataPacket.java:117)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1820)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1985)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1864)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1758)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
Caused by: java.lang.ClassNotFoundException:
com.fico.dmp.data.registry.jdbc.DateAwareTransformer
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at
org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8465)
at
org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:54)
at 
java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1819)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1713)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1986)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1535)
at 
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2231)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2155)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2013)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1535)
at 
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2231)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2155)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2013)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1535)
at 
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2231)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2155)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2013)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1535)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:422)
at java.util.HashMap.readObject(HashMap.java:1404)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1058)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2122)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2013)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1535)
at 
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2231)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2155)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2013)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1535)
 

JDBC store Date deserialization problem

[franck102]

Hi all,

I am using a JDBC store with storeKeepBinary enabled, and getting a single
value that has a SQL date column. The JdbcTypeField for that column has
javaFieldType == java.util.Date.

The  JdbcTypesDefaultTransformer however return java.sql.Date as a value for
the field:



As a result the BinaryObjectBuilder writes that field using the optimized
marshaller (type id -2); and on the client side deserialization fails
because the readers expects typeId=11 for that field (java.util.Date).

I can't use java.sql.Date in my Pojo (it is used in other non-SQL stores)...
shouldn't the transformer be improved to create a java.util.Date value?

Thanks,
Franck



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/JDBC-store-Date-deserialization-problem-tp16276.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Centralized configuration management

[franck102]

Thanks Alex!



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

Re: Client requires DataSource bean configuration copy

[franck102]

In case someone else hits this, the issue is easily resolved by embedding
cachestore and datasource facotyr beans in the cache bean, instead of using
spring references:



Franck



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Client-requires-DataSource-bean-configuration-copy-tp15491p16166.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Centralized configuration management

[franck102]

Hi Alex,

Regarding this statement:
"When you destroy or create a cache from a client node, there generally no
need to have/propagate the configuration manually to remote nodes.
*On join/restart*, a node will find out the caches configured in the cluster
and all the required routines will take place."

I assume that after destroying the cache, simply calling GetOrCreateCache
locally on the client node will be enough for remote server nodes to pick up
the new cache and its configuration - without having to restart them?



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

Re: Centralized configuration management

[franck102]

I need to be a bit more specific I guess.
I need the ability to create new caches, or to update the configuration of
existing caches.
When updating the configuration of a cache other caches should not be
affected - so a node restart is not a great option.

Would this plan work:
- The controller contains a client node; and also serves XML configuration
for all cluster nodes through a REST endpoint
- When an existing cache configuration is updated, the controller
  1. updates the persistent configuration that it returns through the REST
endpoint
  2. destroys the cache
  3. Recreates it use GetOrCreateCache

I assume that 2. and 3. above will propagate the changes to the entire
cluster? And 1. should take care of any late joiners or future restarts?

Franck





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

Centralized configuration management

[franck102]

Hi all,

I am trying to design a controller that will be responsible for managing the
cache configuration of all nodes in a cluster. Having read this in the docs:

"All caches defined in Ignite Spring XML configuration on any cluster member
will also be automatically created and deployed on all the cluster servers
(no need to specify the same configuration on each cluster member)."...

I am thinking of having that controller start a client node and join the
cluster. This raises a few questions though:

- If I update the configuration on the controller, can I manually trigger a
re-deployment to all nodes?
- on configuration changes I can re-create the client node and have it
re-join the cluster: will that trigger a re-deployment of the controller's
cache configuration? Or will that trigger an error because two different
cnofigurations exist for the same cache?
- If that is what it takes, is there any node-2-node or REST API I can use
to restart each node in the cluster?

Any other suggestion to design a configuration manager that can control the
cache configuration for an entire cluster is welcome... thanks!

Franck



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

Re: Failure to deserialize simple model object

[franck102]

My bad, here is the whole project.

Franck ignite-binary-sample.zip

  



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Failure-to-deserialize-simple-model-object-tp15440p16158.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Failure to deserialize simple model object

[franck102]

BTW if you experiment around you will want to clean up the work/marshallers
directories on server & client between tests; once the typeId is saved there
the problem goes away obviously...

Franck



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Failure-to-deserialize-simple-model-object-tp15440p15709.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Failure to deserialize simple model object

[franck102]

Hi Mikhail,

I have extracted the simplest possible configuration, I have attached a
self-contained project that uses an in memory H2 database and reproduces the
problem, here are the steps:

1. mvn install in the root
2. run the junit test org.apache.ignite.sample.test.ServerTests#runIgnite
(this starts the server node, the test method won't return)
3. run the junit test
org.apache.ignite.sample.test.client.ClientTests#loadItem: this starts a
client that tries to get a single entry from the cache.

I get this stack trace, and just as before adding a dummy binary
configuration that simply mentioned the Employees type fixes the problem:





--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Failure-to-deserialize-simple-model-object-tp15440p15708.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

GridGain vs. ignite maven artifacts

[franck102]

Hi all, the online Web console mentioned in the Ignite docs generates code
that points to 2.1.2 ignite artifacts in this repository:

   

On maven central the latest release I can find is 2.0.0... so what do you
recommend I should use?

Are the GridGain artifacts a fork of the Ignite code base? Or will an Ignite
release eventually include everything that is in those artifacts?

Thanks!
Franck



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

Re: Client requires DataSource bean configuration copy

[franck102]

Thanks Val, that makes sense.



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Client-requires-DataSource-bean-configuration-copy-tp15491p15576.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Client requires DataSource bean configuration copy

[franck102]

I have a single server defining a cachestore on top of a JDBC data source
using the attached spring configuration.
I connect a single client, and I don't need to replicate the cache
configuration in the client: the client downloads it from the server on
startup. However I still need to declare the datasource bean that the
cache(s) use - else I get the exception below.
Is that an oversight, or some exchange / spring beans ordering problem? It
looks like if CacheStore exchange is supported then the lower-level beans
the cache depends on should be exchanged as well?
Can I force the client to synchronize / download data sources from the
server before the cache configuration exchange happens?

Thanks!

Mac_Franck-server.xml

  




--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Client-requires-DataSource-bean-configuration-copy-tp15491.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Failure to deserialize simple model object

[franck102]

Hi Mikhail,

I have subscribed to the mailing list - just didn't long enough before
posting :(

I have attached the POM. Since my post I tried a couple more things:

- I removed the CacheConfiguration elements from the client; I can still
find the server's partitioned caches in ignite.cacheNames(), so I guess
replicating cache configuration on the client is not needed. I wonder why
the webConsole generates it by default; and this is far from obvious for the
documentation...

- With that I still get the exact same problem trying to deserialize a
single cache entry. What I don't understand is that throughout the entire
documentation I see that BinaryMarshaller will be the default if I don't
specify a specific marshaller.
The source code however still creates JdkMarshallers in many places (4-5
when breaking in debug mode), and a JdkMarshaller is the one failing to read
the entry.
The marshaller is taken from
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi which seems unaffected
by any configuration I could create...

POM file for the project:

pom.xml   
- 



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Failure-to-deserialize-simple-model-object-tp15440p15458.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.