get the all values stored into cache name?

[Ravi]

Ignite cachedata=ignite.getOrCreateCache(cacheName)

entered the data into cachedata.put()


how to get all data using cacheName from cachedata??



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/get-the-all-values-stored-into-cache-name-tp2631.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Would this be crazy?

[Dmitriy Setrakyan]

On Mon, Jan 18, 2016 at 3:45 AM, nino martinez wael <
nino.martinez.w...@gmail.com> wrote:

> Hi
>
> We are considering using Ignite as a backend for our client / server
> environment (for Ignites key/value store). IT's a telephony based
> system, and the idea are that as a telephony CALL passes through the
> system Ignite nodes will follow the call adding and manipulating data.
> Each call would have it's own node cluster (as we don't need to share
> data between calls). There could be a lot of concurrent calls, max
> would probably be around 1000.
>
> So the question are how does Ignite handle
> * Cluster size of up to 1000 concurrent clusters (all based on a predicate)
>

Most likely you mean 1000 nodes. Ignite has been known to be deployed in
1000+ node clusters. However, it sounds like you are trying to achieve data
isolation, so you may need to start up a cache per call, not a node per
call.

As Alexey suggested, once you describe your use case better, we will be
able to provide better suggestions.


> * A cluster where nodes will come and go and probably are error-prone
>

Ignite nodes can join and leave as needed. However, you should avoid
frequent topology changes, because likely there will be a background
rebalancing triggered every time a node joins or leaves.


> * Realtime, it would be a problem if one node dies and the others have
> to wait for confirmation of death etc
>

This generally does not happen in Ignite. Topology changes generally have
little effect on performance, as all the recovery and rebalancing happens
in the background and cluster continues to operate.


> * OSGI, any issues?
>

Ignite 1.5 added OSGI support. Not sure which issues you are concerned
with, but here are links to the documentation:

https://apacheignite.readme.io/docs/osgi-installation-in-karaf
https://apacheignite.readme.io/docs/osgi-supported-modules
https://apacheignite.readme.io/docs/osgi-starting-inside-a-container


>
> Please ask if I need to rephrase some of my questions
>
> --
> Best regards / Med venlig hilsen
> Nino Martinez
>

Re: TcpDiscoverySpi.setLocalPortRange, value must be > 0

[Dmitriy Setrakyan]

I think it is not a bad change. How about we open a ticket and mark it as
“newbie”, so new community members could get started with it.

On Mon, Jan 18, 2016 at 4:52 AM, Denis Magda  wrote:

> Hi,
>
> Thank for pointing out to this issue. Local port range set to 0 presently
> doesn't work at least for TcpCommunicationSpi and TcpDiscoverySpi. However
> SPIs support it.
>
> In my understanding the condition has to changed to the following one
> (from < to <=).
>
> x = port; x *<=* port + range
>
> But this will violate the following from
> TcpCommunicationSpi.setLocalPortRange
>
> implementation will try to increment the port number for as long as it is 
> less than* initial value plus this range.
>
>
> So it means that setLocalPortRange has to be treated a different way and
> in fact setLocalPortRange=0 will be the same as setLocalPortRange=1
>
> I've copied the message to @dev list to get more thoughts on this.
>
> Igniters, any thoughts? Should localPortRange=0 work the same as
> localPortRange=1?
>
> --
> Denis
>
>
> On 1/18/2016 12:21 PM, DLopez wrote:
>
> Hi,
>
> While experimenting, as I was trying to just allow specific ports, I set the
> LocalPortRange of my configurations to 0. The result was not what I expected
> as you end up getting a NPE when starting the cluster. I traced the issue in
> the source and the cause is that when opening ports, the routine goes from
> the x = port; x < port + range. So you end up with no server socket, and
> when you try to listen to it, kaboum.
>
> So I think it might be interesting to clarify the docs, as the current
> definition (starting from getLocalPort() up until getLocalPort() +
> locPortRange) can be misunderstood and the handling of localport value,
> throwing an error if it is set to an incorrect value.
>
> Just to prevent other people having the same issue :). Not a top priority,
> of course, but such an easy change can prevent more support messages to the
> list to... What do you think?
>
> S!
> D.
>
>
>
> --
> View this message in context: 
> http://apache-ignite-users.70518.x6.nabble.com/TcpDiscoverySpi-setLocalPortRange-value-must-be-0-tp2606.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>
>
>

