[GitHub] ignite pull request: IGNITE-2050 - Remove duplicates from the conf...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/291


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (IGNITE-2102) .NET: Simplify query examples

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-2102:
---

 Summary: .NET: Simplify query examples
 Key: IGNITE-2102
 URL: https://issues.apache.org/jira/browse/IGNITE-2102
 Project: Ignite
  Issue Type: Task
  Components: interop
Affects Versions: ignite-1.4
Reporter: Vladimir Ozerov
 Fix For: 1.6


Simply move IGNITE-2097 to .NET once it is ready.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-2103) CPP: Simplify query examples.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-2103:
---

 Summary: CPP: Simplify query examples.
 Key: IGNITE-2103
 URL: https://issues.apache.org/jira/browse/IGNITE-2103
 Project: Ignite
  Issue Type: Task
  Components: interop
Affects Versions: ignite-1.4
Reporter: Vladimir Ozerov
 Fix For: 1.6


Simply move IGNITE-2097 to .NET once it is ready.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-2101) NPE when trying to submit Hadoop job to a node where Hadoop module is not loaded.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-2101:
---

 Summary: NPE when trying to submit Hadoop job to a node where 
Hadoop module is not loaded.
 Key: IGNITE-2101
 URL: https://issues.apache.org/jira/browse/IGNITE-2101
 Project: Ignite
  Issue Type: Bug
  Components: hadoop
Affects Versions: ignite-1.4
Reporter: Vladimir Ozerov
 Fix For: 1.6


See 
http://apache-ignite-users.70518.x6.nabble.com/NPE-issue-with-trying-to-submit-Hadoop-MapReduce-td2146.html

When Hadoop module is not loaded, HadoopNoopProcessor is started on the node. 
And it's method nextJobId() returns null. This null is then propagated to the 
client and NPE is raised. There is no way for users to underastand what is 
wrong.

Solution should be fairly simple: just throw an exception with sensible message 
from HadoopNoopProcessor.nextJobId() method. It should be propagated smoothly 
to the client. 
Also we need to add tests for this scenario.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] ignite pull request: IGNITE-2098 - Added test for java proxy.

[agoncharuk]

GitHub user agoncharuk opened a pull request:

https://github.com/apache/ignite/pull/301

IGNITE-2098 - Added test for java proxy.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/agoncharuk/ignite ignite-2098

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/301.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #301


commit c5dc062f201e0276ce5c93a0ebdcc3775831f83b
Author: Alexey Goncharuk 
Date:   2015-12-08T10:23:57Z

IGNITE-2098 - Added test for java proxy.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (IGNITE-2107) Splitting TX example and adding new

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-2107:
-

 Summary: Splitting TX example and adding new
 Key: IGNITE-2107
 URL: https://issues.apache.org/jira/browse/IGNITE-2107
 Project: Ignite
  Issue Type: Task
  Components: general
Affects Versions: ignite-1.4, 1.5
Reporter: Sergey Kozlov
Assignee: Yakov Zhdanov
 Fix For: 1.6


CacheQueryExample is overloaded by query features. What's about to introduce a 
new package e.g. called org.apache.ignite.examples.query and split 
org.apache.ignite.examples.datagrid.CacheQueryExample into separate examples 
like: 

QueryScanExample 
QueryJoinExample 
QueryTextExample 
QueryAggregationExample 
QueryFieldsExample 
QueryFieldsJoinExample 

And add new ones:

QueryCrossCacheExample 
QueryExplainExample 

upd YZ: I think this should be done in separate package 
{{org.apache.ignite.examples.datagrid.query}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] ignite pull request: IGNITE-1692 test suite

[ilantukh]

Github user ilantukh closed the pull request at:

https://github.com/apache/ignite/pull/300


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (IGNITE-2108) CacheJdbcPojoStoreFactory is not fully initialized when deserialized on a remote node

[Denis Magda (JIRA)]

Denis Magda created IGNITE-2108:
---

 Summary: CacheJdbcPojoStoreFactory is not fully initialized when 
deserialized on a remote node
 Key: IGNITE-2108
 URL: https://issues.apache.org/jira/browse/IGNITE-2108
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.5
Reporter: Denis Magda
Priority: Blocker
 Fix For: 1.5


