Re: changed cache configuration and restarted server nodes. Getting exception.

[Vladimir Ozerov]

Hi Vinay,

Thanks for provided description. But I am afraid it is too broad for us to
start investigation, because there are lots similar cases when all works
fine. Though, the problem you faced seems pretty serious to me and we
definitely need to find the root cause.

Can we expect more assistance from your side with it? Any more hints - XML
configuration, simplified code sample to reproduce the issue, etc. are
appreciated.

Vladimir.

On Fri, Feb 19, 2016 at 6:32 PM, vinshar  wrote:

> Thanks for workaround Vladimir. I am using multiple caches. Each cache has
> key as long and value are POJOs. One is Program Cache of type  ProgramDto> and similar other caches exists. All had this problem. All
> these
> value classes are simple POJOs which implement serializable, does not
> override any of Object classes methods (equals, hashcode, toString etc) and
> have class attributes of type - long, String, Boolean, java.sql.Timestamp
> with getter setter methods. All classes do have auto generated "private
> static final long serialVersionUID "
>
> I also thought of a workaround of having a MBean which ,out of many other
> tasks, can also restart encapsulated Ignite instance in my custom cache
> manager. I landed in a  issue there which i will share in a separate
> thread.
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/changed-cache-configuration-and-restarted-server-nodes-Getting-exception-tp3064p3100.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: Pagination to fetch complete Cache data

[sujay...@ymail.com]

Yes Val, let me try the options

I will get the Ignite from master and check it out

Thanks again Val for timely help



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Pagination-to-fetch-complete-Cache-data-tp3071p3111.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

RE: Wait for nodes to join the cluster

[vkulichenko]

Yes, good points. Thanks, Andrey.

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Wait-for-nodes-to-join-the-cluster-tp3103p3110.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

RE: Wait for nodes to join the cluster

[Andrey Kornev]

I think a slightly simpler (and less racy) implementation would look something 
like this:

ignite.events().localListen(new IgnitePredicate() {
@Override public boolean apply(DiscoveryEvent event) {
if (event.topologyNodes().size() >= 10) {
// GO!
}
 
return true;
}
}, EventType.EVT_NODE_JOINED);Also, I believe EventType.EVT_NODE_JOINED events 
must be enabled in the configuration:

IgniteConfiguration.setIncludeEventTypes(new int[]{EventType.EVT_NODE_JOINED});

Regards
Andrey

> Date: Fri, 19 Feb 2016 14:06:38 -0800
> From: valentin.kuliche...@gmail.com
> To: user@ignite.apache.org
> Subject: Re: Wait for nodes to join the cluster
> 
> Hi Paolo,
> 
> You can register a discovery event listener and check the topology size
> there:
> 
> ignite.events().localListen(new IgnitePredicate() {
> @Override public boolean apply(Event event) {
> if (ignite.cluster().nodes().size() >= 10) {
> // GO!
> }
> 
> return true;
> }
> }, EventType.EVT_NODE_JOINED);
> 
> Note that it's better to run execution asynchronously in this case, not to
> block the Ignite's internal thread that processes events.
> 
> Let me know if this helps.
> 
> -Val
> 
> 
> 
> --
> View this message in context: 
> http://apache-ignite-users.70518.x6.nabble.com/Wait-for-nodes-to-join-the-cluster-tp3103p3104.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
  

Re: Ignite instance hangs during restart in client mode

[Valentin Kulichenko]

Crossposting to dev@.

Folks,

This is not the first time I see this issue. Is there a way to detect it
and throw an exception?

-Val

On Fri, Feb 19, 2016 at 2:42 PM, vkulichenko 
wrote:

> Hi Vinay,
>
> Yes, you should always create the configuration object from scratch when
> starting a node. Mainly it's because it contains SPIs (e.g.,
> TcpDiscoverySpi) which have lifecycle and can't be reused.
>
> Makes sense?
>
> -Val
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/Ignite-instance-hangs-during-restart-in-client-mode-tp3101p3106.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: IgniteScheduler cron format extension {n1, n2}

[vkulichenko]

Hi Steve,

Yes, n1 is just a delay before submission to Cron scheduler.

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/IgniteScheduler-cron-format-extension-n1-n2-tp3102p3105.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

IgniteScheduler cron format extension {n1, n2}

[Steve Scheck]

Hello,