Re: issue with 2-node ignite server cluster

[Ambha]

This is the error it displays

**
class org.apache.ignite.IgniteCheckedException: Failed to send message (node
may have left the grid or TCP connection cannot be established due to
firewall issues) [node=TcpDiscoveryNode
[id=4b13c224-21be-4c32-b29d-a0d7d079df10, addrs=[0:0:0:0:0:0:0:1%lo,
127.0.0.1, 192.168.186.247], sockAddrs=[/192.168.186.247:47500,
/0:0:0:0:0:0:0:1%lo:47500, /127.0.0.1:47500, /192.168.186.247:47500],
discPort=47500, order=1, intOrder=1, lastExchangeTime=1453209329890,
loc=false, ver=1.4.0#20150924-sha1:c2def5f6, isClient=false],
topic=TOPIC_CACHE, msg=GridDhtPartitionsSingleMessage
[parts={-2100569601=GridDhtPartitionMap
[nodeId=3955b599-e49c-43f3-ad07-752b349db1ac, updateSeq=122, moving=0,
size=100], 689859866=GridDhtPartitionMap
[nodeId=3955b599-e49c-43f3-ad07-752b349db1ac, updateSeq=534, moving=0,
size=512], 1325947219=GridDhtPartitionMap
[nodeId=3955b599-e49c-43f3-ad07-752b349db1ac, updateSeq=42, moving=0,
size=20], 2034899268=GridDhtPartitionMap
[nodeId=3955b599-e49c-43f3-ad07-752b349db1ac, updateSeq=534, moving=0,
size=512], -1559869495=GridDhtPartitionMap
[nodeId=3955b599-e49c-43f3-ad07-752b349db1ac, updateSeq=534, moving=0,
size=512]}, client=false, super=GridDhtPartitionsAbstractMessage
[exchId=null, lastVer=GridCacheVersion [topVer=0, nodeOrderDrId=0,
globalTime=0, order=1453209329443], super=GridCacheMessage [msgId=26,
depInfo=null, err=null, skipPrepare=false]]], policy=2]
at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1071)
at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1214)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.sendNoRetry(GridCacheIoManager.java:873)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.sendLocalPartitions(GridCachePartitionExchangeManager.java:760)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.refreshPartitions(GridCachePartitionExchangeManager.java:671)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.refreshPartitions(GridCachePartitionExchangeManager.java:690)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1800(GridCachePartitionExchangeManager.java:95)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1152)
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.spi.IgniteSpiException: Failed to send
message to remote node: TcpDiscoveryNode
[id=4b13c224-21be-4c32-b29d-a0d7d079df10, addrs=[0:0:0:0:0:0:0:1%lo,
127.0.0.1, 192.168.186.247], sockAddrs=[/192.168.186.247:47500,
/0:0:0:0:0:0:0:1%lo:47500, /127.0.0.1:47500, /192.168.186.247:47500],
discPort=47500, order=1, intOrder=1, lastExchangeTime=1453209329890,
loc=false, ver=1.4.0#20150924-sha1:c2def5f6, isClient=false]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:1940)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:1880)
at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1066)
... 9 more
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to connect
to node (is node still alive?). Make sure that each GridComputeTask and
GridCacheTransaction has a timeout set in order to prevent parties from
waiting forever in case of network issues
[nodeId=4b13c224-21be-4c32-b29d-a0d7d079df10, addrs=[/192.168.186.247:47100,
/0:0:0:0:0:0:0:1%lo:47100, /127.0.0.1:47100]]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2421)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2074)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:1978)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:1914)
... 11 more
Suppressed: class org.apache.ignite.IgniteCheckedException: Failed
to connect to address: /192.168.186.247:47100
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2426)
... 14 more
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
read remote node recovery handshake (connection closed).
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.safeHandshake(TcpCommunicationSpi.java:2634)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2293)
.