When a cache is started dynamically and has an implementation of 
{{CacheJdbcPojoStoreFactory}} in its configuration then the cache startup 
procedure will fail on a remote node with the following exception:

{noformat}
[16:14:10,014][ERROR][exchange-worker-#49%null%][GridDhtPartitionsExchangeFuture]
 Failed to reinitialize local partitions (preloading will be stopped): 
GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=2, 
minorTopVer=1], nodeId=a7a1f89a, evt=DISCOVERY_CUSTOM_EVT]
class org.apache.ignite.IgniteCheckedException: Failed to start component: 
class org.apache.ignite.IgniteException: Failed to initialize cache store (data 
source is not provided).
at 
org.apache.ignite.internal.util.IgniteUtils.startLifecycleAware(IgniteUtils.java:8385)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCache(GridCacheProcessor.java:1251)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1620)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCachesStart(GridCacheProcessor.java:1545)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.startCaches(GridDhtPartitionsExchangeFuture.java:944)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:511)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1297)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:745)
Caused by: class org.apache.ignite.IgniteException: Failed to initialize cache 
store (data source is not provided).
at 
org.apache.ignite.cache.store.jdbc.CacheAbstractJdbcStore.start(CacheAbstractJdbcStore.java:297)
at 
org.apache.ignite.internal.util.IgniteUtils.startLifecycleAware(IgniteUtils.java:8381)
... 8 more
{noformat}

The reason is that in version 1.5 {{CacheJdbcPojoStoreFactory}} was reworked 
significantly and presently it has field {{private transient DataSource 
dataSrc}} that must be initiated somehow after deserialization.

The issue is easily to reproduce with schema-import example:
1) complete all the steps described in the demo tutorial
https://apacheignite.readme.io/docs/automatic-persistence#example

2) Start a remote node using {{DemoNode}}

3) Start {{Demo}}

4) The node started with {{DemoNode}} won't be able to start a cache because of 
the issue with the storage described above



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: NearCacheConfiguration extends MutableConfiguration

[Yakov Zhdanov]

These properties do not make sense for near cache. I doubt if this has been
done on purpose.
What if we extend Configuration? Will it break anything?

--Yakov

2015-12-08 6:06 GMT+03:00 Valentin Kulichenko :

> Folks,
>
> I just noticed that NearCacheConfiguration class extends JCache's
> MutableConfiguration. This means that it inherits properties like
> writeThrough, readThrough, etc., which doesn't look right to me.
>
> Was it done on purpose? Does anyone know the reason?
>
> -Val
>

[jira] [Created] (IGNITE-2104) Marshalling fails with Binary marshaller if class hierarchy contains duplicate field names

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-2104:


 Summary: Marshalling fails with Binary marshaller if class 
hierarchy contains duplicate field names
 Key: IGNITE-2104
 URL: https://issues.apache.org/jira/browse/IGNITE-2104
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.5
Reporter: Alexey Goncharuk
 Fix For: 1.5


Binary marshaller writes {{fieldId}} which is calculated solely on the field 
name. If a class hierarchy contains fields with the same name, marshalling will 
fail:

{code}
class ClassA{
private int field;
}

class ClassB extends ClassA {
private int field;
}
{code}

Even though a private field with the same name in parent and child classes is a 
error-prone approach, default serialization supports this.

Possible solutions:
 * Keep it as it is now and properly document. The issue appeared only in an 
artificial test. No other tests on TC revealed duplicate fields.
 * Write all serializable classes in old format. While this solution works 
perfectly for the marshalling, it will require objects to be deserialized on 
server nodes in order for indexing to work, which defeats the purpose of 
BinaryMarshaller
 * Inspect the class at runtime and use new format if no duplicate fields are 
detected, and print a warning message and switch to the old format otherwise.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-2106) BinaryMarshaller: near cache mustn't keep a copy on put() operation

[Anton Vinogradov (JIRA)]

Anton Vinogradov created IGNITE-2106:


 Summary: BinaryMarshaller: near cache mustn't keep a copy on put() 
operation
 Key: IGNITE-2106
 URL: https://issues.apache.org/jira/browse/IGNITE-2106
 Project: Ignite
  Issue Type: Bug
Reporter: Anton Vinogradov
Assignee: Anton Vinogradov
Priority: Blocker