As per the docs, IgniteScheduler allows you to include the special prefix {n1, 
n2} in the cron string where n1 is “delay of scheduling in seconds”. Could 
someone on the development team elaborate on what that means, exactly? Is n1 
essentially trying to add a “seconds” field to the cron string (it seems not, I 
haven’t observed a seconds delay on subsequent firings that occur on specific 
minutes, they always start on the minute). Or does it just delay submission to 
the scheduler for the specified number of seconds?

Thanks.

Ignite instance hangs during restart in client mode

[vinshar]

Hi,

I was facing a problem due to which i thought that its a good idea to have a
MBean which can do following
1) Restart a embedded client node in an app (we have a custom cache manager
as abstraction over Ignite instance)
2) Can also close or clear caches if required
2) Collate and print metrics the way we may want. 

I implemented above and problem i am facing now is that MBean stops already
running embedded instance successfully but new instance hangs. Thread never
returns. Just to make sure that issue is not in my abstraction and I
replicated the behavior through test case method pasted below. 

My observations are in the end but my guess is that use of same
IgniteConfiguration object is creating problem. This object is mutable and
is mutated by Ignition.start in a way that causes issues if used to start
another instance in client mode.

@Test
public void test() {
LOGGER.debug("START");
IgniteConfiguration config = new IgniteConfiguration();
config.setClientMode(true);
List lst = new ArrayList();
lst.add("127.0.0.1:47500");

TcpDiscoverySpi dspi = new TcpDiscoverySpi();
TcpDiscoveryMulticastIpFinder finder = new
TcpDiscoveryMulticastIpFinder();
dspi.setIpFinder(finder);
finder.setAddresses(lst);
config.setDiscoverySpi(dspi);

Ignite ignite = Ignition.start(config);
Cache cache = ignite.getOrCreateCache("TEST");
cache.put(1,1);
ignite.close();
ignite = Ignition.start(config);
cache =ignite.getOrCreateCache("TEST");
cache.put(1,1);
System.out.println(cache.get(1));
LOGGER.debug("END");
}

A few observations:-
1) Testcase works fine if nodes being started in test case are not client.
2) Server side topology version logger logs joining and leaving of client
nodes as expected. 2nd client node never leaves.
3) i see below error in logs during start of 2nd client node:- WARNING
[Thread-13] org.apache.ignite.logger.java.JavaLogger.warning Custom H2
serialization is already configured, will override.
4) If i do not use same IgniteConfiguration object then test case works
fine.

Regards,
Vinay Sharma 



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Ignite-instance-hangs-during-restart-in-client-mode-tp3101.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: changed cache configuration and restarted server nodes. Getting exception.

[vinshar]

Thanks for workaround Vladimir. I am using multiple caches. Each cache has
key as long and value are POJOs. One is Program Cache of type  and similar other caches exists. All had this problem. All these
value classes are simple POJOs which implement serializable, does not
override any of Object classes methods (equals, hashcode, toString etc) and
have class attributes of type - long, String, Boolean, java.sql.Timestamp
with getter setter methods. All classes do have auto generated "private
static final long serialVersionUID "

I also thought of a workaround of having a MBean which ,out of many other
tasks, can also restart encapsulated Ignite instance in my custom cache
manager. I landed in a  issue there which i will share in a separate thread.



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/changed-cache-configuration-and-restarted-server-nodes-Getting-exception-tp3064p3100.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Can I use Backup Node Instead Primary Node On Partitioned Cache

[kwon]

Thank you very much!

2016-02-19 18:33 GMT+09:00 yakov [via Apache Ignite Users] <
ml-node+s70518n3094...@n6.nabble.com>:

> Hello!
>
> Please see
> org.apache.ignite.configuration.CacheConfiguration#isReadFromBackup which
> is true by default. So, if backup is local and rebalancing has finished and
> no persistent store configured then no network calls should be done. I
> think the latest changes to this logic have not been released yet, but they
> will be in 1.6. For now you can build from master.
>
> --Yakov
>
> 2016-02-19 12:09 GMT+03:00 kwon <[hidden email]
> >:
>
>> Hi, All.
>>
>> I have some question about get data with specific key from backup node
>> instead of primary node on partitioned cache for performance.
>>
>> more specifically,
>> if local client that reside same JVM with partion1 find some specific key
>> for partition2 ,
>> and partion2's backup partition is reside partition1's JVM,
>> then is it possible that get value from partion2's backup partition
>> instead
>> of get from primary partition to avoid additional workload(like network)?
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://apache-ignite-users.70518.x6.nabble.com/Can-I-use-Backup-Node-Instead-Primary-Node-On-Partitioned-Cache-tp3092.html
>> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>>
>
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://apache-ignite-users.70518.x6.nabble.com/Can-I-use-Backup-Node-Instead-Primary-Node-On-Partitioned-Cache-tp3092p3094.html
> To unsubscribe from Can I use Backup Node Instead Primary Node On
> Partitioned Cache, click here
> 
> .
> NAML
> 
>