Re: get the all values stored into cache name?

[Alexey Goncharuk]

Ravi,

IgniteCache does not have a method like getAll() because this can simply
trigger an OOME on the node that receiving the data.

If you want to process all entries on a single node, you can use
IgniteCache#query() method and pass an instance of ScanQuery object to this
method. Resulting cursor will allow you to iterate over cache entries. You
can refer to [1] for more details.

Note that, generally, such an approach is not very efficient because you
are sending a lot of data across the network. You may want to exploit
Ignite compute functionality and collocate your computations with data. In
this case only small objects responsible for the computations and
computation results will be sent across the network. The approach is
described in [2]

Hope this helps,
AG
--
[1] https://apacheignite.readme.io/docs/cache-queries
[2] https://apacheignite.readme.io/docs/collocate-compute-and-data

Re: TcpDiscoverySpi.setLocalPortRange, value must be > 0

[Denis Magda]

Ticket is ready for a contribution :)
https://issues.apache.org/jira/browse/IGNITE-2404

If anyone has any thoughts then feel free to put them there or pick the 
ticket up and fix.


--
Denis

On 1/19/2016 11:45 AM, Dmitriy Setrakyan wrote:
I think it is not a bad change. How about we open a ticket and mark it 
as “newbie”, so new community members could get started with it.


On Mon, Jan 18, 2016 at 4:52 AM, Denis Magda > wrote:


Hi,

Thank for pointing out to this issue. Local port range set to 0
presently doesn't work at least for TcpCommunicationSpi and
TcpDiscoverySpi. However SPIs support it.

In my understanding the condition has to changed to the following
one (from < to <=).

x = port; x*<=*  port + range

But this will violate the following from
TcpCommunicationSpi.setLocalPortRange

implementation will try to increment the port number for as long
as it is less than * initial value plus this range.

So it means that setLocalPortRange has to be treated a different
way and in fact setLocalPortRange=0 will be the same as
setLocalPortRange=1

I've copied the message to @dev list to get more thoughts on this.

Igniters, any thoughts? Should localPortRange=0 work the same as
localPortRange=1?

--
Denis


On 1/18/2016 12:21 PM, DLopez wrote:

Hi,

While experimenting, as I was trying to just allow specific ports, I set the
LocalPortRange of my configurations to 0. The result was not what I expected
as you end up getting a NPE when starting the cluster. I traced the issue in
the source and the cause is that when opening ports, the routine goes from
the x = port; x < port + range. So you end up with no server socket, and
when you try to listen to it, kaboum.

So I think it might be interesting to clarify the docs, as the current
definition (starting from getLocalPort() up until getLocalPort() +
locPortRange) can be misunderstood and the handling of localport value,
throwing an error if it is set to an incorrect value.

Just to prevent other people having the same issue :). Not a top priority,
of course, but such an easy change can prevent more support messages to the
list to... What do you think?

S!
D.



--
View this message in 
context:http://apache-ignite-users.70518.x6.nabble.com/TcpDiscoverySpi-setLocalPortRange-value-must-be-0-tp2606.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: TcpDiscoveryVmIpFinder's isShared property

[Yakov Zhdanov]

Val, you can init your S3 bucket and set "shared" to false and IP finder
will be immutable. Can it be a valid usecase? If none is going to use it
this way, I agree let's change this. Btw, would it be better to deprecate
"shared" and introduce "mutable"?

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

2016-01-19 3:52 GMT+03:00 Valentin Kulichenko :