Binary marshaller is an opensouced Gridgain Prortable marshaller,
So bug http://atlassian.gridgain.com/jira/browse/GG-10791 moved to Ignite jira.

There are several deployment related tests that fail when PortableMarshaller is 
used.
GridPortableCacheDeploymentSelftTest.testDeployment3()/testDeployemnt4();
GridPortableCacheDeploymentOffHeapSelfTest.testDeployment3()/testDeployemnt4();
The reason of the failure is that a near cache stores a copy of a cache entry 
when the cache.put() is being executed. No cache.get() was explicitly called 
during the test.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Binary marshaller issues

[Alexey Goncharuk]

Vova,

We still have the logic that allows us to use reflection to get values in
indexing, so basically the change is an additional check during the query
processor start.

My concern regarding (2) is that a server node must have model classes in
the classpath in order to check that we should deserialize values for
indexing. If a server node does not have classes in the classpath and user
still uses Externalizable classes on client, we will still end up with the
same situation and it looks like we will not be able to detect it. Is there
a way to tell that an object was externalizable without the class on server
node?

Re: More query examples

[Yakov Zhdanov]

I think the same is valid for TXs -
https://issues.apache.org/jira/browse/IGNITE-2107

Thanks!
--
Yakov Zhdanov, Director R
*GridGain Systems*
www.gridgain.com

2015-12-08 9:07 GMT+03:00 Sergey Kozlov :

> I filed https://issues.apache.org/jira/browse/IGNITE-2097
>
> On Tue, Dec 8, 2015 at 12:02 AM, Dmitriy Setrakyan 
> wrote:
>
> > I completely agree. We should make our SQL capabilities more prominent
> and
> > visible. Sergey, can you file a ticket for this outlining what changes
> need
> > to take place?
> >
> > D.
> >
> > On Mon, Dec 7, 2015 at 6:45 AM, Sergey Kozlov 
> > wrote:
> >
> > > Hi Igniters
> > >
> > > I think queries (SQL) is a killer feature of Ignite. But we still have
> > the
> > > example CacheQueryExample where query features provided. What's about
> to
> > > introduce a new package e.g. called org.apache.ignite.examples.query
> and
> > > split org.apache.ignite.examples.datagrid.CacheQueryExample into
> separate
> > > examples like
> > >
> > > CacheQueryExample
> > > CacheQueryJoinExample
> > > CacheQueryCrossCacheExample
> > > CacheQueryExplainExample
> > > etc
> > >
> > > From my standpoint it will be easier to maintain and extend in future.
> > For
> > > ignite user it's more clear where to find the a query functional
> example.
> > > --
> > > Sergey Kozlov
> > >
> >
>
>
>
> --
> Sergey Kozlov
>

[GitHub] ignite pull request: Ignite 2064 2

[avinogradovgg]

GitHub user avinogradovgg opened a pull request:

https://github.com/apache/ignite/pull/303

Ignite 2064 2



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/avinogradovgg/ignite ignite-2064-2

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/303.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #303


commit d5791837890a70e1777b86aab281245701afe1eb
Author: sboikov 
Date:   2015-12-08T09:42:25Z

ignite-1.5 Fixed hang on client reconnect (should not do blocking calls 
from reconnect callback)

commit 5cd0039a535b4c2ea7434d4b085c9e18f28c930d
Author: sboikov 
Date:   2015-12-08T10:12:24Z

ignite-1692 Changed test initialization logic to remove race confition that 
caused ClusterTopologyServerNotFoundException

commit 322a85a359e0fc2c56f5c3aa38fc48a92e553289
Author: S.Vladykin 
Date:   2015-12-08T10:17:36Z

ignite-1.5 - MessageCollection + marshalling issue test

commit c292748013acfcbf6b3752183a34bb26de16c1f4
Author: S.Vladykin 
Date:   2015-12-08T10:18:30Z

Merge remote-tracking branch 'origin/ignite-1.5' into ignite-1.5

commit 67ebd02c9a58ef2d835e55e4aa6efdcec6d53b8c
Author: Alexey Goncharuk 
Date:   2015-12-08T12:09:10Z

Ignite-1.5 - Added missing serialVersionUID to fix the build.