-- 
--
*權 主惠 - KWON JUHYE*
開発部
--

〒150-0013
東京都渋谷区恵比寿4-9-10
tel  03-5793-3731 | fax  03-5793-3732
web   |  map

  |  email 




--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Can-I-use-Backup-Node-Instead-Primary-Node-On-Partitioned-Cache-tp3092p3096.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: IGFS: Writing to a nonexistent file: "Failed to append to the file due to secondary file system exception"

[Vladimir Ozerov]

Kobe,

Append and create operations cannot use the same code path since append
operation require some additional synchronization between primary and
secondary file systems. Anyway, the problem is known and will be fixed.

Vladimir.

On Thu, Feb 18, 2016 at 8:24 PM, Kobe  wrote:

> I was able to sidestep the problem by using create(), however, this bothers
> me since,
> I would have expected update() and create() to be based on same set of
> underlying code.
>
> Thanks,
>
>
>
> Ivan Veselovsky wrote
> > Hi, Kobe,
> > yes, please use #create() method as a workaround, that should work.
> >
> > On Thu, Feb 18, 2016 at 3:02 AM, Kobe 
>
> > rk_@
>
> >  wrote:
> >
> >> I see that this is a known issue:
> >>
> >>https://issues.apache.org/jira/browse/IGNITE-1631
> >>
> >> and is planned to be resolved in 1.6
> >>
> >> What is the workaround? Should I choose not to use DUAL_SYNC?
> >>
> >> If I create the file using IgniteFileSystem.create() would that sidestep
> >> this problem?
> >>
> >> Thanks,
> >>
> >> Rk
> >> x77309
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://apache-ignite-users.70518.x6.nabble.com/IGFS-Writing-to-a-nonexistent-file-Failed-to-append-to-the-file-due-to-secondary-file-system-excepti-tp3065p3067.html
> >> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
> >>
>
>
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/IGFS-Writing-to-a-nonexistent-file-Failed-to-append-to-the-file-due-to-secondary-file-system-excepti-tp3065p3086.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: Can I use Backup Node Instead Primary Node On Partitioned Cache

[Yakov Zhdanov]

Hello!

Please see
org.apache.ignite.configuration.CacheConfiguration#isReadFromBackup which
is true by default. So, if backup is local and rebalancing has finished and
no persistent store configured then no network calls should be done. I
think the latest changes to this logic have not been released yet, but they
will be in 1.6. For now you can build from master.

--Yakov

2016-02-19 12:09 GMT+03:00 kwon :

> Hi, All.
>
> I have some question about get data with specific key from backup node
> instead of primary node on partitioned cache for performance.
>
> more specifically,
> if local client that reside same JVM with partion1 find some specific key
> for partition2 ,
> and partion2's backup partition is reside partition1's JVM,
> then is it possible that get value from partion2's backup partition instead
> of get from primary partition to avoid additional workload(like network)?
>
>
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/Can-I-use-Backup-Node-Instead-Primary-Node-On-Partitioned-Cache-tp3092.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

AW: ExpiryPolicy based on cache element

[Christian Seiler]

Hi Val,
I will go the way you suggested and see how far I can get with that.
Thank you for the quick response!

Regards
Christian

--
InteRes GmbH -   Dr. Christian Seiler
Rheinstrasse 44-46   64283 Darmstadt
fon: +49 6151 307 40 18  fax: -11
www.interes.com   christian.sei...@interes.com

Geschäftsführer:
Volker Herrmann

Registergericht: Amtsgericht Darmstadt
Registernummer: HRB 6831/Darmstadt
Steuernummer: DE 189 632 313 

ITB Berlin - Sie finden uns als Mitaussteller am DRV-Stand in Halle 10.1. 
Schauen Sie vorbei, wir freuen uns!

-Ursprüngliche Nachricht-
Von: vkulichenko [mailto:valentin.kuliche...@gmail.com] 
Gesendet: Mittwoch, 17. Februar 2016 22:14
An: user@ignite.apache.org
Betreff: Re: ExpiryPolicy based on cache element

Hi Christian,

You can broadcast a closure which will use IgniteCache.localEntries() method
to iterate through the local data and remove all required data. This way you
will minimize the network utilization.

Will this work for you?

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/ExpiryPolicy-based-on-cache-element-tp3059p3062.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.