> Yakov,
>
> JavaDoc is OK, but it seems to me that the confusion is caused by the fact
> that setShared() method is placed on the IpFinderAdapter, while it actually
> makes sense only for VmIpFinder. Can we deprecate it and always return
> false from isShared() method for JDBC, S3 and others?
>
> -Val
>
> On Mon, Jan 18, 2016 at 1:56 AM, Yakov Zhdanov 
> wrote:
>
>> Val, can you please review my changes to javadoc in master and update if
>> necessary?
>>
>> --Yakov
>>
>> 2016-01-15 23:13 GMT+03:00 Andrey Kornev :
>>
>>> It does now! Thank you!
>>>
>>> Andrey
>>>
>>> --
>>> Date: Fri, 15 Jan 2016 12:10:15 -0800
>>> Subject: Re: TcpDiscoveryVmIpFinder's isShared property
>>> From: valentin.kuliche...@gmail.com
>>> To: user@ignite.apache.org
>>>
>>>
>>> Andrey,
>>>
>>> Setting shared=true for TcpDiscoveryVmIpFinder means that nodes can
>>> discover each other only within one JVM, when all nodes use the same
>>> instance of IP finder. The shared "storage" in this case is just a local
>>> collection. We use this heavily in unit tests, for example.
>>>
>>> TcpDiscoveryVmIpFinder with shared=false is how it's usually used. There
>>> is no shared storage, so addresses have to be statically provided in the
>>> configuration.
>>>
>>> shared=false for any other IP finder doesn't make any sense, because
>>> they use some kind of storage by definition (e.g., JDBC or S3). This should
>>> be clarified in docs.
>>>
>>> Makes sense?
>>>
>>> -Val
>>>
>>> On Fri, Jan 15, 2016 at 9:16 AM, Andrey Kornev >> > wrote:
>>>
>>> Yakov,
>>>
>>> Thank you for the clarification, but I must admit I'm still not
>>> completely out of the woods with respect to intended usage. Setting the
>>> property to "false" seems to be most natural and only reasonable option,
>>> and I wonder when would one want to set it to true? I must be missing
>>> something.
>>>
>>> Also, just to clarify. In the last sentence you're saying: "This way
>>> user doesn't have to list any IPs before start..." How would then the new
>>> nodes know where to look for a node to connect to? They need to get the
>>> list of seed nodes from somewhere, right? If so, then setting isShared to
>>> true doesn't really make much difference - an initial list of seeds still
>>> must be provided to every node.
>>>
>>> Thanks
>>> Andrey
>>>
>>> --
>>> Date: Thu, 14 Jan 2016 12:55:52 +0300
>>> Subject: Re: TcpDiscoveryVmIpFinder's isShared property
>>> From: yzhda...@apache.org
>>> To: user@ignite.apache.org
>>>
>>>
>>> Guys, this property is supported in VM IP finder for simplifying
>>> discovery in single VM. I agree, that name could be better, but I would not
>>> mess with it for now and just fix the javadocs (pls review, I did that in
>>> master).
>>>
>>> "isShared" is a property of any IP finder. If it is "true" then IP
>>> finder allows to add and remove addresses in runtime and this is how, for
>>> example, S3 IP finder works. If "isShared" is "false" then IP finder is
>>> immutable and all the addresses should be listed in configuration. This is
>>> the most use case for VM IP finder. Since, usually VM IP finder is created
>>> per each Ignite instance and all the known IPs are listed right away, but
>>> there is also an option to make it shared - set "isShared" to true and
>>> literally share it between local VM Ignite instances. This way user does
>>> not have to list any IPs before start, instead all starting nodes add their
>>> addresses to the finder, then get the registered addresses and continue
>>> with discovery procedure.
>>>
>>> --Yakov
>>>
>>> 2016-01-13 22:45 GMT+03:00 Dmitriy Setrakyan :
>>>
>>> Any chance we could get an explanation here, so we can update the docs?
>>> Yakov, I think you would know how this flag works.
>>>
>>> On Wed, Jan 13, 2016 at 11:40 AM, Vladimir Ozerov 
>>> wrote:
>>>
>>> +1 to the question. Very confusing property. At the very least JavaDocs
>>> should be reworked significantly.
>>>
>>> On Wed, Jan 13, 2016 at 8:32 PM, Andrey Kornev >> > wrote:
>>>
>>> Hi there,
>>>
>>> I'm a bit confused about the purpose and usage of this property. What is
>>> being shared with who? What are the consequences of setting the property to
>>> true or false? Under what circumstances would one want to set it to either
>>> true or false? Does one care at all?
>>>
>>> Thanks
>>> Andrey
>>>
>>>
>>>
>>>
>>>
>>>
>>
>