commit 8ca163bd0f06cc832df126733dbbe50cea35c2ac
Author: Anton Vinogradov 
Date:   2015-12-08T12:46:10Z

IGNITE-2064 More test fixes

commit efe632b18e760f699bedee906050f66eabadb077
Author: Pavel Tupitsyn 
Date:   2015-12-08T12:59:23Z

IGNITE-2026: .NET: Fixed stack overflow caused by incorrect unboxing of 
value types.

commit 3a340034056f5da0ca00ed88e128b59cc28381d2
Author: ashutak 
Date:   2015-12-08T13:02:36Z

Fixed race in IgniteTransactionalWriteInvokeBenchmark test.

commit 070d248c133c070ad333e914af2ca25cd9f09cdd
Author: Anton Vinogradov 
Date:   2015-12-08T13:39:36Z

IGNITE-2064 Fixed Usage of Optimize classloader




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request: 2064 Test hotfix

[avinogradovgg]

Github user avinogradovgg closed the pull request at:

https://github.com/apache/ignite/pull/297


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: EA versioning

[Sergi Vladykin]

Cos,

I think you are right, probably we have to release 1.5.0-b1 then stable
bug-fix versions will be 1.5.1, 1.5.2...
And then next release from master should be 1.6.0. Yes, this should work
and then we will not need
*final *qualifier.

Sergi


2015-12-07 7:23 GMT+03:00 Konstantin Boudnik :

> Oh, and not to say - JIRA would have to have a corresponding versions. Say
> right now I see only 1.5 in JIRA and it has 161 unresolved bugs. However,
> the
> -b1 release is already voted for and is almost official.
>
> Cos
>
> On Sun, Dec 06, 2015 at 03:11PM, Konstantin Boudnik wrote:
> > On Sun, Dec 06, 2015 at 11:30AM, Sergi Vladykin wrote:
> > > Cos and Brane,
> > >
> > > This issue arised not from our feeling of beautiful, but from practical
> > > reasons,
> > > namely we need to conform existing Maven and OSGi version models at the
> > > same time.
> > >
> > > We did not invent Maven or OSGi, but if we want to play with them well,
> > > we have to keep in mind their own quirks and bad design decisions,
> > > when choosing how our versions will look like.
> >
> > Very true. However, both Maven and OSGi are supporting normal semver
> schema,
> > so the argument doesn't apply ;)
> >
> > > Cos,
> > >
> > > JDK and Linux kernel are bad examples here exactly because
> > > they were free to choose any good or bad versioning they want,
> > > we are not that free.
> >
> > We are free to stick to simver and don't make convoluted choices, that
> will
> > confuse the hell out of the users. I am seen 1.5.0-b1 getting released
> and I
> > already have no idea if it is better than 1.5.0 or worst. If the latter -
> > where's 1.5.0 then?
> >
> > > Could you please clarify what exactly happened with HBase?
> > > And why do you think we will have the same problems?
> >
> > Hbase used to have 0.98.16.1-hadoop2 and 0.98.16.1-hadoop1 classifiers to
> > distinguish between different versions of HDFS base. Considering that
> maven
> > classifiers are designed to differentiate between _types_ of artifacts,
> not
> > the platforms, hooking up to the hbase artifacts from different
> dependency
> > management systems were a royal PITA.
> >
> > We'll have the same problem exactly because these are arbitrary choices
> and have
> > no similarities with anything else out there. The most effective
> engineering
> > principal is KISS: anything that goes against it will have a higher
> friction
> > with the users. Meaning more disoriented emails on the user@ list, more
> > frustration and incorrectly filed bug reports, reflecting in a lower
> > traction with future contributors.
> >
> > Cheers,
> >   Cos
> >
> > > 2015-12-06 4:24 GMT+03:00 Konstantin Boudnik :
> > >
> > > > On Tue, Dec 01, 2015 at 07:18PM, Raul Kripalani wrote:
> > > > > On Tue, Dec 1, 2015 at 7:15 PM, Dmitriy Setrakyan <
> dsetrak...@apache.org
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Raul, as an OSGI expert, do you confirm?
> > > > > >
> > > > >
> > > > > Yep, it was my proposal only to add "-final". Just to be clear,
> this is a
> > > > > Maven qualifier. The maven-bundle-plugin will translate the hyphen
> to a
> > > > > dot, for compatibility with OSGi.
> > > >
> > > > For the die-hard fans of "-lksfdiuye" classifiers in Maven
> artifacts, I'd
> > > > suggest to check how well it has played for HBase. Hadoop been there
> as
> > > > well -
> > > > they still are fighting the consequences of once thought to be a neat
> > > > "-alpha"
> > > > idea. Seriously guys, this is gonna be mess, confusing the hell out
> of
> > > > everybody.
> > > >
> > > > Cos
> > > >
> > > > > *Raúl Kripalani*
> > > > > PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big
> Data and
> > > > > Messaging Engineer
> > > > > http://about.me/raulkripalani |
> http://www.linkedin.com/in/raulkripalani
> > > > > http://blog.raulkr.net | twitter: @raulvk
> > > >
>
>
>

[jira] [Created] (IGNITE-2111) .Net: Create a build script

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-2111:
--

 Summary: .Net: Create a build script
 Key: IGNITE-2111
 URL: https://issues.apache.org/jira/browse/IGNITE-2111
 Project: Ignite
  Issue Type: Task
  Components: interop
Affects Versions: 1.1.4
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 1.5


* Create a build script (batch file) to easily produce x86/x64 binaries
* Add a Maven step to generate Doxygen documentation



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-2112) Provide a way to serialize/deserialize an IgniteConfiguration object using JSON

[Juan Velez (JIRA)]

Juan Velez created IGNITE-2112:
--

 Summary: Provide a way to serialize/deserialize an 
IgniteConfiguration object using JSON
 Key: IGNITE-2112
 URL: https://issues.apache.org/jira/browse/IGNITE-2112
 Project: Ignite
  Issue Type: Improvement
  Components: general
Affects Versions: ignite-1.4
Reporter: Juan Velez
Priority: Minor


Currently as of Release 1.4, Ignite does not provide a way to 
serialize/deserialize an IgniteConfiguration object using JSON. Attempts to 
create a working serializer/deserializer are met with very difficult setup and 
configuration because the IgniteConfiguration (and subcomponents) rely on 
Factories, SPIs, etc for properties. as well as not being completely compliant 
with the JavaBeans standard.

It would be great if the serialization/deserialization using JSON could be 
provided as either a new method in an existing/new Util class or part of the 
IgniteConfiguration class itself.

I understand that in the case of deserialization most likely there would be 
constraints on how to correctly specify the JSON string but that would be left 
for implementors of the feature to correctly decide/design/document.

See user@ thread 
http://apache-ignite-users.70518.x6.nabble.com/How-to-serialize-deserialize-IgniteConfiguration-to-from-JSON-td2164.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Handling collections in BinaryMarshaller

[Alexey Goncharuk]

I like the idea, however it has obvious downsides. First, if a user class
contains a collection, we force user to implement additional interface,
even if the collection is a simple ArrayList. Second, I do not see how this
plain collection can be the value for the cache - user will always need to
write a wrapper/containing class around it.

I think we should provide minimum support for basic types - HashMap,
LinkedHashMap, ArrayList and treat other classes the way Vladimir described.

[jira] [Created] (IGNITE-2113) Yardstick scripts don't work under Solaris (SunOS)

[Andrey Gura (JIRA)]

Andrey Gura created IGNITE-2113:
---

 Summary: Yardstick scripts don't work under Solaris (SunOS)
 Key: IGNITE-2113
 URL: https://issues.apache.org/jira/browse/IGNITE-2113
 Project: Ignite
  Issue Type: Bug
Reporter: Andrey Gura


Yardstick scripts don't work under Solaris (SunOS). The problem in shell 
commands like {{pgrep}} that work a little different than under Linux.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: What is jdbc:ignite:cfg ??

[Andrey Gura]

Done. I hope that is more clear now.

On Tue, Dec 8, 2015 at 1:14 AM, Dmitriy Setrakyan 
wrote:

> On Mon, Dec 7, 2015 at 10:17 AM, Andrey Gura  wrote:
>
> > Cos,
> >
> >  sepcifies configuration file for Ignite client node that
> will
> > be started during connection establishing by JDBC driver. So this file
> > should be available for JDBC driver client.
> >
>
> Andrey, should this be documented here?
> https://apacheignite.readme.io/docs/jdbc-driver
>
> D.
>
>
> >
> > On Mon, Dec 7, 2015 at 8:59 PM, Konstantin Boudnik 
> wrote:
> >
> > > Thanks Andrey!
> > >
> > > Still a bit unclear: the doc says
> > > " is required and represents any valid URL which points to
> > > Ignite configuration file"
> > >
> > > So, that's server side URL then, something like
> > > jdbc:ignite:cfg:///etc/ignite/conf/default-config.xml
> > >
> > > assuming that server nodes have said configuration under
> > > /etc/ignite/conf/default-config.xml ? Sorry, it's either I am a bit
> > dense,
> > > or
> > > the doc isn't written to a layman
> > >
> > > Thanks in advance!
> > >   Cos
> > >
> > > On Mon, Dec 07, 2015 at 01:03PM, Andrey Gura wrote:
> > > > Cos,
> > > >
> > > > JDBC driver was reworked in order to use Ignite client node instead
> of
> > > > Ignite Java client. It gives better performance. So now JDBC dirver
> > uses
> > > > Ignite xml configuration file using jdbc:ignite:cfg protocol. See
> > > > documentation for version 1.4
> > > > https://apacheignite.readme.io/v1.4/docs/jdbc-driver
> > > >
> > > > At the same time we still support old version of JDBC driver that
> uses
> > > > jdbc:ignite protocol. See documentation for version 1.3
> > > > https://apacheignite.readme.io/v1.3/docs/jdbc-driver
> > > >
> > > > Thus you can control used JDBC driver type (new or old) just with
> > choosen
> > > > protocol.
> > > >
> > > > Please, note, that old JDBC driver is deprecated and can be removed
> > from
> > > > future releases.
> > > >
> > > > On Mon, Dec 7, 2015 at 6:41 AM, Konstantin Boudnik 
> > > wrote:
> > > >
> > > > > Guys, I am looking into [1] and see a reference to
> > > > >
> > > > > ignite.jdbc.url = "jdbc:ignite:cfg://"
> > > > >
> > > > > So, I am curious if there's a way to fetch node's config via JDBC
> > > somehow?
> > > > > Or
> > > > > this is just a simple error in the doc, which needs to be fixed?
> > > > >
> > > > > Would appreciate the insight from the team. Thanks!
> > > > >   Cos
> > > > >
> > > > > [1]
> > > > >
> > >
> >
> https://zeppelin.incubator.apache.org/docs/0.5.5-incubating/interpreter/ignite.html
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Andrey Gura
> > > > GridGain Systems, Inc.
> > > > www.gridgain.com
> > >
> >
> >
> >
> > --
> > Andrey Gura
> > GridGain Systems, Inc.
> > www.gridgain.com
> >
>



-- 
Andrey Gura
GridGain Systems, Inc.
www.gridgain.com

Re: Handling collections in BinaryMarshaller

[Dmitriy Setrakyan]

Vladimir,

I believe the default collections in Java and .NET should be supported out
of the box. Moreover, if we know the collection type, e.g. HashMap, we can
always provide a more efficient way of serializing it ourselves, in the
Binary marshaller.

Is this something you had in mind, or were you proposing something
different.

D.

On Tue, Dec 8, 2015 at 6:29 AM, Vladimir Ozerov 
wrote:

> Alex,
>
> What interface do you mean? If user has collection field in class and
> explicitly call BinaryWriter.writeCollection(), we can leave current
> interoperability support - it is not a problem.
> As per your second point - user could pass collections e.g. as argument to
> Java task started from .NET. This is where we will loose interoperabiltiy
> and will force user to create some wrappers. But these are very specific
> use cases.
>
> BTW, proposed solution is almost exactly how we work with collections in
> .NET.
>
> On Tue, Dec 8, 2015 at 4:57 PM, Alexey Goncharuk <
> alexey.goncha...@gmail.com
> > wrote:
>
> > I like the idea, however it has obvious downsides. First, if a user class
> > contains a collection, we force user to implement additional interface,
> > even if the collection is a simple ArrayList. Second, I do not see how
> this
> > plain collection can be the value for the cache - user will always need
> to
> > write a wrapper/containing class around it.
> >
> > I think we should provide minimum support for basic types - HashMap,
> > LinkedHashMap, ArrayList and treat other classes the way Vladimir
> > described.
> >
>