Re: Execution hangs at IgniteRDD.savePairs()

[Shane Kinsella]

Val,

That has worked. I haven’t frozen since. Cheers!

Shane



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

Re: get the all values stored into cache name?

[Andrey Gura]

Ravi,

if you still want to get all data despite Alexey recommendations then you
can just use iterator() method on cache instance. This equals to ScanQuery
creation.

On Tue, Jan 19, 2016 at 1:04 PM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:

> Ravi,
>
> IgniteCache does not have a method like getAll() because this can simply
> trigger an OOME on the node that receiving the data.
>
> If you want to process all entries on a single node, you can use
> IgniteCache#query() method and pass an instance of ScanQuery object to this
> method. Resulting cursor will allow you to iterate over cache entries. You
> can refer to [1] for more details.
>
> Note that, generally, such an approach is not very efficient because you
> are sending a lot of data across the network. You may want to exploit
> Ignite compute functionality and collocate your computations with data. In
> this case only small objects responsible for the computations and
> computation results will be sent across the network. The approach is
> described in [2]
>
> Hope this helps,
> AG
> --
> [1] https://apacheignite.readme.io/docs/cache-queries
> [2] https://apacheignite.readme.io/docs/collocate-compute-and-data
>
>


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

Grouping cache when loading data using CacheStore

[Ferry Syafei Sapei]

I have a CSV file with the following structure:

accountNumber,accountProperty1,accountProperty2,billNumber,billProperty1,billProperty2
100,property11,property12,100700,billProperty11,billProperty12
100,property11,property12,100700,billProperty21,billProperty22

I would like to import the file and fill in the cache with the following object 
structure:
class AccountInformation
int accountNumber
String accountProperty1
String accountProperty2
List bills

class Bill
int billNumber
String billProperty1
String billProperty2

I have tried using IgniteDataStreamer and StreamVisitor. Line by line will be 
read and added to the data stream. In the data streamer, I could check if the 
account information exists or not. If it exists, I just add the new bill to the 
existing account and replace the cache content for that account.

How can I achieve the same result using CacheStore? 

Re: Grouping cache when loading data using CacheStore

[Dmitriy Setrakyan]

The CacheStore implementation using JDBC is documented here:
https://apacheignite.readme.io/docs/data-loading

You can use this example to implement the same over CSV file.

D.

On Tue, Jan 19, 2016 at 7:02 AM, Ferry Syafei Sapei <
ferry.sa...@googlemail.com> wrote:

> I have a CSV file with the following structure:
>
>
> accountNumber,accountProperty1,accountProperty2,billNumber,billProperty1,billProperty2
> 100,property11,property12,100700,billProperty11,billProperty12
> 100,property11,property12,100700,billProperty21,billProperty22
>
> I would like to import the file and fill in the cache with the following
> object structure:
> class AccountInformation
> int accountNumber
> String accountProperty1
> String accountProperty2
> List bills
>
> class Bill
> int billNumber
> String billProperty1
> String billProperty2
>
> I have tried using IgniteDataStreamer and StreamVisitor. Line by line will
> be read and added to the data stream. In the data streamer, I could check
> if the account information exists or not. If it exists, I just add the new
> bill to the existing account and replace the cache content for that account.
>
> How can I achieve the same result using CacheStore?

UnsupportedOperationException on adding indexed types to a config object

[vinshar]

Hi,

Below code throws UnsupportedOperationException.


public static void main(String[] args) {
CacheConfiguration config = new
CacheConfiguration((CompleteConfiguration)new CacheConfiguration());
config.setIndexedTypes(Integer.class,String.class); 
}


trace:-
Exception in thread "main" java.lang.UnsupportedOperationException
at java.util.AbstractList.add(AbstractList.java:148)

I am not sure whats going on in the setter hence thought of asking here.