Re: Binary marshaller issues

[Dmitriy Setrakyan]

My preference would be to deserialize and grab the fields using reflection,
assuming the class is available on the server. If the class is not
available, then a corresponding field-access operation should produce an
exception with a proper error message, instructing user how to address it.

There is no need to punish users with some idealistic unsupported
exceptions if the classes are available on the server side.

D.

On Tue, Dec 8, 2015 at 4:16 AM, Vladimir Ozerov 
wrote:

> Alex,
>
> I was wrong about OptimizedMarshaller. We handle Externalizable a bit
> differently: we immediately swtich to "raw mode" and write object's content
> in raw form. This situation can be detected using several flags in object
> header. But the same flags will be set if user implemented Binarizable and
> manually switched object to raw mode. So the answer is no - we cannot
> detected this situation reliably at the moment.
>
> May be some new flag could help us. It could mean "cannot read fields from
> deserialized object".
>
> On Tue, Dec 8, 2015 at 3:03 PM, Alexey Goncharuk <
> alexey.goncha...@gmail.com
> > wrote:
>
> > Vova,
> >
> > We still have the logic that allows us to use reflection to get values in
> > indexing, so basically the change is an additional check during the query
> > processor start.
> >
> > My concern regarding (2) is that a server node must have model classes in
> > the classpath in order to check that we should deserialize values for
> > indexing. If a server node does not have classes in the classpath and
> user
> > still uses Externalizable classes on client, we will still end up with
> the
> > same situation and it looks like we will not be able to detect it. Is
> there
> > a way to tell that an object was externalizable without the class on
> server
> > node?
> >
>

Re: What is jdbc:ignite:cfg ??

[Dmitriy Setrakyan]

Thanks Andrey!

In my view, we should also provide a sample XML configuration file,
especially given that we refer to it in the sample URL.

D.

On Tue, Dec 8, 2015 at 10:17 AM, Andrey Gura  wrote:

> Done. I hope that is more clear now.
>
> On Tue, Dec 8, 2015 at 1:14 AM, Dmitriy Setrakyan 
> wrote:
>
> > On Mon, Dec 7, 2015 at 10:17 AM, Andrey Gura  wrote:
> >
> > > Cos,
> > >
> > >  sepcifies configuration file for Ignite client node that
> > will
> > > be started during connection establishing by JDBC driver. So this file
> > > should be available for JDBC driver client.
> > >
> >
> > Andrey, should this be documented here?
> > https://apacheignite.readme.io/docs/jdbc-driver
> >
> > D.
> >
> >
> > >
> > > On Mon, Dec 7, 2015 at 8:59 PM, Konstantin Boudnik 
> > wrote:
> > >
> > > > Thanks Andrey!
> > > >
> > > > Still a bit unclear: the doc says
> > > > " is required and represents any valid URL which points
> to
> > > > Ignite configuration file"
> > > >
> > > > So, that's server side URL then, something like
> > > > jdbc:ignite:cfg:///etc/ignite/conf/default-config.xml
> > > >
> > > > assuming that server nodes have said configuration under
> > > > /etc/ignite/conf/default-config.xml ? Sorry, it's either I am a bit
> > > dense,
> > > > or
> > > > the doc isn't written to a layman
> > > >
> > > > Thanks in advance!
> > > >   Cos
> > > >
> > > > On Mon, Dec 07, 2015 at 01:03PM, Andrey Gura wrote:
> > > > > Cos,
> > > > >
> > > > > JDBC driver was reworked in order to use Ignite client node instead
> > of
> > > > > Ignite Java client. It gives better performance. So now JDBC dirver
> > > uses
> > > > > Ignite xml configuration file using jdbc:ignite:cfg protocol. See
> > > > > documentation for version 1.4
> > > > > https://apacheignite.readme.io/v1.4/docs/jdbc-driver
> > > > >
> > > > > At the same time we still support old version of JDBC driver that
> > uses
> > > > > jdbc:ignite protocol. See documentation for version 1.3
> > > > > https://apacheignite.readme.io/v1.3/docs/jdbc-driver
> > > > >
> > > > > Thus you can control used JDBC driver type (new or old) just with
> > > choosen
> > > > > protocol.
> > > > >
> > > > > Please, note, that old JDBC driver is deprecated and can be removed
> > > from
> > > > > future releases.
> > > > >
> > > > > On Mon, Dec 7, 2015 at 6:41 AM, Konstantin Boudnik  >
> > > > wrote:
> > > > >
> > > > > > Guys, I am looking into [1] and see a reference to
> > > > > >
> > > > > > ignite.jdbc.url = "jdbc:ignite:cfg://"
> > > > > >
> > > > > > So, I am curious if there's a way to fetch node's config via JDBC
> > > > somehow?
> > > > > > Or
> > > > > > this is just a simple error in the doc, which needs to be fixed?
> > > > > >
> > > > > > Would appreciate the insight from the team. Thanks!
> > > > > >   Cos
> > > > > >
> > > > > > [1]
> > > > > >
> > > >
> > >
> >
> https://zeppelin.incubator.apache.org/docs/0.5.5-incubating/interpreter/ignite.html
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Andrey Gura
> > > > > GridGain Systems, Inc.
> > > > > www.gridgain.com
> > > >
> > >
> > >
> > >
> > > --
> > > Andrey Gura
> > > GridGain Systems, Inc.
> > > www.gridgain.com
> > >
> >
>
>
>
> --
> Andrey Gura
> GridGain Systems, Inc.
> www.gridgain.com
>