Regards,
Vinay



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/UnsupportedOperationException-on-adding-indexed-types-to-a-config-object-tp2642.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Serialization issue with Ignite 1.5 built from master (357d791)

[Dmitriy Setrakyan]

Paulo,

Any reason why you need a hot fix release? Looks like Alexey provided you
with a commit revision number you can build from. Should not be hard to
generate your own release jar.

D.

On Fri, Jan 15, 2016 at 1:24 AM, Paulo Pires  wrote:

> Thank you Alexey.
>
> Any ETA on a hotfix release?
>
> Cheers,
> Pires
>
> On Fri, Jan 15, 2016 at 7:37 AM, Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
>
>> Paulo,
>>
>> The issue has been fixed and the fix was merged to master. You should be
>> able to cherry-pick the commit 02dbcfd8ed2701a4f415c8871d0b8fd08bfa0583 and
>> build Ignite from sources with this fix.
>>
>>
>>
>
>
> --
> Cheers,
> Pires
>

Re: TcpDiscoveryVmIpFinder's isShared property

[Dmitriy Setrakyan]

Looks like this property is only for the local VM. How about we rename it
to isInProcess() or isLocalVm()?

On Tue, Jan 19, 2016 at 4:50 AM, Yakov Zhdanov 
wrote:

> Val, you can init your S3 bucket and set "shared" to false and IP finder
> will be immutable. Can it be a valid usecase? If none is going to use it
> this way, I agree let's change this. Btw, would it be better to deprecate
> "shared" and introduce "mutable"?
>
> Thanks!
> --
> Yakov Zhdanov, Director R&D
> *GridGain Systems*
> www.gridgain.com
>
> 2016-01-19 3:52 GMT+03:00 Valentin Kulichenko <
> valentin.kuliche...@gmail.com>:
>
>> Yakov,
>>
>> JavaDoc is OK, but it seems to me that the confusion is caused by the
>> fact that setShared() method is placed on the IpFinderAdapter, while it
>> actually makes sense only for VmIpFinder. Can we deprecate it and always
>> return false from isShared() method for JDBC, S3 and others?
>>
>> -Val
>>
>> On Mon, Jan 18, 2016 at 1:56 AM, Yakov Zhdanov 
>> wrote:
>>
>>> Val, can you please review my changes to javadoc in master and update if
>>> necessary?
>>>
>>> --Yakov
>>>
>>> 2016-01-15 23:13 GMT+03:00 Andrey Kornev :
>>>
 It does now! Thank you!

 Andrey

 --
 Date: Fri, 15 Jan 2016 12:10:15 -0800
 Subject: Re: TcpDiscoveryVmIpFinder's isShared property
 From: valentin.kuliche...@gmail.com
 To: user@ignite.apache.org


 Andrey,

 Setting shared=true for TcpDiscoveryVmIpFinder means that nodes can
 discover each other only within one JVM, when all nodes use the same
 instance of IP finder. The shared "storage" in this case is just a local
 collection. We use this heavily in unit tests, for example.

 TcpDiscoveryVmIpFinder with shared=false is how it's usually used.
 There is no shared storage, so addresses have to be statically provided in
 the configuration.

 shared=false for any other IP finder doesn't make any sense, because
 they use some kind of storage by definition (e.g., JDBC or S3). This should
 be clarified in docs.

 Makes sense?

 -Val

 On Fri, Jan 15, 2016 at 9:16 AM, Andrey Kornev <
 andrewkor...@hotmail.com> wrote:

 Yakov,

 Thank you for the clarification, but I must admit I'm still not
 completely out of the woods with respect to intended usage. Setting the
 property to "false" seems to be most natural and only reasonable option,
 and I wonder when would one want to set it to true? I must be missing
 something.

 Also, just to clarify. In the last sentence you're saying: "This way
 user doesn't have to list any IPs before start..." How would then the new
 nodes know where to look for a node to connect to? They need to get the
 list of seed nodes from somewhere, right? If so, then setting isShared to
 true doesn't really make much difference - an initial list of seeds still
 must be provided to every node.

 Thanks
 Andrey

 --
 Date: Thu, 14 Jan 2016 12:55:52 +0300
 Subject: Re: TcpDiscoveryVmIpFinder's isShared property
 From: yzhda...@apache.org
 To: user@ignite.apache.org


 Guys, this property is supported in VM IP finder for simplifying
 discovery in single VM. I agree, that name could be better, but I would not
 mess with it for now and just fix the javadocs (pls review, I did that in
 master).

 "isShared" is a property of any IP finder. If it is "true" then IP
 finder allows to add and remove addresses in runtime and this is how, for
 example, S3 IP finder works. If "isShared" is "false" then IP finder is
 immutable and all the addresses should be listed in configuration. This is
 the most use case for VM IP finder. Since, usually VM IP finder is created
 per each Ignite instance and all the known IPs are listed right away, but
 there is also an option to make it shared - set "isShared" to true and
 literally share it between local VM Ignite instances. This way user does
 not have to list any IPs before start, instead all starting nodes add their
 addresses to the finder, then get the registered addresses and continue
 with discovery procedure.

 --Yakov

 2016-01-13 22:45 GMT+03:00 Dmitriy Setrakyan :

 Any chance we could get an explanation here, so we can update the docs?
 Yakov, I think you would know how this flag works.

 On Wed, Jan 13, 2016 at 11:40 AM, Vladimir Ozerov >>> > wrote:

 +1 to the question. Very confusing property. At the very least JavaDocs
 should be reworked significantly.

 On Wed, Jan 13, 2016 at 8:32 PM, Andrey Kornev <
 andrewkor...@hotmail.com> wrote:

 Hi there,

 I'm a bit confused about the purpose and usage of this property. What
 is being shared with who? What are the consequences of setting the property
 to true 

Re: Grouping cache when loading data using CacheStore

[Alexey Kuznetsov]

Ferry,

I would like to propose following work around:
1) Import your CSV into H2 database, see:
http://www.h2database.com/html/tutorial.html#csv
2) Use Apache Ignite Schema Import Utility to generate POJO classes and
xml/java configuration,\
see https://apacheignite.readme.io/docs/automatic-persistence
3) Use CacheJdbcPojoStoreFactory / CacheJdbcPojoStore to load your data
into cache.

Will this work for you?


On Tue, Jan 19, 2016 at 10:02 PM, Ferry Syafei Sapei <
ferry.sa...@googlemail.com> wrote:

> I have a CSV file with the following structure:
>
>
> accountNumber,accountProperty1,accountProperty2,billNumber,billProperty1,billProperty2
> 100,property11,property12,100700,billProperty11,billProperty12
> 100,property11,property12,100700,billProperty21,billProperty22
>
> I would like to import the file and fill in the cache with the following
> object structure:
> class AccountInformation
> int accountNumber
> String accountProperty1
> String accountProperty2
> List bills
>
> class Bill
> int billNumber
> String billProperty1
> String billProperty2
>
> I have tried using IgniteDataStreamer and StreamVisitor. Line by line will
> be read and added to the data stream. In the data streamer, I could check
> if the account information exists or not. If it exists, I just add the new
> bill to the existing account and replace the cache content for that account.
>
> How can I achieve the same result using CacheStore?




-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

Re: TcpDiscoveryVmIpFinder's isShared property

[Yakov Zhdanov]

I quote this from my previous email:

you can init your S3 bucket and set "shared" to false and IP finder will be
immutable. Can it be a valid usecase? If none is going to use it this way,
I agree let's change this. Btw, would it be better to deprecate "shared"
and introduce "mutable"?

--Yakov

2016-01-20 5:56 GMT+03:00 Dmitriy Setrakyan :