Re: NearCacheConfiguration extends MutableConfiguration

[Dmitriy Setrakyan]

Are there any other properties from MutableConfiguration that
NearCacheConfiguration requires?

On Tue, Dec 8, 2015 at 3:47 AM, Yakov Zhdanov  wrote:

> These properties do not make sense for near cache. I doubt if this has been
> done on purpose.
> What if we extend Configuration? Will it break anything?
>
> --Yakov
>
> 2015-12-08 6:06 GMT+03:00 Valentin Kulichenko <
> valentin.kuliche...@gmail.com
> >:
>
> > Folks,
> >
> > I just noticed that NearCacheConfiguration class extends JCache's
> > MutableConfiguration. This means that it inherits properties like
> > writeThrough, readThrough, etc., which doesn't look right to me.
> >
> > Was it done on purpose? Does anyone know the reason?
> >
> > -Val
> >
>

Re: Is there any plan to build an ignite web console ?

[Dmitriy Setrakyan]

There are a couple more of 3rd party management consoles.

ApacheIgniteExtensions - provides basic management functionality and
ability to manually use Ignite REST API from a UI console:
https://github.com/sumeet70/aiex

GridGain Visor - a UI management tool with comprehensive management and
monitoring features:
https://gridgain.readme.io/docs/visor-management-console

D.

On Mon, Dec 7, 2015 at 6:36 PM, Alexey Kuznetsov 
wrote:

> Ken, we already working on it.
> See: https://issues.apache.org/jira/browse/IGNITE-843
>
> Sources will be released in ignite-1.6
>
> Also we have beta-version with hosting sponsored by GridGain:
> console.gridgain.com
>
>
> On Tue, Dec 8, 2015 at 9:11 AM, Ken Cheng  wrote:
>
> > Is there any plan to build an ignite web console? The similar web
> > application as hazcalst.
> >
> >
> >
> >
> > Thanks,
> > kcheng
> >
>
>
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>

Idiomatic way of configuring caches on client

[Alexey Kuznetsov]

I'm working on Ignite Web Console.
And this utility is generating XML and java code with cluster configuration.

For server-side I generate XML and java code that describe caches.

But should I do the same when generating client node configuration?

I think that I should only generate NearCacheConfiguration in case
of client node
and do not generate CacheConfiguration in XML and java.

Also, it is a good idea to generate NearCacheConfiguration for each cache
by default?
Or better to give a choice of caches?


Thoughts?

-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

[jira] [Created] (IGNITE-2114) implemented ability to download configuration as independent logic

[Dmitriyff (JIRA)]

Dmitriyff created IGNITE-2114:
-

 Summary: implemented ability to download configuration as 
independent logic
 Key: IGNITE-2114
 URL: https://issues.apache.org/jira/browse/IGNITE-2114
 Project: Ignite
  Issue Type: Sub-task
Reporter: Dmitriyff
Assignee: Dmitriyff






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)