> Looks like this property is only for the local VM. How about we rename it
> to isInProcess() or isLocalVm()?
>
> On Tue, Jan 19, 2016 at 4:50 AM, Yakov Zhdanov 
> wrote:
>
>> Val, you can init your S3 bucket and set "shared" to false and IP finder
>> will be immutable. Can it be a valid usecase? If none is going to use it
>> this way, I agree let's change this. Btw, would it be better to deprecate
>> "shared" and introduce "mutable"?
>>
>> Thanks!
>> --
>> Yakov Zhdanov, Director R&D
>> *GridGain Systems*
>> www.gridgain.com
>>
>> 2016-01-19 3:52 GMT+03:00 Valentin Kulichenko <
>> valentin.kuliche...@gmail.com>:
>>
>>> Yakov,
>>>
>>> JavaDoc is OK, but it seems to me that the confusion is caused by the
>>> fact that setShared() method is placed on the IpFinderAdapter, while it
>>> actually makes sense only for VmIpFinder. Can we deprecate it and always
>>> return false from isShared() method for JDBC, S3 and others?
>>>
>>> -Val
>>>
>>> On Mon, Jan 18, 2016 at 1:56 AM, Yakov Zhdanov 
>>> wrote:
>>>
 Val, can you please review my changes to javadoc in master and update
 if necessary?

 --Yakov

 2016-01-15 23:13 GMT+03:00 Andrey Kornev :

> It does now! Thank you!
>
> Andrey
>
> --
> Date: Fri, 15 Jan 2016 12:10:15 -0800
> Subject: Re: TcpDiscoveryVmIpFinder's isShared property
> From: valentin.kuliche...@gmail.com
> To: user@ignite.apache.org
>
>
> Andrey,
>
> Setting shared=true for TcpDiscoveryVmIpFinder means that nodes can
> discover each other only within one JVM, when all nodes use the same
> instance of IP finder. The shared "storage" in this case is just a local
> collection. We use this heavily in unit tests, for example.
>
> TcpDiscoveryVmIpFinder with shared=false is how it's usually used.
> There is no shared storage, so addresses have to be statically provided in
> the configuration.
>
> shared=false for any other IP finder doesn't make any sense, because
> they use some kind of storage by definition (e.g., JDBC or S3). This 
> should
> be clarified in docs.
>
> Makes sense?
>
> -Val
>
> On Fri, Jan 15, 2016 at 9:16 AM, Andrey Kornev <
> andrewkor...@hotmail.com> wrote:
>
> Yakov,
>
> Thank you for the clarification, but I must admit I'm still not
> completely out of the woods with respect to intended usage. Setting the
> property to "false" seems to be most natural and only reasonable option,
> and I wonder when would one want to set it to true? I must be missing
> something.
>
> Also, just to clarify. In the last sentence you're saying: "This way
> user doesn't have to list any IPs before start..." How would then the new
> nodes know where to look for a node to connect to? They need to get the
> list of seed nodes from somewhere, right? If so, then setting isShared to
> true doesn't really make much difference - an initial list of seeds still
> must be provided to every node.
>
> Thanks
> Andrey
>
> --
> Date: Thu, 14 Jan 2016 12:55:52 +0300
> Subject: Re: TcpDiscoveryVmIpFinder's isShared property
> From: yzhda...@apache.org
> To: user@ignite.apache.org
>
>
> Guys, this property is supported in VM IP finder for simplifying
> discovery in single VM. I agree, that name could be better, but I would 
> not
> mess with it for now and just fix the javadocs (pls review, I did that in
> master).
>
> "isShared" is a property of any IP finder. If it is "true" then IP
> finder allows to add and remove addresses in runtime and this is how, for
> example, S3 IP finder works. If "isShared" is "false" then IP finder is
> immutable and all the addresses should be listed in configuration. This is
> the most use case for VM IP finder. Since, usually VM IP finder is created
> per each Ignite instance and all the known IPs are listed right away, but
> there is also an option to make it shared - set "isShared" to true and
> literally share it between local VM Ignite instances. This way user does
> not have to list any IPs before start, instead all starting nodes add 
> their
> addresses to the finder, then get the registered addresses and continue
> with discovery procedure.
>
> --Yakov
>
> 2016-01-13 22:45 GMT+03:00 Dmitriy Setrakyan :
>
> Any chance we could get an explanation here, so we can update the
> docs? Yakov, I think you would know how this flag wor