From galder at redhat.com  Tue Jan  3 10:34:33 2017
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Tue, 3 Jan 2017 16:34:33 +0100
Subject: [infinispan-dev] First weekly meeting of the year
Message-ID: <197E83A9-B2B2-4EC9-8482-14D90C3260DB@redhat.com>

Hi all,

We had a short weekly meeting today with a subset of the team, discussing what we did before the break and what we'll be up to this coming week:
http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2017/infinispan.2017-01-03-15.16.html

Cheers,
--
Galder Zamarre?o
Infinispan, Red Hat



From vrigamon at redhat.com  Tue Jan  3 13:33:48 2017
From: vrigamon at redhat.com (Vittorio Rigamonti)
Date: Tue, 3 Jan 2017 13:33:48 -0500 (EST)
Subject: [infinispan-dev] First weekly meeting of the year
In-Reply-To: <197E83A9-B2B2-4EC9-8482-14D90C3260DB@redhat.com>
References: <197E83A9-B2B2-4EC9-8482-14D90C3260DB@redhat.com>
Message-ID: <977349346.7837304.1483468428173.JavaMail.zimbra@redhat.com>

Hi All,

sorry I miss the meeting alert this afternoon. 
Just a quick add on my activities before holidays:

#topic rigazilla
I worked on

HRCPP-311 	 Client should load PEM certificate also from file

without any progress: everything I tried end up with a certificate installed into the certs store
or the need to rewrite all the verification chain by hands.

Little frustrating...

This week I'll release the 8.1.0.Beta1 and I'll probably have some time to spend on the product side.

Happy New Year!



----- Original Message -----
From: "Galder Zamarre?o" <galder at redhat.com>
To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
Sent: Tuesday, January 3, 2017 4:34:33 PM
Subject: [infinispan-dev] First weekly meeting of the year

Hi all,

We had a short weekly meeting today with a subset of the team, discussing what we did before the break and what we'll be up to this coming week:
http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2017/infinispan.2017-01-03-15.16.html

Cheers,
--
Galder Zamarre?o
Infinispan, Red Hat


_______________________________________________
infinispan-dev mailing list
infinispan-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev


From galder at redhat.com  Fri Jan  6 07:32:08 2017
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Fri, 6 Jan 2017 13:32:08 +0100
Subject: [infinispan-dev] Data Container Changes Part 1
In-Reply-To: <0be1da11-1129-1f48-ac13-cb466fadcbcc@redhat.com>
References: <CA+YCuUOYUWvqhgDBWsA4-y10NbKnEHV+V+E+iLuzM=z4QSecXg@mail.gmail.com>
	<d8583c62-db84-9981-2ef6-af03373a8928@redhat.com>
	<CA+YCuUMtt_=TZ81pjW+7GjKAr1GwjULAKy4iBuaX1k_5SS1_kg@mail.gmail.com>
	<0be1da11-1129-1f48-ac13-cb466fadcbcc@redhat.com>
Message-ID: <955CD6A1-C895-445A-9224-87D2021A1EB2@redhat.com>

The problem of annotations is that you need to modify the cached value, and the user might not be able to do that, e.g. not their code.

Flags are fine IMO. I only have two problems with them:

1. We don't separate user vs internal flags.
2. Flags can't carry values.

In functional, I've fixed this by doing Param (flag replacement in functional) only for user concerns, and they can carry values.

Cheers,
--
Galder Zamarre?o
Infinispan, Red Hat

> On 20 Dec 2016, at 17:10, Radim Vansa <rvansa at redhat.com> wrote:
> 
> Perfect! This would reduce the only limitation of dist/replicated caches 
> in 2LC, while I am convinced that these have much better performance 
> (there have been some changes recently, so I have to re-run the perf tests).
> 
> So, how should that feature be exposed to users?
> 
> 1) Annotating the value class with @NonEvictable or @Evictable(false)
> - What if the user can't change the class definition? That would require 
> us to provide alternative way as well (listing classes in configuration)
> - Should we set this fixed for a value class? Inheritance?
> - Should we support also @NonEvictable keys?
> 
> 2) Adding Flag.NON_EVICTABLE to the write
> - Flags are a bit controversial, we shouldn't add more user-facing flags
> - We need a Param for functional commands as well
> 
> 3) Other ways?
> 
> Should we create another type of CacheEntry (-1), add a flag to 
> Metadata, or something else?
> 
> Radim
> 
> 
> On 12/20/2016 03:33 PM, William Burns wrote:
>> Yes, definitely!
>> 
>> I made sure to check when I added Caffeine [1]
>> 
>> I was thinking we could add that later if we really need the feature.
>> 
>> - Will
>> 
>> [1] 
>> https://github.com/ben-manes/caffeine/blob/master/caffeine/src/main/java/com/github/benmanes/caffeine/cache/Caffeine.java#L347
>> 
>> On Tue, Dec 20, 2016 at 4:16 AM Radim Vansa <rvansa at redhat.com 
>> <mailto:rvansa at redhat.com>> wrote:
>> 
>>    Regarding another use of Weighter in Caffeine: would it be possible to
>>    guarantee that an object with weight 0 (or negative one) is never
>>    evicted?
>> 
>>    R.
>> 
>>    On 12/19/2016 10:10 PM, William Burns wrote:
>>> Check out some of the new changes to the Data Container in
>>    Infinispan
>>> 9.0. Beta 1 [1].  Part 2 will be probably after Holiday break.
>>> 
>>> [1]
>>    http://blog.infinispan.org/2016/12/data-container-changes-part-1.html
>>> 
>>> 
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>    <mailto:infinispan-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
>> 
>>    --
>>    Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>>
>>    JBoss Performance Team
>> 
>>    _______________________________________________
>>    infinispan-dev mailing list
>>    infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.jboss.org>
>>    https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> 
> -- 
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev



From galder at redhat.com  Mon Jan  9 08:49:34 2017
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Mon, 9 Jan 2017 14:49:34 +0100
Subject: [infinispan-dev] Property substitution for attributes that are part
	of paths - ISPN-7326
Message-ID: <0BB31825-2DB4-48AB-B0C3-38F00675066B@redhat.com>

Hey Paul,

Re: https://issues.jboss.org/browse/ISPN-7326

I have some doubts how to achieve what I'm trying to do in ^

More specifically, backup's 'site' attribute and remote-site's name attributes are special in the sense that they're not represented as SimpleAttributeDefinition instances. Instead, it seems like they're expected to be fully resolved when the XML read since they are part of path addresses.

Resolution when XML is read does not work since reading is done by the host controller and I'd want the resolution to happen when the particular server node starts up.

So, what would be the best way to achieve what I'm after?

One way I was thinking is maybe leaving the XML reading part as is, and only when the cache is added, do the resolution manually there. However, this does not seem to work as is, because the XML attribute is already resolved when I add the cache and it's resolved to the default value (cos process controller was not started with -D...), so I can't seem to get the original XML value. Moreover, even if this was resolved, would it be fine for the path address to have the default value for the property in it, and the actual cache configured with the name passed via system property? Doesn't sound right...

Any other way? Maybe add separate SimpleAttributeDefinition instances for these XML attributes on top of their path address values?

Cheers,
--
Galder Zamarre?o
Infinispan, Red Hat



From paul.ferraro at redhat.com  Mon Jan  9 11:47:25 2017
From: paul.ferraro at redhat.com (Paul Ferraro)
Date: Mon, 9 Jan 2017 11:47:25 -0500
Subject: [infinispan-dev] Property substitution for attributes that are
	part of paths - ISPN-7326
In-Reply-To: <0BB31825-2DB4-48AB-B0C3-38F00675066B@redhat.com>
References: <0BB31825-2DB4-48AB-B0C3-38F00675066B@redhat.com>
Message-ID: <CAF5qqoONNpwPMv_zytyqYR1TpEHBCzkkD=76RgDFeUgedgOaMA@mail.gmail.com>

Hi Galder,

The short answer: Attributes that are components of a resource path
address may not contain expressions.

What is the motivation behind ISPN-7326?

When the x-site domain model for Infinispan was originally designed,
the assumption was that a domain controller would never attempt to
manage a host residing in a remote data center.  Typically a domain
controller doesn't manage hosts outside of its own network.  Even an
architecture that uses multiple logical sites within the same physical
data center would still isolate each site to a separate network.

Question aside, there are at least 2 ways we can do this:

1. Refactor the model.  Remove the backup resource entirely.  This
means that individual site configurations will no longer be
addressable.  Instead, the parent resource would maintain a list of
backup objects, where "site" becomes a normal attribute that allows
expressions.

Dealing with complex object types in the model isn't exactly a
pleasurable experience, so I would first make sure that the
requirement is legitimate/realistic and thus warrants the change.  Of
course, the biggest headache will be the model transformations
required to support mixed domains (mixed domains are a reality of
upgrading), as well as translation of domain operations that reference
the legacy resources.

2. Decouple the logical backup name from the actual site name:

<backups>
    <backup name="remote" site="${...}" strategy="SYNC"/>
</backups>

Here, each host has an addressable "remote" backup resource, where the
site name is an expression and resolves to a host-specific value.
Additionally, we can make this site attribute optional, and have it
default to the backup name if undefined.

In conclusion, if this is confirmed to be a genuine feature request, I
would strongly encourage you to go with option #2.

Paul

On Mon, Jan 9, 2017 at 8:49 AM, Galder Zamarre?o <galder at redhat.com> wrote:
> Hey Paul,
>
> Re: https://issues.jboss.org/browse/ISPN-7326
>
> I have some doubts how to achieve what I'm trying to do in ^
>
> More specifically, backup's 'site' attribute and remote-site's name attributes are special in the sense that they're not represented as SimpleAttributeDefinition instances. Instead, it seems like they're expected to be fully resolved when the XML read since they are part of path addresses.
>
> Resolution when XML is read does not work since reading is done by the host controller and I'd want the resolution to happen when the particular server node starts up.
>
> So, what would be the best way to achieve what I'm after?
>
> One way I was thinking is maybe leaving the XML reading part as is, and only when the cache is added, do the resolution manually there. However, this does not seem to work as is, because the XML attribute is already resolved when I add the cache and it's resolved to the default value (cos process controller was not started with -D...), so I can't seem to get the original XML value. Moreover, even if this was resolved, would it be fine for the path address to have the default value for the property in it, and the actual cache configured with the name passed via system property? Doesn't sound right...
>
> Any other way? Maybe add separate SimpleAttributeDefinition instances for these XML attributes on top of their path address values?
>
> Cheers,
> --
> Galder Zamarre?o
> Infinispan, Red Hat
>


From galder at redhat.com  Tue Jan 10 05:09:47 2017
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Tue, 10 Jan 2017 11:09:47 +0100
Subject: [infinispan-dev] Property substitution for attributes that are
	part of paths - ISPN-7326
In-Reply-To: <CAF5qqoONNpwPMv_zytyqYR1TpEHBCzkkD=76RgDFeUgedgOaMA@mail.gmail.com>
References: <0BB31825-2DB4-48AB-B0C3-38F00675066B@redhat.com>
	<CAF5qqoONNpwPMv_zytyqYR1TpEHBCzkkD=76RgDFeUgedgOaMA@mail.gmail.com>
Message-ID: <D1717035-6418-4F55-8884-DC0275253BA4@redhat.com>

Hey Paul,

Thanks for the quick answer. 

The motivation for ISPN-7326 is to reduce domain configuration needed to test xsite replication in the Javascript client. Without ISPN-7326 I'm having to duplicate profiles for each site where the changing values are minimal. It would be helpful to control the values I mentioned via system property to reduce the number of profiles required in the domain config.

The reason I'm interested in reducing the number of changes I make the default domain config (e.g. by reducing number of profiles) is to make it easier in the future to migrate to newer domain configurations.

To be more precise, domain.xml in [1] contains 3 clustered profiles: 'clustered', 'earth' and 'moon'. This makes the configuration for testing clustered and xsite capabilities quite verbose. Ideally, I'd like to have 1 clustered profile, 'clustered', and using system properties select which transport to use and provide optional site names...etc where needed.

So indeed, the motivation for this is not a real environment.

Your sugggestion for 2. doesn't sound too bad. Note that a similar approach would be required for remote-site's name.	

Thoughts?

[1] https://github.com/galderz/js-client/blob/16c985e0957c10f332c0dc9b561997c3f88c1c24/spec/configs/domain.xml
--
Galder Zamarre?o
Infinispan, Red Hat

> On 9 Jan 2017, at 17:47, Paul Ferraro <paul.ferraro at redhat.com> wrote:
> 
> Hi Galder,
> 
> The short answer: Attributes that are components of a resource path
> address may not contain expressions.
> 
> What is the motivation behind ISPN-7326?
> 
> When the x-site domain model for Infinispan was originally designed,
> the assumption was that a domain controller would never attempt to
> manage a host residing in a remote data center.  Typically a domain
> controller doesn't manage hosts outside of its own network.  Even an
> architecture that uses multiple logical sites within the same physical
> data center would still isolate each site to a separate network.
> 
> Question aside, there are at least 2 ways we can do this:
> 
> 1. Refactor the model.  Remove the backup resource entirely.  This
> means that individual site configurations will no longer be
> addressable.  Instead, the parent resource would maintain a list of
> backup objects, where "site" becomes a normal attribute that allows
> expressions.
> 
> Dealing with complex object types in the model isn't exactly a
> pleasurable experience, so I would first make sure that the
> requirement is legitimate/realistic and thus warrants the change.  Of
> course, the biggest headache will be the model transformations
> required to support mixed domains (mixed domains are a reality of
> upgrading), as well as translation of domain operations that reference
> the legacy resources.
> 
> 2. Decouple the logical backup name from the actual site name:
> 
> <backups>
>    <backup name="remote" site="${...}" strategy="SYNC"/>
> </backups>
> 
> Here, each host has an addressable "remote" backup resource, where the
> site name is an expression and resolves to a host-specific value.
> Additionally, we can make this site attribute optional, and have it
> default to the backup name if undefined.
> 
> In conclusion, if this is confirmed to be a genuine feature request, I
> would strongly encourage you to go with option #2.
> 
> Paul
> 
> On Mon, Jan 9, 2017 at 8:49 AM, Galder Zamarre?o <galder at redhat.com> wrote:
>> Hey Paul,
>> 
>> Re: https://issues.jboss.org/browse/ISPN-7326
>> 
>> I have some doubts how to achieve what I'm trying to do in ^
>> 
>> More specifically, backup's 'site' attribute and remote-site's name attributes are special in the sense that they're not represented as SimpleAttributeDefinition instances. Instead, it seems like they're expected to be fully resolved when the XML read since they are part of path addresses.
>> 
>> Resolution when XML is read does not work since reading is done by the host controller and I'd want the resolution to happen when the particular server node starts up.
>> 
>> So, what would be the best way to achieve what I'm after?
>> 
>> One way I was thinking is maybe leaving the XML reading part as is, and only when the cache is added, do the resolution manually there. However, this does not seem to work as is, because the XML attribute is already resolved when I add the cache and it's resolved to the default value (cos process controller was not started with -D...), so I can't seem to get the original XML value. Moreover, even if this was resolved, would it be fine for the path address to have the default value for the property in it, and the actual cache configured with the name passed via system property? Doesn't sound right...
>> 
>> Any other way? Maybe add separate SimpleAttributeDefinition instances for these XML attributes on top of their path address values?
>> 
>> Cheers,
>> --
>> Galder Zamarre?o
>> Infinispan, Red Hat
>> 



From rory.odonnell at oracle.com  Tue Jan 10 05:19:10 2017
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Tue, 10 Jan 2017 10:19:10 +0000
Subject: [infinispan-dev] JDK 9 EA Build 151 is available on java.net
Message-ID: <8a4d77f1-af8a-6172-cc01-df8f3a38b397@oracle.com>


Hi Galder,

Best wishes for the New Year.

Dalibor and I will be at FOSDEM '17, Brussels 4 & 5 February. Let us 
know if you will be there, hopefully we can meet up !

*JDK 9 Early Access* b151 <https://jdk9.java.net/download/>  is 
available on java.net

There have been a number of fixes to bugs reported by Open Source 
projects since the last availability email  :

  * JDK-8171377 : Add sun.misc.Unsafe::invokeCleaner
  * JDK-8075793 : Source incompatibility for inference using -source 7
  * JDK-8087303  : LSSerializer pretty print does not work anymore
  * JDK-8167143 :CLDR timezone parsing does not work for all locales

Other changes that maybe of interest:

  * JDK-8066474 : Remove the lib/$ARCH directory from Linux and Solaris
    images
  * JDK-8170428 : Move src.zip to JDK/lib/src.zip

*JEPs intergrated:*

  * JEP 295 <http://openjdk.java.net/jeps/295>: Ahead-of-Time
    Compilation has been integrated in b150.

*Schedule - Milestones since last availability email *

  * *Feature Extension Complete 22nd of December 2016*
  * *Rampdown Started 5th of January 2017
    *
      o Phases in which increasing levels of scrutiny are applied to
        incoming changes.
      o In phase 1, only P1-P3 bugs can be fixed. In phase 2 only
        showstopper bugs can be fixed.

Rgds,Rory

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170110/85c9932d/attachment.html 

From ttarrant at redhat.com  Tue Jan 10 08:13:53 2017
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Tue, 10 Jan 2017 14:13:53 +0100
Subject: [infinispan-dev] Infinispan Weekly IRC Meeting Logs 2016-01-09
Message-ID: <5ea5dd93-4bc1-f935-39b8-23efabaa2e7e@redhat.com>

Dear Infinispan users/devs,

the logs for yesterday's IRC meeting are available at

http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2017/infinispan.2017-01-09-15.01.log.html

Tristan
-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat

From sjena at aurusinc.com  Tue Jan 10 11:06:18 2017
From: sjena at aurusinc.com (Sridhar Jena)
Date: Tue, 10 Jan 2017 21:36:18 +0530
Subject: [infinispan-dev] Infinispan Memory Issue - Storing Index
 Memory(ram) - OutOfMemoryError: Java heap space
Message-ID: <0aa55209-4a66-cce9-d27d-f721b99d3b82@aurusinc.com>

Hi Dev Team,

I am using infinispan 8.2.4 standalone hotrod server and i am facing 
"*java.lang.OutOfMemoryError: Java heap space*"  issue when putting or 
retrieving the data into cache.

In below two ways i have loaded the data into local cache.

_/*Case 1*/_ : *(Data Loading is taking more time, But there is no issue 
with **"**OutOfMemoryError: Java heap space**"**)*

In this case I am storing the index into a different dedicated 
infinispan cache by using the below tag ,

/*<property name="default.directory_provider">Infinispan</property>*/

I have observed that it is taking much time to load the data into cache 
, but in this case i am not facing /Java Out of memory heap space/ issue 
during data putting or retrieving.

/Below is local cache configuration,/

<local-cache name="MERCHANT_STORE_DETAILS" start="EAGER">

             <locking acquire-timeout="30000" concurrency-level="1000" 
striping="false"/>
             <transaction mode="NONE"/>
             <eviction strategy="NONE"/>
             <file-store path="/MRSD/data" purge="false" 
passivation="false" preload="true"/>
             <indexing index="LOCAL">
                             <property 
name="default.indexmanager">*org.infinispan.query.indexmanager.InfinispanIndexManager*</property>
                             <property 
name="default.directory_provider">*Infinispan*</property>
                             <property 
name="default.metadata_cachename">MRSD-INDEX_META_DATA</property>
                             <property 
name="default.data_cachename">MRSD-INDEX_DATA</property>
                            <property 
name="default.locking_cachename">MRSD-INDEX_LOCKING</property>
             </indexing>
</local-cache>
<local-cache name="MRSD-INDEX_META_DATA" start="EAGER">
              <indexing index="NONE"/>
             <file-store path="/MRSD/index/indexMetadata" shared="false" 
purge="false" passivation="false" preload="true" fetch-state="true" 
read-only="false"/>
  </local-cache>
  <local-cache name="MRSD-INDEX_DATA" start="EAGER">
           <indexing index="NONE"/>
           <file-store path="MRSD/index/indexData" shared="false" 
purge="false" passivation="false" preload="true" fetch-state="true" 
read-only="false"/>
</local-cache>
<local-cache name="MRSD-INDEX_LOCKING" start="EAGER">
           <indexing index="NONE"/>
           <file-store path="MRSD/index/indexLocking" shared="false" 
purge="false" passivation="false" preload="true" fetch-state="true" 
read-only="false"/>
</local-cache>


*Time Taken To Load Data: *3 Min 13 Sec*
*

*Number of Records :* 45024


/*_Case 2_ */: *(Data Loading is very quick, But issue with 
**"**OutOfMemoryError: Java heap space**"**)*

In this case I am storing the index into memory by using the below tag ,

/*<property name="default.directory_provider">ram</property>*/

I have observed that, data has loaded into cache with in some seconds 
for same number of records that mentioned in _Case 1_,

But in this case when i am trying the store the same number of 
records(*45024*) multiple times and retrieving the data in same duration 
, It is throwing *OutOfMemoryError: Java heap space *in 
/infinispan-server-8.2.4.Final/standalone/configuration/server.log./

/Below is local cache configuration,

/<local-cache name="MERCHANT_STORE_DETAILS" start="EAGER">
             <locking acquire-timeout="30000" concurrency-level="1000" 
striping="false"/>
                     <transaction mode="NONE"/>
                    <eviction strategy="NONE"/>
                     <indexing index="LOCAL">
                             <property 
name="default.indexmanager">near-real-time</property>
                             <property 
name="default.directory_provider">ram</property>
             </indexing>
</local-cache>


*Time Taken To Load Data: *32 Sec

*Number of Records :* 45024


_*Exception In Details

*_2017-01-09 06:38:31,777 ERROR [stderr] 
(HotRod-externalServerHandler-1-88) Exception in thread 
"HotRod-externalServerHandler-1-88" java.lang.OutOfMemoryError: Java 
heap space
2017-01-09 06:39:18,706 ERROR 
[org.hibernate.search.exception.impl.LogErrorHandler] (Lucene Merge 
Thread #7869 for index 
org.infinispan.query.remote.impl.indexing.ProtobufValueWrapper) 
HSEARCH000058: HSEARCH000118: Exception during index Merge operation: 
org.apache.lucene.index.MergePolicy$MergeException: 
java.lang.OutOfMemoryError: Java heap space
         at 
org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException(ConcurrentMergeScheduler.java:668)
         at 
org.hibernate.search.backend.impl.lucene.overrides.ConcurrentMergeScheduler.handleMergeException(ConcurrentMergeScheduler.java:42)
         at 
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:648)
Caused by: java.lang.OutOfMemoryError: Java heap space

2017-01-09 06:41:23,919 ERROR [stderr] 
(HotRod-externalServerHandler-1-88)      at 
org.antlr.runtime.Lexer.emit(Lexer.java:160)
2017-01-09 06:36:54,872 ERROR 
[org.jboss.as.controller.management-operation] 
(DeploymentScanner-threads - 2) WFLYCTL0013: Operation 
("read-children-resources") failed - address: ([]): 
java.lang.OutOfMemoryError: Java heap space
         at java.util.HashMap.resize(HashMap.java:703)
         at java.util.HashMap.putVal(HashMap.java:628)
         at java.util.HashMap.put(HashMap.java:611)
         at 
org.jboss.as.controller.OperationContextImpl$AuthorizationResponseImpl.addResourceResult(OperationContextImpl.java:2356)
         at 
org.jboss.as.controller.OperationContextImpl$AuthorizationResponseImpl.access$700(OperationContextImpl.java:2328)
         at 
org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1764)
         at 
org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1659)
         at 
org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1618)
         at 
org.jboss.as.controller.OperationContextImpl.getResourceRegistration(OperationContextImpl.java:567)
         at 
org.jboss.as.controller.operations.global.ReadChildrenResourcesHandler.execute(ReadChildrenResourcesHandler.java:94)
         at 
org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
         at 
org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
         at 
org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
         at 
org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
         at 
org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
         at 
org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:204)
         at 
org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:659)
         at 
org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:649)
         at 
org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations.getDeploymentsStatus(DefaultDeploymentOperations.java:76)
         at 
org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScanContext.<init>(FileSystemDeploymentService.java:1614)
         at 
org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScanContext.<init>(FileSystemDeploymentService.java:1563)
         at 
org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:568)
         at 
org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:489)
         at 
org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$DeploymentScanRunnable.run(FileSystemDeploymentService.java:250)
         at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
         at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
         at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
         at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
         at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
         at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
         at java.lang.Thread.run(Thread.java:745)
         at org.jboss.threads.JBossThread.run(JBossThread.java:320)


2017-01-09 06:38:39,564 ERROR 
[org.infinispan.interceptors.InvocationContextInterceptor] 
(HotRod-externalServerHandler-1-107) ISPN000136: Error executing command 
PutKeyValueCommand, writing keys [[B0x4a1b313031323331..[29]]: 
java.lang.OutOfMemoryError: Java heap space
         at 
java.util.ResourceBundle.putBundleInCache(ResourceBundle.java:1694)
         at java.util.ResourceBundle.findBundle(ResourceBundle.java:1471)
         at java.util.ResourceBundle.findBundle(ResourceBundle.java:1419)
         at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1361)
         at java.util.ResourceBundle.getBundle(ResourceBundle.java:890)
         at sun.util.resources.LocaleData$1.run(LocaleData.java:164)
         at sun.util.resources.LocaleData$1.run(LocaleData.java:160)
         at java.security.AccessController.doPrivileged(Native Method)
         at sun.util.resources.LocaleData.getBundle(LocaleData.java:160)
         at 
sun.util.resources.LocaleData.getNumberFormatData(LocaleData.java:156)
         at 
sun.util.locale.provider.LocaleResources.getNumberPatterns(LocaleResources.java:439)
         at 
sun.util.locale.provider.NumberFormatProviderImpl.getInstance(NumberFormatProviderImpl.java:177)
         at 
sun.util.locale.provider.NumberFormatProviderImpl.getNumberInstance(NumberFormatProviderImpl.java:149)
         at java.text.NumberFormat.getInstance(NumberFormat.java:875)
         at java.text.NumberFormat.getInstance(NumberFormat.java:861)
         at java.text.NumberFormat.getNumberInstance(NumberFormat.java:458)
         at org.infinispan.commons.util.Util.prettyPrintTime(Util.java:353)
         at 
org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.lock(DefaultLockManager.java:238)
         at 
org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockAndRecord(AbstractLockingInterceptor.java:193)
         at 
org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitNonTxDataWriteCommand(AbstractLockingInterceptor.java:98)
         at 
org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor.visitDataWriteCommand(NonTransactionalLockingInterceptor.java:41)
         at 
org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitPutKeyValueCommand(AbstractLockingInterceptor.java:65)
         at 
org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:78)
         at 
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
         at 
org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:191)
         at 
org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:177)
         at 
org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:78)
         at 
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
         at 
org.infinispan.interceptors.compat.BaseTypeConverterInterceptor.visitPutKeyValueCommand(BaseTypeConverterInterceptor.java:84)
         at 
org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:78)
         at 
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
         at 
org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:114)


Could any one please help me here to fix the "*OutOfMemoryError: Java 
heap space*" issue for _*Case 2.

*_Please let me know if you need more information on this.

Thanks in advance.
_*
*_
-- 
Aurus Signature

*________________________________________________________________________________________________________________________________________________________________*

*Thanks and Regards,*

*Sridhar Jena,* Sr. Techincal Lead, Products

*+91 - 20 - 27655062* | *+91 - 9226345267* | *sjena345* | 
*www.aurusinc.com* <http://www.aurusinc.com/>
*Plot G-2, Sector 26, Pradhikaran, Pune, Maharashtra-411044*

<http://www.aurusinc.com/>

<https://www.facebook.com/pages/Aurus-Inc-Solution-and-Services-Provider/168611626510639> 
<https://twitter.com/aurustech> <http://linkedin.com/company/aurustech> 
<https://plus.google.com/100924847781939597025>

/*Please consider the environment before printing this e-mail */

Disclaimers: This message contains confidential information and is 
intended only for the individual named. If you are not the named 
addressee you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system. E-mail 
transmission cannot be guaranteed to be secure or error-free as 
information could be intercepted, corrupted, lost, destroyed, arrive 
late or incomplete, or contain viruses. The sender therefore does not 
accept liability for any errors or omissions in the contents of this 
message, which arise as a result of e-mail transmission. If verification 
is required please request a hard-copy version.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170110/892abeec/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graphics11
Type: image/png
Size: 1529 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170110/892abeec/attachment-0010.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graphics12
Type: image/png
Size: 1205 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170110/892abeec/attachment-0011.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graphics13
Type: image/png
Size: 1801 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170110/892abeec/attachment-0012.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graphics14
Type: image/png
Size: 1458 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170110/892abeec/attachment-0013.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graphics15
Type: image/png
Size: 1510 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170110/892abeec/attachment-0014.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Aurus
Type: image/png
Size: 6066 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170110/892abeec/attachment-0015.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graphics17
Type: image/png
Size: 2982 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170110/892abeec/attachment-0016.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graphics18
Type: image/png
Size: 3153 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170110/892abeec/attachment-0017.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graphics19
Type: image/png
Size: 3072 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170110/892abeec/attachment-0018.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graphics20
Type: image/png
Size: 1388 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170110/892abeec/attachment-0019.png 

From gustavo at infinispan.org  Tue Jan 10 11:23:37 2017
From: gustavo at infinispan.org (Gustavo Fernandes)
Date: Tue, 10 Jan 2017 16:23:37 +0000
Subject: [infinispan-dev] Infinispan Memory Issue - Storing Index
 Memory(ram) - OutOfMemoryError: Java heap space
In-Reply-To: <0aa55209-4a66-cce9-d27d-f721b99d3b82@aurusinc.com>
References: <0aa55209-4a66-cce9-d27d-f721b99d3b82@aurusinc.com>
Message-ID: <CAH8Ud1FV0yxY9oPCG6TWXMFyCOkc2Anh1WNX0wm8Ej404R55HQ@mail.gmail.com>

Hi, please use the forum[1] to post such questions.

To solve the OOME, have you configured your heap size correctly? AFAIR, the
default heap size is very small in the server

[1] https://developer.jboss.org/en/infinispan/content

On Tue, Jan 10, 2017 at 4:06 PM, Sridhar Jena <sjena at aurusinc.com> wrote:

> Hi Dev Team,
>
> I am using infinispan 8.2.4 standalone hotrod server and i am facing "*java.lang.OutOfMemoryError:
> Java heap space*"  issue when putting or retrieving the data into cache.
> In below two ways i have loaded the data into local cache.
>
> *Case 1* : *(Data Loading is taking more time, But there is no issue with
> **"**OutOfMemoryError: Java heap space**"**)*
>
> In this case I am storing the index into a different dedicated infinispan
> cache by using the below tag ,
>
> *            <property
> name="default.directory_provider">Infinispan</property>*
>
> I have observed that it is taking much time to load the data into cache ,
> but in this case i am not facing *Java Out of memory heap space* issue
> during data putting or retrieving.
> *Below is local cache configuration,*
>
> <local-cache name="MERCHANT_STORE_DETAILS" start="EAGER">
>             <locking acquire-timeout="30000" concurrency-level="1000"
> striping="false"/>
>             <transaction mode="NONE"/>
>             <eviction strategy="NONE"/>
>             <file-store path="/MRSD/data" purge="false"
> passivation="false" preload="true"/>
>             <indexing index="LOCAL">
>                             <property name="default.indexmanager">
> *org.infinispan.query.indexmanager.InfinispanIndexManager*</property>
>                             <property name="default.directory_provider">
> *Infinispan*</property>
>                             <property name="default.metadata_
> cachename">MRSD-INDEX_META_DATA</property>
>                             <property name="default.data_cachename">
> MRSD-INDEX_DATA</property>
>                            <property name="default.locking_
> cachename">MRSD-INDEX_LOCKING</property>
>             </indexing>
> </local-cache>
> <local-cache name="MRSD-INDEX_META_DATA" start="EAGER">
>              <indexing index="NONE"/>
>             <file-store path="/MRSD/index/indexMetadata" shared="false"
> purge="false" passivation="false" preload="true" fetch-state="true"
> read-only="false"/>
>  </local-cache>
>  <local-cache name="MRSD-INDEX_DATA" start="EAGER">
>           <indexing index="NONE"/>
>           <file-store path="MRSD/index/indexData" shared="false"
> purge="false" passivation="false" preload="true" fetch-state="true"
> read-only="false"/>
> </local-cache>
> <local-cache name="MRSD-INDEX_LOCKING" start="EAGER">
>           <indexing index="NONE"/>
>           <file-store path="MRSD/index/indexLocking" shared="false"
> purge="false" passivation="false" preload="true" fetch-state="true"
> read-only="false"/>
> </local-cache>
>
>
> *Time Taken To Load Data: *3 Min 13 Sec
>
> *Number of Records :* 45024
>
>
> *Case 2 *: *(Data Loading is very quick, But issue with **"**OutOfMemoryError:
> Java heap space**"**)*
>
> In this case I am storing the index into memory by using the below tag ,
>
> *<property name="default.directory_provider">ram</property>*
>
> I have observed that, data has loaded into cache with in some seconds for
> same number of records that mentioned in *Case 1*,
>
> But in this case when i am trying the store the same number of records(
> *45024*) multiple times and retrieving the data in same duration , It is
> throwing *OutOfMemoryError: Java heap space *in
> *infinispan-server-8.2.4.Final/standalone/configuration/server.log.*
>
>
> *Below is local cache configuration, *<local-cache
> name="MERCHANT_STORE_DETAILS" start="EAGER">
>             <locking acquire-timeout="30000" concurrency-level="1000"
> striping="false"/>
>                     <transaction mode="NONE"/>
>                    <eviction strategy="NONE"/>
>                     <indexing index="LOCAL">
>                             <property name="default.indexmanager">
> near-real-time</property>
>                             <property name="default.directory_
> provider">ram</property>
>             </indexing>
> </local-cache>
>
>
> *Time Taken To Load Data: *32 Sec
>
> *Number of Records :* 45024
>
>
>
> *Exception In Details *2017-01-09 06:38:31,777 ERROR [stderr]
> (HotRod-externalServerHandler-1-88) Exception in thread
> "HotRod-externalServerHandler-1-88" java.lang.OutOfMemoryError: Java heap
> space
> 2017-01-09 06:39:18,706 ERROR [org.hibernate.search.exception.impl.LogErrorHandler]
> (Lucene Merge Thread #7869 for index org.infinispan.query.remote.
> impl.indexing.ProtobufValueWrapper) HSEARCH000058: HSEARCH000118:
> Exception during index Merge operation: org.apache.lucene.index.MergePolicy$MergeException:
> java.lang.OutOfMemoryError: Java heap space
>         at org.apache.lucene.index.ConcurrentMergeScheduler.
> handleMergeException(ConcurrentMergeScheduler.java:668)
>         at org.hibernate.search.backend.impl.lucene.overrides.
> ConcurrentMergeScheduler.handleMergeException(
> ConcurrentMergeScheduler.java:42)
>         at org.apache.lucene.index.ConcurrentMergeScheduler$
> MergeThread.run(ConcurrentMergeScheduler.java:648)
> Caused by: java.lang.OutOfMemoryError: Java heap space
>
> 2017-01-09 06:41:23,919 ERROR [stderr] (HotRod-externalServerHandler-1-88)
> at org.antlr.runtime.Lexer.emit(Lexer.java:160)
> 2017-01-09 06:36:54,872 ERROR [org.jboss.as.controller.management-operation]
> (DeploymentScanner-threads - 2) WFLYCTL0013: Operation
> ("read-children-resources") failed - address: ([]):
> java.lang.OutOfMemoryError: Java heap space
>         at java.util.HashMap.resize(HashMap.java:703)
>         at java.util.HashMap.putVal(HashMap.java:628)
>         at java.util.HashMap.put(HashMap.java:611)
>         at org.jboss.as.controller.OperationContextImpl$
> AuthorizationResponseImpl.addResourceResult(OperationContextImpl.java:
> 2356)
>         at org.jboss.as.controller.OperationContextImpl$
> AuthorizationResponseImpl.access$700(OperationContextImpl.java:2328)
>         at org.jboss.as.controller.OperationContextImpl.
> getBasicAuthorizationResponse(OperationContextImpl.java:1764)
>         at org.jboss.as.controller.OperationContextImpl.authorize(
> OperationContextImpl.java:1659)
>         at org.jboss.as.controller.OperationContextImpl.authorize(
> OperationContextImpl.java:1618)
>         at org.jboss.as.controller.OperationContextImpl.
> getResourceRegistration(OperationContextImpl.java:567)
>         at org.jboss.as.controller.operations.global.
> ReadChildrenResourcesHandler.execute(ReadChildrenResourcesHandler.java:94)
>         at org.jboss.as.controller.AbstractOperationContext.executeStep(
> AbstractOperationContext.java:890)
>         at org.jboss.as.controller.AbstractOperationContext.processStages(
> AbstractOperationContext.java:659)
>         at org.jboss.as.controller.AbstractOperationContext.
> executeOperation(AbstractOperationContext.java:370)
>         at org.jboss.as.controller.OperationContextImpl.executeOperation(
> OperationContextImpl.java:1344)
>         at org.jboss.as.controller.ModelControllerImpl.internalExecute(
> ModelControllerImpl.java:392)
>         at org.jboss.as.controller.ModelControllerImpl.execute(
> ModelControllerImpl.java:204)
>         at org.jboss.as.controller.ModelControllerImpl$3.execute(
> ModelControllerImpl.java:659)
>         at org.jboss.as.controller.ModelControllerImpl$3.execute(
> ModelControllerImpl.java:649)
>         at org.jboss.as.server.deployment.scanner.
> DefaultDeploymentOperations.getDeploymentsStatus(
> DefaultDeploymentOperations.java:76)
>         at org.jboss.as.server.deployment.scanner.
> FileSystemDeploymentService$ScanContext.<init>(
> FileSystemDeploymentService.java:1614)
>         at org.jboss.as.server.deployment.scanner.
> FileSystemDeploymentService$ScanContext.<init>(
> FileSystemDeploymentService.java:1563)
>         at org.jboss.as.server.deployment.scanner.
> FileSystemDeploymentService.scan(FileSystemDeploymentService.java:568)
>         at org.jboss.as.server.deployment.scanner.
> FileSystemDeploymentService.scan(FileSystemDeploymentService.java:489)
>         at org.jboss.as.server.deployment.scanner.
> FileSystemDeploymentService$DeploymentScanRunnable.run(
> FileSystemDeploymentService.java:250)
>         at java.util.concurrent.Executors$RunnableAdapter.
> call(Executors.java:511)
>         at java.util.concurrent.FutureTask.runAndReset(
> FutureTask.java:308)
>         at java.util.concurrent.ScheduledThreadPoolExecutor$
> ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>         at java.util.concurrent.ScheduledThreadPoolExecutor$
> ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
>         at java.lang.Thread.run(Thread.java:745)
>         at org.jboss.threads.JBossThread.run(JBossThread.java:320)
>
>
> 2017-01-09 06:38:39,564 ERROR [org.infinispan.interceptors.InvocationContextInterceptor]
> (HotRod-externalServerHandler-1-107) ISPN000136: Error executing command
> PutKeyValueCommand, writing keys [[B0x4a1b313031323331..[29]]:
> java.lang.OutOfMemoryError: Java heap space
>         at java.util.ResourceBundle.putBundleInCache(
> ResourceBundle.java:1694)
>         at java.util.ResourceBundle.findBundle(ResourceBundle.java:1471)
>         at java.util.ResourceBundle.findBundle(ResourceBundle.java:1419)
>         at java.util.ResourceBundle.getBundleImpl(ResourceBundle.
> java:1361)
>         at java.util.ResourceBundle.getBundle(ResourceBundle.java:890)
>         at sun.util.resources.LocaleData$1.run(LocaleData.java:164)
>         at sun.util.resources.LocaleData$1.run(LocaleData.java:160)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at sun.util.resources.LocaleData.getBundle(LocaleData.java:160)
>         at sun.util.resources.LocaleData.getNumberFormatData(
> LocaleData.java:156)
>         at sun.util.locale.provider.LocaleResources.getNumberPatterns(
> LocaleResources.java:439)
>         at sun.util.locale.provider.NumberFormatProviderImpl.getInstance(
> NumberFormatProviderImpl.java:177)
>         at sun.util.locale.provider.NumberFormatProviderImpl.
> getNumberInstance(NumberFormatProviderImpl.java:149)
>         at java.text.NumberFormat.getInstance(NumberFormat.java:875)
>         at java.text.NumberFormat.getInstance(NumberFormat.java:861)
>         at java.text.NumberFormat.getNumberInstance(NumberFormat.java:458)
>         at org.infinispan.commons.util.Util.prettyPrintTime(Util.java:353)
>         at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$
> KeyAwareExtendedLockPromise.lock(DefaultLockManager.java:238)
>         at org.infinispan.interceptors.locking.AbstractLockingInterceptor.
> lockAndRecord(AbstractLockingInterceptor.java:193)
>         at org.infinispan.interceptors.locking.AbstractLockingInterceptor.
> visitNonTxDataWriteCommand(AbstractLockingInterceptor.java:98)
>         at org.infinispan.interceptors.locking.
> NonTransactionalLockingInterceptor.visitDataWriteCommand(
> NonTransactionalLockingInterceptor.java:41)
>         at org.infinispan.interceptors.locking.AbstractLockingInterceptor.
> visitPutKeyValueCommand(AbstractLockingInterceptor.java:65)
>         at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(
> PutKeyValueCommand.java:78)
>         at org.infinispan.interceptors.base.CommandInterceptor.
> invokeNextInterceptor(CommandInterceptor.java:99)
>         at org.infinispan.interceptors.CacheMgmtInterceptor.
> updateStoreStatistics(CacheMgmtInterceptor.java:191)
>         at org.infinispan.interceptors.CacheMgmtInterceptor.
> visitPutKeyValueCommand(CacheMgmtInterceptor.java:177)
>         at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(
> PutKeyValueCommand.java:78)
>         at org.infinispan.interceptors.base.CommandInterceptor.
> invokeNextInterceptor(CommandInterceptor.java:99)
>         at org.infinispan.interceptors.compat.
> BaseTypeConverterInterceptor.visitPutKeyValueCommand(
> BaseTypeConverterInterceptor.java:84)
>         at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(
> PutKeyValueCommand.java:78)
>         at org.infinispan.interceptors.base.CommandInterceptor.
> invokeNextInterceptor(CommandInterceptor.java:99)
>         at org.infinispan.interceptors.InvocationContextInterceptor.
> handleAll(InvocationContextInterceptor.java:114)
>
>
> Could any one please help me here to fix the "*OutOfMemoryError: Java
> heap space*" issue for
>
> *Case 2. *Please let me know if you need more information on this.
>
> Thanks in advance.
>
> --
>
>
> *________________________________________________________________________________________________________________________________________________________________*
>
> *Thanks and Regards,*
>
> *Sridhar Jena,* Sr. Techincal Lead, Products
>
> * +91 - 20 - 27655062 <+91%2020%202765%205062>* | * +91 - 9226345267* | *
> sjena345* | *www.aurusinc.com* <http://www.aurusinc.com/>
> * Plot G-2, Sector 26, Pradhikaran, Pune, Maharashtra-411044*
>
> <http://www.aurusinc.com/>
>
>
> <https://www.facebook.com/pages/Aurus-Inc-Solution-and-Services-Provider/168611626510639>
> <https://twitter.com/aurustech> <http://linkedin.com/company/aurustech>
> <https://plus.google.com/100924847781939597025>
>
> *Please consider the environment before printing this e-mail *
>
> Disclaimers: This message contains confidential information and is
> intended only for the individual named. If you are not the named addressee
> you should not disseminate, distribute or copy this e-mail. Please notify
> the sender immediately by e-mail if you have received this e-mail by
> mistake and delete this e-mail from your system. E-mail transmission cannot
> be guaranteed to be secure or error-free as information could be
> intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
> contain viruses. The sender therefore does not accept liability for any
> errors or omissions in the contents of this message, which arise as a
> result of e-mail transmission. If verification is required please request a
> hard-copy version.
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170110/964efa37/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graphics15
Type: image/png
Size: 1510 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170110/964efa37/attachment-0010.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graphics14
Type: image/png
Size: 1458 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170110/964efa37/attachment-0011.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graphics17
Type: image/png
Size: 2982 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170110/964efa37/attachment-0012.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graphics20
Type: image/png
Size: 1388 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170110/964efa37/attachment-0013.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graphics13
Type: image/png
Size: 1801 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170110/964efa37/attachment-0014.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graphics18
Type: image/png
Size: 3153 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170110/964efa37/attachment-0015.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Aurus
Type: image/png
Size: 6066 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170110/964efa37/attachment-0016.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graphics12
Type: image/png
Size: 1205 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170110/964efa37/attachment-0017.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graphics11
Type: image/png
Size: 1529 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170110/964efa37/attachment-0018.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graphics19
Type: image/png
Size: 3072 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170110/964efa37/attachment-0019.png 

From paul.ferraro at redhat.com  Tue Jan 10 12:38:44 2017
From: paul.ferraro at redhat.com (Paul Ferraro)
Date: Tue, 10 Jan 2017 12:38:44 -0500
Subject: [infinispan-dev] Property substitution for attributes that are
	part of paths - ISPN-7326
In-Reply-To: <D1717035-6418-4F55-8884-DC0275253BA4@redhat.com>
References: <0BB31825-2DB4-48AB-B0C3-38F00675066B@redhat.com>
	<CAF5qqoONNpwPMv_zytyqYR1TpEHBCzkkD=76RgDFeUgedgOaMA@mail.gmail.com>
	<D1717035-6418-4F55-8884-DC0275253BA4@redhat.com>
Message-ID: <CAF5qqoM5uNfV0JEhWcRtsawkUZLKW2RCdx44v33hpEQKuXF3mw@mail.gmail.com>

On Tue, Jan 10, 2017 at 5:09 AM, Galder Zamarre?o <galder at redhat.com> wrote:
> Hey Paul,
>
> Thanks for the quick answer.
>
> The motivation for ISPN-7326 is to reduce domain configuration needed to test xsite replication in the Javascript client. Without ISPN-7326 I'm having to duplicate profiles for each site where the changing values are minimal. It would be helpful to control the values I mentioned via system property to reduce the number of profiles required in the domain config.
>
> The reason I'm interested in reducing the number of changes I make the default domain config (e.g. by reducing number of profiles) is to make it easier in the future to migrate to newer domain configurations.
>
> To be more precise, domain.xml in [1] contains 3 clustered profiles: 'clustered', 'earth' and 'moon'. This makes the configuration for testing clustered and xsite capabilities quite verbose. Ideally, I'd like to have 1 clustered profile, 'clustered', and using system properties select which transport to use and provide optional site names...etc where needed.
>
> So indeed, the motivation for this is not a real environment.

I see.  So long as we go with approach #2, I think this is worthwhile.

> Your sugggestion for 2. doesn't sound too bad. Note that a similar approach would be required for remote-site's name.

Ah, you mean for the JGroups remote-site config in the RELAY2
protocol.  Yeah, that shouldn't be too bad either.
e.g.
<relay site="local">
    <remote-site name="local" site-name="${...}" channel=".."/>
    <remote-site name="remote" site-name="${...}" channel=".."/>
</relay>

Here the site attribute of the relay resource must reference the
remote-site resource by it's name (because it is a model reference).
The relay resource's service handler currently stores the remote-sites
in a list.  We'll want to change this to map them by name.  Obtaining
the actual site-name (i.e. the value returned by
RelayConfiguration.getSiteName()) becomes a simple map lookup, now
that the site name is decoupled from the resource name.  We can still
make site-name optional, and default it to the resource name if
undefined.

I've opened https://issues.jboss.org/browse/WFLY-7871

Paul

> Thoughts?
>
> [1] https://github.com/galderz/js-client/blob/16c985e0957c10f332c0dc9b561997c3f88c1c24/spec/configs/domain.xml
> --
> Galder Zamarre?o
> Infinispan, Red Hat
>
>> On 9 Jan 2017, at 17:47, Paul Ferraro <paul.ferraro at redhat.com> wrote:
>>
>> Hi Galder,
>>
>> The short answer: Attributes that are components of a resource path
>> address may not contain expressions.
>>
>> What is the motivation behind ISPN-7326?
>>
>> When the x-site domain model for Infinispan was originally designed,
>> the assumption was that a domain controller would never attempt to
>> manage a host residing in a remote data center.  Typically a domain
>> controller doesn't manage hosts outside of its own network.  Even an
>> architecture that uses multiple logical sites within the same physical
>> data center would still isolate each site to a separate network.
>>
>> Question aside, there are at least 2 ways we can do this:
>>
>> 1. Refactor the model.  Remove the backup resource entirely.  This
>> means that individual site configurations will no longer be
>> addressable.  Instead, the parent resource would maintain a list of
>> backup objects, where "site" becomes a normal attribute that allows
>> expressions.
>>
>> Dealing with complex object types in the model isn't exactly a
>> pleasurable experience, so I would first make sure that the
>> requirement is legitimate/realistic and thus warrants the change.  Of
>> course, the biggest headache will be the model transformations
>> required to support mixed domains (mixed domains are a reality of
>> upgrading), as well as translation of domain operations that reference
>> the legacy resources.
>>
>> 2. Decouple the logical backup name from the actual site name:
>>
>> <backups>
>>    <backup name="remote" site="${...}" strategy="SYNC"/>
>> </backups>
>>
>> Here, each host has an addressable "remote" backup resource, where the
>> site name is an expression and resolves to a host-specific value.
>> Additionally, we can make this site attribute optional, and have it
>> default to the backup name if undefined.
>>
>> In conclusion, if this is confirmed to be a genuine feature request, I
>> would strongly encourage you to go with option #2.
>>
>> Paul
>>
>> On Mon, Jan 9, 2017 at 8:49 AM, Galder Zamarre?o <galder at redhat.com> wrote:
>>> Hey Paul,
>>>
>>> Re: https://issues.jboss.org/browse/ISPN-7326
>>>
>>> I have some doubts how to achieve what I'm trying to do in ^
>>>
>>> More specifically, backup's 'site' attribute and remote-site's name attributes are special in the sense that they're not represented as SimpleAttributeDefinition instances. Instead, it seems like they're expected to be fully resolved when the XML read since they are part of path addresses.
>>>
>>> Resolution when XML is read does not work since reading is done by the host controller and I'd want the resolution to happen when the particular server node starts up.
>>>
>>> So, what would be the best way to achieve what I'm after?
>>>
>>> One way I was thinking is maybe leaving the XML reading part as is, and only when the cache is added, do the resolution manually there. However, this does not seem to work as is, because the XML attribute is already resolved when I add the cache and it's resolved to the default value (cos process controller was not started with -D...), so I can't seem to get the original XML value. Moreover, even if this was resolved, would it be fine for the path address to have the default value for the property in it, and the actual cache configured with the name passed via system property? Doesn't sound right...
>>>
>>> Any other way? Maybe add separate SimpleAttributeDefinition instances for these XML attributes on top of their path address values?
>>>
>>> Cheers,
>>> --
>>> Galder Zamarre?o
>>> Infinispan, Red Hat
>>>
>


From bban at redhat.com  Thu Jan 12 04:17:38 2017
From: bban at redhat.com (Bela Ban)
Date: Thu, 12 Jan 2017 10:17:38 +0100
Subject: [infinispan-dev] Fwd: Re: Tags don't show up in Tags dropdown menu
In-Reply-To: <discussions/7878d1b2d7f211e69da7a957e1ccdc24/comments/3508916@github.com>
References: <discussions/7878d1b2d7f211e69da7a957e1ccdc24/comments/3508916@github.com>
Message-ID: <473b1976-96e8-8999-0077-4d618caf7133@redhat.com>


FYI

-------- Forwarded Message --------
Subject: 	Re: Tags don't show up in Tags dropdown menu
Date: 	Wed, 11 Jan 2017 16:54:07 -0800
From: 	Francis (GitHub Staff) <support at github.com>
To: 	Bela Ban <belaban at mailbox.org>



Hi Bela -

Thanks for getting in touch! The tag dropdown is capped at 100 tags for 
performance reasons, but you can still get the full list of tags on the 
repository tags page:

https://github.com/belaban/JGroups/tags

You can access the |JGroups-3.6.12.Final| tag by navigating to this URL:

https://github.com/belaban/JGroups/tree/JGroups-3.6.12.Final

I hope that helps, but let me know if you have any other questions!

All the best,
Francis

------------------------------------------------------------------------

     Howdy folks,

     kudos for the great work on GH!

     in my repo github.com/belaban/JGroups, under "branch:master" ->
     "tags", only a fraction of the tags show up. When I clone the repo,
     or on git ls-remote, they do show up (for example
     JGroups-3.6.12.Final), see below.

     Can you look at this? Not high prio as everything works, but is this
     a bug in GH?
     Cheers,
     Bela

     [belasmac] /Users/bela/JGroups$ git ls-remote origin |grep 3.6.12
     X11 forwarding request failed on channel 0
     7c4e70131237dd6b54d8c8bc2f2c336f40b93518 refs/tags/JGroups-3.6.12.Final


From rvansa at redhat.com  Thu Jan 12 04:45:25 2017
From: rvansa at redhat.com (Radim Vansa)
Date: Thu, 12 Jan 2017 10:45:25 +0100
Subject: [infinispan-dev] Fwd: Re: Tags don't show up in Tags dropdown
 menu
In-Reply-To: <473b1976-96e8-8999-0077-4d618caf7133@redhat.com>
References: <discussions/7878d1b2d7f211e69da7a957e1ccdc24/comments/3508916@github.com>
	<473b1976-96e8-8999-0077-4d618caf7133@redhat.com>
Message-ID: <7030956b-f6e0-b722-264c-17307b436169@redhat.com>

Seems that the tags are displayed in descending order, but the various 
formats for tags don't help that too much. Retagging consistently (e.g. 
just x.y.z.Omega) would help.

Btw., I don't see any link to /tags so it's not as useful to users who 
don't know GH that well.

R.

On 01/12/2017 10:17 AM, Bela Ban wrote:
> FYI
>
> -------- Forwarded Message --------
> Subject: 	Re: Tags don't show up in Tags dropdown menu
> Date: 	Wed, 11 Jan 2017 16:54:07 -0800
> From: 	Francis (GitHub Staff) <support at github.com>
> To: 	Bela Ban <belaban at mailbox.org>
>
>
>
> Hi Bela -
>
> Thanks for getting in touch! The tag dropdown is capped at 100 tags for
> performance reasons, but you can still get the full list of tags on the
> repository tags page:
>
> https://github.com/belaban/JGroups/tags
>
> You can access the |JGroups-3.6.12.Final| tag by navigating to this URL:
>
> https://github.com/belaban/JGroups/tree/JGroups-3.6.12.Final
>
> I hope that helps, but let me know if you have any other questions!
>
> All the best,
> Francis
>
> ------------------------------------------------------------------------
>
>       Howdy folks,
>
>       kudos for the great work on GH!
>
>       in my repo github.com/belaban/JGroups, under "branch:master" ->
>       "tags", only a fraction of the tags show up. When I clone the repo,
>       or on git ls-remote, they do show up (for example
>       JGroups-3.6.12.Final), see below.
>
>       Can you look at this? Not high prio as everything works, but is this
>       a bug in GH?
>       Cheers,
>       Bela
>
>       [belasmac] /Users/bela/JGroups$ git ls-remote origin |grep 3.6.12
>       X11 forwarding request failed on channel 0
>       7c4e70131237dd6b54d8c8bc2f2c336f40b93518 refs/tags/JGroups-3.6.12.Final
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From bban at redhat.com  Thu Jan 12 04:55:58 2017
From: bban at redhat.com (Bela Ban)
Date: Thu, 12 Jan 2017 10:55:58 +0100
Subject: [infinispan-dev] Fwd: Re: Tags don't show up in Tags dropdown
 menu
In-Reply-To: <7030956b-f6e0-b722-264c-17307b436169@redhat.com>
References: <discussions/7878d1b2d7f211e69da7a957e1ccdc24/comments/3508916@github.com>
	<473b1976-96e8-8999-0077-4d618caf7133@redhat.com>
	<7030956b-f6e0-b722-264c-17307b436169@redhat.com>
Message-ID: <eafe278b-a6e6-f198-9a32-81bac959cd96@redhat.com>



On 12/01/17 10:45, Radim Vansa wrote:
> Seems that the tags are displayed in descending order, but the various
> formats for tags don't help that too much. Retagging consistently (e.g.
> just x.y.z.Omega) would help.
>
> Btw., I don't see any link to /tags so it's not as useful to users who
> don't know GH that well.

Yes, I said that in my response to them, too

> R.
>
> On 01/12/2017 10:17 AM, Bela Ban wrote:
>> FYI
>>
>> -------- Forwarded Message --------
>> Subject: 	Re: Tags don't show up in Tags dropdown menu
>> Date: 	Wed, 11 Jan 2017 16:54:07 -0800
>> From: 	Francis (GitHub Staff) <support at github.com>
>> To: 	Bela Ban <belaban at mailbox.org>
>>
>>
>>
>> Hi Bela -
>>
>> Thanks for getting in touch! The tag dropdown is capped at 100 tags for
>> performance reasons, but you can still get the full list of tags on the
>> repository tags page:
>>
>> https://github.com/belaban/JGroups/tags
>>
>> You can access the |JGroups-3.6.12.Final| tag by navigating to this URL:
>>
>> https://github.com/belaban/JGroups/tree/JGroups-3.6.12.Final
>>
>> I hope that helps, but let me know if you have any other questions!
>>
>> All the best,
>> Francis
>>
>> ------------------------------------------------------------------------
>>
>>       Howdy folks,
>>
>>       kudos for the great work on GH!
>>
>>       in my repo github.com/belaban/JGroups, under "branch:master" ->
>>       "tags", only a fraction of the tags show up. When I clone the repo,
>>       or on git ls-remote, they do show up (for example
>>       JGroups-3.6.12.Final), see below.
>>
>>       Can you look at this? Not high prio as everything works, but is this
>>       a bug in GH?
>>       Cheers,
>>       Bela
>>
>>       [belasmac] /Users/bela/JGroups$ git ls-remote origin |grep 3.6.12
>>       X11 forwarding request failed on channel 0
>>       7c4e70131237dd6b54d8c8bc2f2c336f40b93518 refs/tags/JGroups-3.6.12.Final
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>

-- 
Bela Ban, JGroups lead (http://www.jgroups.org)


From galder at redhat.com  Thu Jan 12 06:10:44 2017
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Thu, 12 Jan 2017 12:10:44 +0100
Subject: [infinispan-dev] XSite route status listener in server -
	ISPN-7230/ISPN-7231
Message-ID: <12CFFDB8-000E-4C55-87FF-EC6FB90422E2@redhat.com>

Hi Paul,

Sorry to bother you again :)

Re: https://issues.jboss.org/browse/ISPN-7230 & https://issues.jboss.org/browse/ISPN-7231

The aim of these JIRAs is to have a x-site view exposed as an INFO message as well as JMX and DMR operation.

To do that, following Bela's advice, I've extracted RELAY2 protocol of the stack and on Infinispan's JGroupsTransport start() method, call setRouteStatusListener() with a relay RouteStatusListener implementation that allows the x-site view to be tracked [1].

This works fine in library mode, but in server, on startup setRouteStatusListener() sometimes gets called after the Relayer's viewAccepted() method has been already called (which is the one that calls into RouteStatusListener). These means that the inital x-site view might not be registered.

So, what would be the correct place to add the setRouteStatusListener() call so that all views are captured? Or given how the server works, do I need to avoid using setRouteStatusListener() and use my own, Infinispan level, listener for tracking somehow?

Cheers,

[1] https://github.com/galderz/infinispan/blob/t_7230/core/src/main/java/org/infinispan/remoting/transport/jgroups/JGroupsTransport.java#L926
--
Galder Zamarre?o
Infinispan, Red Hat



From paul.ferraro at redhat.com  Sat Jan 14 13:22:14 2017
From: paul.ferraro at redhat.com (Paul Ferraro)
Date: Sat, 14 Jan 2017 13:22:14 -0500
Subject: [infinispan-dev] XSite route status listener in server -
	ISPN-7230/ISPN-7231
In-Reply-To: <12CFFDB8-000E-4C55-87FF-EC6FB90422E2@redhat.com>
References: <12CFFDB8-000E-4C55-87FF-EC6FB90422E2@redhat.com>
Message-ID: <CAF5qqoMiSBMtNBvffxaDN+GyhygzL9Peeh=3vhSFnc+cPETznw@mail.gmail.com>

Hi Galder,

Sorry for the delay.  For server-mode, we'd need to set the
RouteStatusListener in the jgroups subsystem before the RELAY2
protocol is initialized.
e.g.
public class DefaultRouteStatusListener implements
RouteStatusListener, Supplier<Set<String>> {
    private final Set<String> view = new ConcurrentSkipListSet<>();
    @Override
    public void sitesUp(String... sites) {
        this.view.addAll(Arrays.asList(sites));
        log.receivedXSiteClusterView(view);
    }
    @Override
    public void sitesDown(String... sites) {
        this.view.removeAll(Arrays.asList(sites));
        log.receivedXSiteClusterView(view);
    }
    @Override
    public Set<String> get() {
        return Collections.unmodifiableSet(this.view);
    }
}

We would set the RouteStatusListener following this line from JChannelFactory:
https://github.com/infinispan/infinispan/blob/master/server/integration/jgroups/src/main/java/org/infinispan/server/jgroups/JChannelFactory.java#L136
e.g.
RELAY2 relay = new RELAY2().site(localSite);
relay.setRouteStatusListener(new DefaultRouteStatusListener());

JGroupsTransport can then obtain the site view via:
@Override
public Set<String> getSitesView() {
    RELAY2 relay = channel.getProtocolStack().findProtocol(RELAY2.class);
    RouteStatusListener listener = (relay != null) ?
relay.getRouteStatusListener() : null;
    return (listener instanceof Supplier) ? ((Supplier<Set<String>>)
listener).get() : null;
}

On Thu, Jan 12, 2017 at 6:10 AM, Galder Zamarre?o <galder at redhat.com> wrote:
> Hi Paul,
>
> Sorry to bother you again :)
>
> Re: https://issues.jboss.org/browse/ISPN-7230 & https://issues.jboss.org/browse/ISPN-7231
>
> The aim of these JIRAs is to have a x-site view exposed as an INFO message as well as JMX and DMR operation.
>
> To do that, following Bela's advice, I've extracted RELAY2 protocol of the stack and on Infinispan's JGroupsTransport start() method, call setRouteStatusListener() with a relay RouteStatusListener implementation that allows the x-site view to be tracked [1].
>
> This works fine in library mode, but in server, on startup setRouteStatusListener() sometimes gets called after the Relayer's viewAccepted() method has been already called (which is the one that calls into RouteStatusListener). These means that the inital x-site view might not be registered.
>
> So, what would be the correct place to add the setRouteStatusListener() call so that all views are captured? Or given how the server works, do I need to avoid using setRouteStatusListener() and use my own, Infinispan level, listener for tracking somehow?
>
> Cheers,
>
> [1] https://github.com/galderz/infinispan/blob/t_7230/core/src/main/java/org/infinispan/remoting/transport/jgroups/JGroupsTransport.java#L926
> --
> Galder Zamarre?o
> Infinispan, Red Hat
>


From ttarrant at redhat.com  Mon Jan 16 10:58:22 2017
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Mon, 16 Jan 2017 16:58:22 +0100
Subject: [infinispan-dev] Weekly IRC Meeting Logs 2016-01-16
Message-ID: <d9043db4-324f-4ba0-05c0-8de7c2aa0a60@redhat.com>

Dear all,

please find the logs to this week's IRC meeting here:

http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2017/infinispan.2017-01-16-15.00.log.html

Tristan
-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat

From galder at redhat.com  Tue Jan 17 02:48:41 2017
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Tue, 17 Jan 2017 08:48:41 +0100
Subject: [infinispan-dev] XSite route status listener in server -
	ISPN-7230/ISPN-7231
In-Reply-To: <CAF5qqoMiSBMtNBvffxaDN+GyhygzL9Peeh=3vhSFnc+cPETznw@mail.gmail.com>
References: <12CFFDB8-000E-4C55-87FF-EC6FB90422E2@redhat.com>
	<CAF5qqoMiSBMtNBvffxaDN+GyhygzL9Peeh=3vhSFnc+cPETznw@mail.gmail.com>
Message-ID: <01FD2C95-9EC0-4CA3-83A6-5604B13C084D@redhat.com>

Hey Paul,

Thanks for the suggestion. I'll give it a go and let you know how it goes.

Btw, if the suggestion works, would it make sense to add it to WF too?

Cheers
--
Galder Zamarre?o
Infinispan, Red Hat

> On 14 Jan 2017, at 19:22, Paul Ferraro <paul.ferraro at redhat.com> wrote:
> 
> Hi Galder,
> 
> Sorry for the delay.  For server-mode, we'd need to set the
> RouteStatusListener in the jgroups subsystem before the RELAY2
> protocol is initialized.
> e.g.
> public class DefaultRouteStatusListener implements
> RouteStatusListener, Supplier<Set<String>> {
>   private final Set<String> view = new ConcurrentSkipListSet<>();
>   @Override
>   public void sitesUp(String... sites) {
>       this.view.addAll(Arrays.asList(sites));
>       log.receivedXSiteClusterView(view);
>   }
>   @Override
>   public void sitesDown(String... sites) {
>       this.view.removeAll(Arrays.asList(sites));
>       log.receivedXSiteClusterView(view);
>   }
>   @Override
>   public Set<String> get() {
>       return Collections.unmodifiableSet(this.view);
>   }
> }
> 
> We would set the RouteStatusListener following this line from JChannelFactory:
> https://github.com/infinispan/infinispan/blob/master/server/integration/jgroups/src/main/java/org/infinispan/server/jgroups/JChannelFactory.java#L136
> e.g.
> RELAY2 relay = new RELAY2().site(localSite);
> relay.setRouteStatusListener(new DefaultRouteStatusListener());
> 
> JGroupsTransport can then obtain the site view via:
> @Override
> public Set<String> getSitesView() {
>   RELAY2 relay = channel.getProtocolStack().findProtocol(RELAY2.class);
>   RouteStatusListener listener = (relay != null) ?
> relay.getRouteStatusListener() : null;
>   return (listener instanceof Supplier) ? ((Supplier<Set<String>>)
> listener).get() : null;
> }
> 
> On Thu, Jan 12, 2017 at 6:10 AM, Galder Zamarre?o <galder at redhat.com> wrote:
>> Hi Paul,
>> 
>> Sorry to bother you again :)
>> 
>> Re: https://issues.jboss.org/browse/ISPN-7230 & https://issues.jboss.org/browse/ISPN-7231
>> 
>> The aim of these JIRAs is to have a x-site view exposed as an INFO message as well as JMX and DMR operation.
>> 
>> To do that, following Bela's advice, I've extracted RELAY2 protocol of the stack and on Infinispan's JGroupsTransport start() method, call setRouteStatusListener() with a relay RouteStatusListener implementation that allows the x-site view to be tracked [1].
>> 
>> This works fine in library mode, but in server, on startup setRouteStatusListener() sometimes gets called after the Relayer's viewAccepted() method has been already called (which is the one that calls into RouteStatusListener). These means that the inital x-site view might not be registered.
>> 
>> So, what would be the correct place to add the setRouteStatusListener() call so that all views are captured? Or given how the server works, do I need to avoid using setRouteStatusListener() and use my own, Infinispan level, listener for tracking somehow?
>> 
>> Cheers,
>> 
>> [1] https://github.com/galderz/infinispan/blob/t_7230/core/src/main/java/org/infinispan/remoting/transport/jgroups/JGroupsTransport.java#L926
>> --
>> Galder Zamarre?o
>> Infinispan, Red Hat
>> 



From slaskawi at redhat.com  Thu Jan 19 02:39:27 2017
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Thu, 19 Jan 2017 08:39:27 +0100
Subject: [infinispan-dev] Infinispan Managment Console versioning and
	releases
In-Reply-To: <CAA9R9O4m2rq7A74FwMNh32NwDf1YiWj0hG+uX_Ds9nb6y5Wn+g@mail.gmail.com>
References: <CAA9R9O4m2rq7A74FwMNh32NwDf1YiWj0hG+uX_Ds9nb6y5Wn+g@mail.gmail.com>
Message-ID: <CAA9R9O6k-hZMp0E-ERs7jO2Q7NptxJq_COJhVgCGhsmVmLGmjQ@mail.gmail.com>

Just a friendly reminder...

@Vladimir, @Ryan.... yes, I'm looking at YOU :)

On Fri, Dec 16, 2016 at 9:22 AM, Sebastian Laskawiec <slaskawi at redhat.com>
wrote:

> Hey guys,
>
> A while ago was been talking with Ryan and Tristan about automated
> releases for Infinispan Management Console. I would like to send the main
> point for wider audience.
>
> Long story short, we were considering different versioning schemes, such
> as X.Y.Z.SHA1 or using Z as an auto-increment counter for console releases.
> The main problem we were trying to solve was how to release the management
> console more often.
>
> I would like to propose different approach - Let's stick with a standard
> versioning (X.Y.Z.[Alpha|Beta|Fina] for releases and X.Y.Z-SNAPSHOT for
> ongoing work). Then we need to embed SHA1 into the MANIFEST.MF to increase
> tracability (in other words, here I have an Infinispan build and I need to
> know which SHA1 was used to build the console). SNAPSHOTs will be pushed
> into JBoss Repository [1] after each commit. Infinispan master branch will
> have a SNAPSHOT dependency to the console. The tricky part are releases.
> Well, at first we need to release the console (I hope we will automate that
> in Team City). Then we can use the version plugin [2] to update the
> Infinispan source code to the latest version of the console. Finally, we
> can release the Infinispan. As a long-term goal, everything will happen
> inside a single staging repository in Nexus (but that's a long-term goal...
> first let get this running).
>
> If you agree to my proposal, please change the version in the console into
> 9.0.0-SNAPSHOT and retrigger [3] (automated builds are disabled at the
> moment). Next, I would kindly ask to look into the build logs [4][5] and
> give me a hint how to fix it. The NPM plugin is failing with some weird
> error. Once we are done with that, I will configure a Pull Request builder
> and release job.
>
> Thanks
> Sebastian
>
> [1] https://repository.jboss.org/nexus/content/repositories/snapshots/
> [2] http://www.mojohaus.org/versions-maven-plugin/
> [3] http://ci.infinispan.org/viewType.html?buildTypeId=Infinispan_
> ManagmentConsoleMasterHotspotJdk8
> [4] http://ci.infinispan.org/viewLog.html?buildId=46542&
> buildTypeId=Infinispan_ManagmentConsoleMasterHotspotJdk8&tab=buildLog
> [5] http://ci.infinispan.org/viewLog.html?buildId=46543&
> buildTypeId=Infinispan_ManagmentConsoleMasterHotspotJdk8&tab=buildLog
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170119/b7542045/attachment.html 

From vblagoje at redhat.com  Thu Jan 19 09:00:06 2017
From: vblagoje at redhat.com (Vladimir Blagojevic)
Date: Thu, 19 Jan 2017 09:00:06 -0500
Subject: [infinispan-dev] Infinispan Managment Console versioning and
 releases
In-Reply-To: <CAA9R9O6k-hZMp0E-ERs7jO2Q7NptxJq_COJhVgCGhsmVmLGmjQ@mail.gmail.com>
References: <CAA9R9O4m2rq7A74FwMNh32NwDf1YiWj0hG+uX_Ds9nb6y5Wn+g@mail.gmail.com>
	<CAA9R9O6k-hZMp0E-ERs7jO2Q7NptxJq_COJhVgCGhsmVmLGmjQ@mail.gmail.com>
Message-ID: <f51744c1-d93e-0303-4743-2b21ec0e7186@redhat.com>

Sebastian,

Seems like you solved everything already on your own. Do you still have 
build issues?

Vladimir
On 2017-01-19 2:39 AM, Sebastian Laskawiec wrote:
> Just a friendly reminder...
>
> @Vladimir, @Ryan.... yes, I'm looking at YOU :)
>
> On Fri, Dec 16, 2016 at 9:22 AM, Sebastian Laskawiec 
> <slaskawi at redhat.com <mailto:slaskawi at redhat.com>> wrote:
>
>     Hey guys,
>
>     A while ago was been talking with Ryan and Tristan about automated
>     releases for Infinispan Management Console. I would like to send
>     the main point for wider audience.
>
>     Long story short, we were considering different versioning
>     schemes, such as X.Y.Z.SHA1 or using Z as an auto-increment
>     counter for console releases. The main problem we were trying to
>     solve was how to release the management console more often.
>
>     I would like to propose different approach - Let's stick with a
>     standard versioning (X.Y.Z.[Alpha|Beta|Fina] for releases and
>     X.Y.Z-SNAPSHOT for ongoing work). Then we need to embed SHA1 into
>     the MANIFEST.MF to increase tracability (in other words, here I
>     have an Infinispan build and I need to know which SHA1 was used to
>     build the console). SNAPSHOTs will be pushed into JBoss Repository
>     [1] after each commit. Infinispan master branch will have a
>     SNAPSHOT dependency to the console. The tricky part are releases.
>     Well, at first we need to release the console (I hope we will
>     automate that in Team City). Then we can use the version plugin
>     [2] to update the Infinispan source code to the latest version of
>     the console. Finally, we can release the Infinispan. As a
>     long-term goal, everything will happen inside a single staging
>     repository in Nexus (but that's a long-term goal... first let get
>     this running).
>
>     If you agree to my proposal, please change the version in the
>     console into 9.0.0-SNAPSHOT and retrigger [3] (automated builds
>     are disabled at the moment). Next, I would kindly ask to look into
>     the build logs [4][5] and give me a hint how to fix it. The NPM
>     plugin is failing with some weird error. Once we are done with
>     that, I will configure a Pull Request builder and release job.
>
>     Thanks
>     Sebastian
>
>     [1]
>     https://repository.jboss.org/nexus/content/repositories/snapshots/
>     <https://repository.jboss.org/nexus/content/repositories/snapshots/>
>     [2] http://www.mojohaus.org/versions-maven-plugin/
>     <http://www.mojohaus.org/versions-maven-plugin/>
>     [3]
>     http://ci.infinispan.org/viewType.html?buildTypeId=Infinispan_ManagmentConsoleMasterHotspotJdk8
>     <http://ci.infinispan.org/viewType.html?buildTypeId=Infinispan_ManagmentConsoleMasterHotspotJdk8>
>     [4]
>     http://ci.infinispan.org/viewLog.html?buildId=46542&buildTypeId=Infinispan_ManagmentConsoleMasterHotspotJdk8&tab=buildLog
>     <http://ci.infinispan.org/viewLog.html?buildId=46542&buildTypeId=Infinispan_ManagmentConsoleMasterHotspotJdk8&tab=buildLog>
>     [5]
>     http://ci.infinispan.org/viewLog.html?buildId=46543&buildTypeId=Infinispan_ManagmentConsoleMasterHotspotJdk8&tab=buildLog
>     <http://ci.infinispan.org/viewLog.html?buildId=46543&buildTypeId=Infinispan_ManagmentConsoleMasterHotspotJdk8&tab=buildLog>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170119/11c8b5ed/attachment.html 

From slaskawi at redhat.com  Thu Jan 19 09:03:26 2017
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Thu, 19 Jan 2017 15:03:26 +0100
Subject: [infinispan-dev] Infinispan Managment Console versioning and
	releases
In-Reply-To: <f51744c1-d93e-0303-4743-2b21ec0e7186@redhat.com>
References: <CAA9R9O4m2rq7A74FwMNh32NwDf1YiWj0hG+uX_Ds9nb6y5Wn+g@mail.gmail.com>
	<CAA9R9O6k-hZMp0E-ERs7jO2Q7NptxJq_COJhVgCGhsmVmLGmjQ@mail.gmail.com>
	<f51744c1-d93e-0303-4743-2b21ec0e7186@redhat.com>
Message-ID: <CAA9R9O6dwV_rw1Bs+oEE=uuSS7XFvKAmjnFNxEV=Qc6zDDRYXA@mail.gmail.com>

Yes. Please trigger this CI job:
http://ci.infinispan.org/viewType.html?buildTypeId=Infinispan_ManagmentConsoleMasterHotspotJdk8

On Thu, Jan 19, 2017 at 3:00 PM, Vladimir Blagojevic <vblagoje at redhat.com>
wrote:

> Sebastian,
>
> Seems like you solved everything already on your own. Do you still have
> build issues?
>
> Vladimir
>
> On 2017-01-19 2:39 AM, Sebastian Laskawiec wrote:
>
> Just a friendly reminder...
>
> @Vladimir, @Ryan.... yes, I'm looking at YOU :)
>
> On Fri, Dec 16, 2016 at 9:22 AM, Sebastian Laskawiec <slaskawi at redhat.com>
> wrote:
>
>> Hey guys,
>>
>> A while ago was been talking with Ryan and Tristan about automated
>> releases for Infinispan Management Console. I would like to send the main
>> point for wider audience.
>>
>> Long story short, we were considering different versioning schemes, such
>> as X.Y.Z.SHA1 or using Z as an auto-increment counter for console releases.
>> The main problem we were trying to solve was how to release the management
>> console more often.
>>
>> I would like to propose different approach - Let's stick with a standard
>> versioning (X.Y.Z.[Alpha|Beta|Fina] for releases and X.Y.Z-SNAPSHOT for
>> ongoing work). Then we need to embed SHA1 into the MANIFEST.MF to increase
>> tracability (in other words, here I have an Infinispan build and I need to
>> know which SHA1 was used to build the console). SNAPSHOTs will be pushed
>> into JBoss Repository [1] after each commit. Infinispan master branch will
>> have a SNAPSHOT dependency to the console. The tricky part are releases.
>> Well, at first we need to release the console (I hope we will automate that
>> in Team City). Then we can use the version plugin [2] to update the
>> Infinispan source code to the latest version of the console. Finally, we
>> can release the Infinispan. As a long-term goal, everything will happen
>> inside a single staging repository in Nexus (but that's a long-term goal...
>> first let get this running).
>>
>> If you agree to my proposal, please change the version in the console
>> into 9.0.0-SNAPSHOT and retrigger [3] (automated builds are disabled at the
>> moment). Next, I would kindly ask to look into the build logs [4][5] and
>> give me a hint how to fix it. The NPM plugin is failing with some weird
>> error. Once we are done with that, I will configure a Pull Request builder
>> and release job.
>>
>> Thanks
>> Sebastian
>>
>> [1] https://repository.jboss.org/nexus/content/repositories/snapshots/
>> [2] http://www.mojohaus.org/versions-maven-plugin/
>> [3] http://ci.infinispan.org/viewType.html?buildTypeId=Infin
>> ispan_ManagmentConsoleMasterHotspotJdk8
>> [4] http://ci.infinispan.org/viewLog.html?buildId=46542&buil
>> dTypeId=Infinispan_ManagmentConsoleMasterHotspotJdk8&tab=buildLog
>> [5] http://ci.infinispan.org/viewLog.html?buildId=46543&buil
>> dTypeId=Infinispan_ManagmentConsoleMasterHotspotJdk8&tab=buildLog
>>
>
>
>
> _______________________________________________
> infinispan-dev mailing listinfinispan-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170119/9025a452/attachment-0001.html 

From rvansa at redhat.com  Thu Jan 19 11:11:46 2017
From: rvansa at redhat.com (Radim Vansa)
Date: Thu, 19 Jan 2017 17:11:46 +0100
Subject: [infinispan-dev] State transfer-related terms
Message-ID: <095d786e-1fa7-761c-48f7-2653e6a67b65@redhat.com>

Hi,

I've started (again) working on ISPN-5021 [1], and I'd like to get some 
common agreement on few terms. So below I summarize my understanding (or 
misunderstanding) of these, please state you opinion, thinking a bit 
more generally.

State transfer: whole process beginning with some ST-related event = 
node being detected to crash/sending join or leave request, and ending 
when this event is processed. When another event happens, the current ST 
can either be finished or canceled and then *another* ST can begin. 
State transfer is a cluster-wide process, though it cannot be started 
and ended absolutely simultaneously.

Rebalance: one phase of ST, when the data transfer occurs.

Data rehash: this is a bit painful point: we have DataRehashEvent where 
the name suggest that it is related rather to rebalance, but currently 
it fires when CacheTopology.getPendingCH() == null (that means when ST 
is complete), and the event itself also looks more like it should be 
fired at the end of state transfer. If we have something more to do 
after the rebalance, I am not sure how useful is firing that just 
because all data has been transferred (but for example before old data 
has been wiped out). Should I add another StateTransferEvent event (and 
appropriate listeners)? That would break the compatibility with tightly 
related implementations...

WDYT?

Radim

[1] https://issues.jboss.org/browse/ISPN-5021


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From mudokonman at gmail.com  Thu Jan 19 17:14:42 2017
From: mudokonman at gmail.com (William Burns)
Date: Thu, 19 Jan 2017 22:14:42 +0000
Subject: [infinispan-dev] State transfer-related terms
In-Reply-To: <095d786e-1fa7-761c-48f7-2653e6a67b65@redhat.com>
References: <095d786e-1fa7-761c-48f7-2653e6a67b65@redhat.com>
Message-ID: <CA+YCuUOJ8cnzNkzHVGxfSgdVVe6fRfeBf2Z-q1izCAsxvUS_dg@mail.gmail.com>

On Thu, Jan 19, 2017 at 11:13 AM Radim Vansa <rvansa at redhat.com> wrote:

> Hi,
>
> I've started (again) working on ISPN-5021 [1], and I'd like to get some
> common agreement on few terms. So below I summarize my understanding (or
> misunderstanding) of these, please state you opinion, thinking a bit
> more generally.
>
> State transfer: whole process beginning with some ST-related event =
> node being detected to crash/sending join or leave request, and ending
> when this event is processed. When another event happens, the current ST
> can either be finished or canceled and then *another* ST can begin.
> State transfer is a cluster-wide process, though it cannot be started
> and ended absolutely simultaneously.
>
> Rebalance: one phase of ST, when the data transfer occurs.
>
> Data rehash: this is a bit painful point: we have DataRehashEvent where
> the name suggest that it is related rather to rebalance, but currently
> it fires when CacheTopology.getPendingCH() == null (that means when ST
> is complete), and the event itself also looks more like it should be
> fired at the end of state transfer. If we have something more to do
> after the rebalance, I am not sure how useful is firing that just
> because all data has been transferred (but for example before old data
> has been wiped out). Should I add another StateTransferEvent event (and
> appropriate listeners)? That would break the compatibility with tightly
> related implementations...
>

The stream retry mechanism currently uses DataRehashedEvent. It is
beneficial but not required for it to be notified immediately after all
entries have been transferred but before any have been removed. This
shortens the window for when a stream operation is retried since it has to
be sure that all entries for a given segment are present, but we don't care
if entries for a non owned segment are present. But the good thing is that
the code shouldn't require much work at all to be changed if we needed to.

I am personally not keen on having another event that is like
DataRehashedEvent, but only signifies entries were removed. It seems a bit
confusing. Is there any usage you were thinking that required the old
entries to be removed that could benefit from the new event/listeners?


>
> WDYT?
>
> Radim
>
> [1] https://issues.jboss.org/browse/ISPN-5021
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170119/fa2755b8/attachment.html 

From mudokonman at gmail.com  Fri Jan 20 13:05:25 2017
From: mudokonman at gmail.com (William Burns)
Date: Fri, 20 Jan 2017 18:05:25 +0000
Subject: [infinispan-dev] HotRod Server Test Decoder Perf Changes
Message-ID: <CA+YCuUMzb-=N8i+X+QZHgb8XohQ6oEQH24j5H+nK4Q5su3EF7Q@mail.gmail.com>

I just wanted to take a quick sec to make people aware of a recent change
to the HotRodTestingUtils class.  If you are utilizing this class to create
your hotrod server you may need to tweak how you are calling it [1].

What this change does is install an additional decoder which only sends 1
byte at a time down the netty stack.  This is important for testing as it
will find any replay issues we have with our decoder.  The drawback is that
this slows down decoding a little bit.

For those of you who don't wish to have this enabled, such as when running
performance tests, there is an overloaded method that does just that! [2]
Just make sure you pass true as the argument to the perf argument and
everything should run as it was before the change.

 - Will

[1]
https://github.com/infinispan/infinispan/commit/2cfc205626837ff675033635cfacc67f7638b537#diff-fb3498f5315ea1259f86b8099c29661a
[2]
https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/test/scala/org/infinispan/server/hotrod/test/HotRodTestingUtil.scala#L112
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170120/cbc6e960/attachment.html 

From rvansa at redhat.com  Mon Jan 23 04:13:34 2017
From: rvansa at redhat.com (Radim Vansa)
Date: Mon, 23 Jan 2017 10:13:34 +0100
Subject: [infinispan-dev] State transfer-related terms
In-Reply-To: <CA+YCuUOJ8cnzNkzHVGxfSgdVVe6fRfeBf2Z-q1izCAsxvUS_dg@mail.gmail.com>
References: <095d786e-1fa7-761c-48f7-2653e6a67b65@redhat.com>
	<CA+YCuUOJ8cnzNkzHVGxfSgdVVe6fRfeBf2Z-q1izCAsxvUS_dg@mail.gmail.com>
Message-ID: <45e5ce1f-b253-7402-2203-b26d52bf09b2@redhat.com>

On 01/19/2017 11:14 PM, William Burns wrote:
>
>
> On Thu, Jan 19, 2017 at 11:13 AM Radim Vansa <rvansa at redhat.com 
> <mailto:rvansa at redhat.com>> wrote:
>
>     Hi,
>
>     I've started (again) working on ISPN-5021 [1], and I'd like to get
>     some
>     common agreement on few terms. So below I summarize my
>     understanding (or
>     misunderstanding) of these, please state you opinion, thinking a bit
>     more generally.
>
>     State transfer: whole process beginning with some ST-related event =
>     node being detected to crash/sending join or leave request, and ending
>     when this event is processed. When another event happens, the
>     current ST
>     can either be finished or canceled and then *another* ST can begin.
>     State transfer is a cluster-wide process, though it cannot be started
>     and ended absolutely simultaneously.
>
>     Rebalance: one phase of ST, when the data transfer occurs.
>
>     Data rehash: this is a bit painful point: we have DataRehashEvent
>     where
>     the name suggest that it is related rather to rebalance, but currently
>     it fires when CacheTopology.getPendingCH() == null (that means when ST
>     is complete), and the event itself also looks more like it should be
>     fired at the end of state transfer. If we have something more to do
>     after the rebalance, I am not sure how useful is firing that just
>     because all data has been transferred (but for example before old data
>     has been wiped out). Should I add another StateTransferEvent event
>     (and
>     appropriate listeners)? That would break the compatibility with
>     tightly
>     related implementations...
>
>
> The stream retry mechanism currently uses DataRehashedEvent. It is 
> beneficial but not required for it to be notified immediately after 
> all entries have been transferred but before any have been removed. 
> This shortens the window for when a stream operation is retried since 
> it has to be sure that all entries for a given segment are present, 
> but we don't care if entries for a non owned segment are present. But 
> the good thing is that the code shouldn't require much work at all to 
> be changed if we needed to.
>
> I am personally not keen on having another event that is like 
> DataRehashedEvent, but only signifies entries were removed. It seems a 
> bit confusing. Is there any usage you were thinking that required the 
> old entries to be removed that could benefit from the new event/listeners?

Okay, so from streams POV, DataRehashedEvent should mark rebalance, and 
be fired once all incoming segments arrive. The implementation does not 
rely on pendingCH being null when the event is fired, right? I like such 
definition as "data rehash" sounds like moving data around.

I can see StateTransferEvent being useful when downscaling the cluster, 
and you want to remove one node at a time (as the current leave is not 
too graceful and calling cacheManager.stop() does not wait until ST 
completes).

R.

>
>     WDYT?
>
>     Radim
>
>     [1] https://issues.jboss.org/browse/ISPN-5021
>
>
>     --
>     Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>>
>     JBoss Performance Team
>
>     _______________________________________________
>     infinispan-dev mailing list
>     infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From remerson at redhat.com  Mon Jan 23 12:27:53 2017
From: remerson at redhat.com (Ryan Emerson)
Date: Mon, 23 Jan 2017 12:27:53 -0500 (EST)
Subject: [infinispan-dev] JDBC Blog Post
In-Reply-To: <1932522637.11897002.1485192353317.JavaMail.zimbra@redhat.com>
Message-ID: <295420559.11898107.1485192473109.JavaMail.zimbra@redhat.com>

Hi Everyone,

I have published a new blog post [1] that gives a brief overview on some of the JDBC improvements/optimisations introduced in 9.x.

[1] http://blog.infinispan.org/2017/01/9x-jdbc-store-improvements.html

Cheers
Ryan

From mudokonman at gmail.com  Mon Jan 23 17:21:26 2017
From: mudokonman at gmail.com (William Burns)
Date: Mon, 23 Jan 2017 22:21:26 +0000
Subject: [infinispan-dev] Data Container Changes Part 1
In-Reply-To: <CA+YCuUOYUWvqhgDBWsA4-y10NbKnEHV+V+E+iLuzM=z4QSecXg@mail.gmail.com>
References: <CA+YCuUOYUWvqhgDBWsA4-y10NbKnEHV+V+E+iLuzM=z4QSecXg@mail.gmail.com>
Message-ID: <CA+YCuUOGaUO3e11XWsk6ZoM+AAOrS6KtFaWyVJDWuAa7sfn+Zg@mail.gmail.com>

I just wanted to let you all know that Part 2 of Data Container changes is
now ready.  Go ahead and check it at out at our new feature that we are
very excited about at [2] !

[2] http://blog.infinispan.org/2017/01/data-container-changes-part-2.html

On Mon, Dec 19, 2016 at 4:10 PM William Burns <mudokonman at gmail.com> wrote:

> Check out some of the new changes to the Data Container in Infinispan 9.0.
> Beta 1 [1].  Part 2 will be probably after Holiday break.
>
> [1] http://blog.infinispan.org/2016/12/data-container-changes-part-1.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170123/c7ec6350/attachment-0001.html 

From dan.berindei at gmail.com  Tue Jan 24 03:22:57 2017
From: dan.berindei at gmail.com (Dan Berindei)
Date: Tue, 24 Jan 2017 10:22:57 +0200
Subject: [infinispan-dev] Data Container Changes Part 1
In-Reply-To: <CA+YCuUOGaUO3e11XWsk6ZoM+AAOrS6KtFaWyVJDWuAa7sfn+Zg@mail.gmail.com>
References: <CA+YCuUOYUWvqhgDBWsA4-y10NbKnEHV+V+E+iLuzM=z4QSecXg@mail.gmail.com>
	<CA+YCuUOGaUO3e11XWsk6ZoM+AAOrS6KtFaWyVJDWuAa7sfn+Zg@mail.gmail.com>
Message-ID: <CA+nfvwTss_k-tydxAGdnveLnmZ10aKHb_NshEiwJGod_4MycTg@mail.gmail.com>

I have some small comments on the blog post. I didn't read almost any
of the code, so I guess I match the experience of a typical reader :)

1. Can you really use eviction="COUNT", like for the other memory types?
2. The address-count name is a bit odd, as it invites comparison with
the native pointers: are our addresses ints on 32-bit and longs on
64-bit, do we have something similar to compressed oops etc. I'd
rather call it initialCapacity, like the HashMap constructor argument,
to allow us more wiggle-room in the implementation. E.g. we don't need
the entry in the table to be just a "next" pointer, it could be a
proper entry with a pointer to the key and maybe even a hash code.
3. The details on the way we do the locking and the actual number of
ReadWriteLocks we use also sound like they could become out of date
quickly. I'd put these and the memory overhead in a "Implementation
Details" section.
4. Reading the code, it looks like address-count is also rounded up to
the next power of 2, I think that should be mentioned here (and in the
javadoc/schema).
5. Does bounded off-heap need extra locking?
6. 36 bytes for "an additional address pointer" seems a bit excessive
:) Here too, I'd rather give an estimate of the overhead instead of
trying to explain exactly what we're using those bytes for.

Cheers
Dan



On Tue, Jan 24, 2017 at 12:21 AM, William Burns <mudokonman at gmail.com> wrote:
> I just wanted to let you all know that Part 2 of Data Container changes is
> now ready.  Go ahead and check it at out at our new feature that we are very
> excited about at [2] !
>
> [2] http://blog.infinispan.org/2017/01/data-container-changes-part-2.html
>
> On Mon, Dec 19, 2016 at 4:10 PM William Burns <mudokonman at gmail.com> wrote:
>>
>> Check out some of the new changes to the Data Container in Infinispan 9.0.
>> Beta 1 [1].  Part 2 will be probably after Holiday break.
>>
>> [1] http://blog.infinispan.org/2016/12/data-container-changes-part-1.html
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

From slaskawi at redhat.com  Tue Jan 24 04:28:12 2017
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Tue, 24 Jan 2017 10:28:12 +0100
Subject: [infinispan-dev] Lots of exceptions in tests
Message-ID: <CAA9R9O66W+s-j4feJRZfSJXRaLaeJmh0fmF+Z18AwqrdJUjPbQ@mail.gmail.com>

Hey guys!

Just wanted to point out there we have lots and lots of error messages in
TC logs [1]:
[18:48:00] : [Step 2/5] org.infinispan.commons.CacheException:
java.lang.IllegalStateException: channel is not connected
[18:48:00] : [Step 2/5] at
org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.rethrowAsCacheException(CommandAwareRpcDispatcher.java:134)
[18:48:00] : [Step 2/5] at
org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:128)
[18:48:00] : [Step 2/5] at
org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotelyAsync(JGroupsTransport.java:614)

Thanks,
Sebastian


[1]
http://ci.infinispan.org/viewLog.html?buildId=48357&buildTypeId=bt9&tab=buildLog#_focus=29
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170124/98335bc9/attachment.html 

From galder at redhat.com  Tue Jan 24 08:57:26 2017
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Tue, 24 Jan 2017 14:57:26 +0100
Subject: [infinispan-dev] Infinispan 9.0.0.Beta2 and 8.2.6.Final are out!
Message-ID: <F6ABB431-95CB-43C9-9077-845D9E0A899E@redhat.com>

You can read all about these releases here:
http://blog.infinispan.org/2017/01/infinispan-900beta2-and-826final-are-out.html

Cheers,
--
Galder Zamarre?o
Infinispan, Red Hat



From mudokonman at gmail.com  Tue Jan 24 09:27:08 2017
From: mudokonman at gmail.com (William Burns)
Date: Tue, 24 Jan 2017 14:27:08 +0000
Subject: [infinispan-dev] Data Container Changes Part 1
In-Reply-To: <CA+nfvwTss_k-tydxAGdnveLnmZ10aKHb_NshEiwJGod_4MycTg@mail.gmail.com>
References: <CA+YCuUOYUWvqhgDBWsA4-y10NbKnEHV+V+E+iLuzM=z4QSecXg@mail.gmail.com>
	<CA+YCuUOGaUO3e11XWsk6ZoM+AAOrS6KtFaWyVJDWuAa7sfn+Zg@mail.gmail.com>
	<CA+nfvwTss_k-tydxAGdnveLnmZ10aKHb_NshEiwJGod_4MycTg@mail.gmail.com>
Message-ID: <CA+YCuUNhEvhew3OGzs=j5t0m4_bGXrnd9o+grqfXUS6b+6H5WQ@mail.gmail.com>

On Tue, Jan 24, 2017 at 3:23 AM Dan Berindei <dan.berindei at gmail.com> wrote:

> I have some small comments on the blog post. I didn't read almost any
> of the code, so I guess I match the experience of a typical reader :)
>
> 1. Can you really use eviction="COUNT", like for the other memory types?
>

Yes, I was hoping people would assume that from me saying it isn't
different.  But I can clearly state it.


> 2. The address-count name is a bit odd, as it invites comparison with
> the native pointers: are our addresses ints on 32-bit and longs on
> 64-bit, do we have something similar to compressed oops etc. I'd
> rather call it initialCapacity, like the HashMap constructor argument,
> to allow us more wiggle-room in the implementation. E.g. we don't need
> the entry in the table to be just a "next" pointer, it could be a
> proper entry with a pointer to the key and maybe even a hash code.
>

It is a bunch of longs that each point to an entry object off heap.  I
would love to have compressed oops, but we are kinda at the mercy of malloc
so there is no way to guarantee where the addresses will be allocated at.


> 3. The details on the way we do the locking and the actual number of
> ReadWriteLocks we use also sound like they could become out of date
> quickly. I'd put these and the memory overhead in a "Implementation
> Details" section.
>

Sure can.  The way this works is pretty intrinsic to the current design,
since it utilizes these known facts to iterate over the entries with as
minimal locking as possible.


> 4. Reading the code, it looks like address-count is also rounded up to
> the next power of 2, I think that should be mentioned here (and in the
> javadoc/schema).
>

I actually had it in here, but in my many edits it was lost.  I will add it
back in.  It is actually in the javadocs already however it was missed in
the schema, I will add it there.


> 5. Does bounded off-heap need extra locking?
>

It does I mention in the overhead it requires an additional lock.  I was
trying not to go into super details.


> 6. 36 bytes for "an additional address pointer" seems a bit excessive
> :) Here too, I'd rather give an estimate of the overhead instead of
> trying to explain exactly what we're using those bytes for.
>

I can clarify it obviously isn't an additional address pointer.  I was
trying not to be specific with the usage but rather give an approximation
of the overhead instead.

As you may have noticed I was torn with how specific to be. Originally I
had the document much more detailed about how things worked, but I tried to
pair it down. I was thinking maybe if we thought there was interest I could
go into more details in a future blog post.


>
> Cheers
> Dan
>
>
>
> On Tue, Jan 24, 2017 at 12:21 AM, William Burns <mudokonman at gmail.com>
> wrote:
> > I just wanted to let you all know that Part 2 of Data Container changes
> is
> > now ready.  Go ahead and check it at out at our new feature that we are
> very
> > excited about at [2] !
> >
> > [2]
> http://blog.infinispan.org/2017/01/data-container-changes-part-2.html
> >
> > On Mon, Dec 19, 2016 at 4:10 PM William Burns <mudokonman at gmail.com>
> wrote:
> >>
> >> Check out some of the new changes to the Data Container in Infinispan
> 9.0.
> >> Beta 1 [1].  Part 2 will be probably after Holiday break.
> >>
> >> [1]
> http://blog.infinispan.org/2016/12/data-container-changes-part-1.html
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170124/e82dd1fd/attachment.html 

From mudokonman at gmail.com  Tue Jan 24 09:44:24 2017
From: mudokonman at gmail.com (William Burns)
Date: Tue, 24 Jan 2017 14:44:24 +0000
Subject: [infinispan-dev] Data Container Changes Part 1
In-Reply-To: <CA+nfvwTss_k-tydxAGdnveLnmZ10aKHb_NshEiwJGod_4MycTg@mail.gmail.com>
References: <CA+YCuUOYUWvqhgDBWsA4-y10NbKnEHV+V+E+iLuzM=z4QSecXg@mail.gmail.com>
	<CA+YCuUOGaUO3e11XWsk6ZoM+AAOrS6KtFaWyVJDWuAa7sfn+Zg@mail.gmail.com>
	<CA+nfvwTss_k-tydxAGdnveLnmZ10aKHb_NshEiwJGod_4MycTg@mail.gmail.com>
Message-ID: <CA+YCuUN1f7GkWPX-BifduptcXWRb4YKo0PzF47q1cRRKuhjmGg@mail.gmail.com>

On Tue, Jan 24, 2017 at 3:23 AM Dan Berindei <dan.berindei at gmail.com> wrote:

> I have some small comments on the blog post. I didn't read almost any
> of the code, so I guess I match the experience of a typical reader :)
>
> 1. Can you really use eviction="COUNT", like for the other memory types?
> 2. The address-count name is a bit odd, as it invites comparison with
> the native pointers: are our addresses ints on 32-bit and longs on
> 64-bit, do we have something similar to compressed oops etc. I'd
> rather call it initialCapacity, like the HashMap constructor argument,
>

The only issue I had with an argument name like initialCapacity is then I
would assume the capacity (array) can grow, which it does not. Also the
word just capacity makes me think I can't have more entries than that,
which you can. Did you have any ideas on names or you really like
initialCapacity?


> to allow us more wiggle-room in the implementation. E.g. we don't need
> the entry in the table to be just a "next" pointer, it could be a
> proper entry with a pointer to the key and maybe even a hash code.
>

The problem with it being a proper entry is then the size is unknown, where
as I know the size of all pointers. I can't really allocate a big block for
the pointers then, and I wouldn't want to keep track of all of the pointers
in Java since those would be on heap.


> 3. The details on the way we do the locking and the actual number of
> ReadWriteLocks we use also sound like they could become out of date
> quickly. I'd put these and the memory overhead in a "Implementation
> Details" section.
> 4. Reading the code, it looks like address-count is also rounded up to
> the next power of 2, I think that should be mentioned here (and in the
> javadoc/schema).
> 5. Does bounded off-heap need extra locking?
> 6. 36 bytes for "an additional address pointer" seems a bit excessive
> :) Here too, I'd rather give an estimate of the overhead instead of
> trying to explain exactly what we're using those bytes for.
>
> Cheers
> Dan
>
>
>
> On Tue, Jan 24, 2017 at 12:21 AM, William Burns <mudokonman at gmail.com>
> wrote:
> > I just wanted to let you all know that Part 2 of Data Container changes
> is
> > now ready.  Go ahead and check it at out at our new feature that we are
> very
> > excited about at [2] !
> >
> > [2]
> http://blog.infinispan.org/2017/01/data-container-changes-part-2.html
> >
> > On Mon, Dec 19, 2016 at 4:10 PM William Burns <mudokonman at gmail.com>
> wrote:
> >>
> >> Check out some of the new changes to the Data Container in Infinispan
> 9.0.
> >> Beta 1 [1].  Part 2 will be probably after Holiday break.
> >>
> >> [1]
> http://blog.infinispan.org/2016/12/data-container-changes-part-1.html
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170124/45d3f834/attachment-0001.html 

From ancosen1985 at yahoo.com  Wed Jan 25 05:32:46 2017
From: ancosen1985 at yahoo.com (Andrea Cosentino)
Date: Wed, 25 Jan 2017 10:32:46 +0000 (UTC)
Subject: [infinispan-dev] R: Infinispan 9.0.0.Beta2 and 8.2.6.Final are out!
In-Reply-To: <F6ABB431-95CB-43C9-9077-845D9E0A899E@redhat.com>
References: <F6ABB431-95CB-43C9-9077-845D9E0A899E@redhat.com>
Message-ID: <1722935770.394930.1485340366305@mail.yahoo.com>

Just noticed the artifacts aren't promoted on Maven central.
Cheers,Andrea 
 
  Il mar, 24 gen, 2017 alle 14:57, Galder Zamarre?o<galder at redhat.com> ha scritto:   You can read all about these releases here:
http://blog.infinispan.org/2017/01/infinispan-900beta2-and-826final-are-out.html

Cheers,
--
Galder Zamarre?o
Infinispan, Red Hat


_______________________________________________
infinispan-dev mailing list
infinispan-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170125/0ea0b7c4/attachment.html 

From ancosen1985 at yahoo.com  Wed Jan 25 05:32:46 2017
From: ancosen1985 at yahoo.com (Andrea Cosentino)
Date: Wed, 25 Jan 2017 10:32:46 +0000 (UTC)
Subject: [infinispan-dev] R: Infinispan 9.0.0.Beta2 and 8.2.6.Final are out!
In-Reply-To: <F6ABB431-95CB-43C9-9077-845D9E0A899E@redhat.com>
References: <F6ABB431-95CB-43C9-9077-845D9E0A899E@redhat.com>
Message-ID: <1722935770.394930.1485340366305@mail.yahoo.com>

Just noticed the artifacts aren't promoted on Maven central.
Cheers,Andrea 
 
  Il mar, 24 gen, 2017 alle 14:57, Galder Zamarre?o<galder at redhat.com> ha scritto:   You can read all about these releases here:
http://blog.infinispan.org/2017/01/infinispan-900beta2-and-826final-are-out.html

Cheers,
--
Galder Zamarre?o
Infinispan, Red Hat


_______________________________________________
infinispan-dev mailing list
infinispan-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170125/0ea0b7c4/attachment-0001.html 

From galder at redhat.com  Thu Jan 26 07:24:18 2017
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Thu, 26 Jan 2017 13:24:18 +0100
Subject: [infinispan-dev] REPL async semantics in the context of Hibernate
	2LC
Message-ID: <9AF3DDDD-22BE-489B-AC42-6810EE651E72@redhat.com>

Hi all,

Forgive me if we've discussed this before (I vaguely remember...), but the current async semantics always through me off a bit, let me explain:

I've been working on/off on Hibernate 2LC tutorial that demonstrates how to run 2LC on embedded, Wildfly and Spring set ups, and for each of them, explains how it all works in local vs clustered mode.

One of the sections involves working with queries, updating an entity that's part of the query, and seeing how that query gets re-executed from the db. When an entity is updated, that entity's update timestamp gets updated in a cache, which in a cluster environment is configured with repl async.

If you have two nodes A and B, it was expected that if you updated the entity in node A, you'd want to wait a tiny bit to run the query in node B so that the timestamp update would propagate to node B.

However, recent async semantics work in such way that if you updated the entity in node A and wanted to execute the query in node A, you still might want to add a little delay...

The reason for that is that the logic changes based on whether the ownership of entity type key in the update timestamp cache is in node A or node B. If the owner is node A, the cache is updated directly by the main thread. So you can execute a query on node A immediately after the update and it'll be fine.

However, if the owner is node B, even if the update was done in node A, node A will only be updated asynchronously. So, if after calling an update on node A, you do a query on node A, in this scenario you'd get outdated results for a small period of time. [1]

So, my question here is: can we do anything to make this more predictable from a users perspective? Or is it just not worth doing it? Or is it just a side effect that we must be aware off?

Cheers,

[1] https://gist.github.com/galderz/676f689884969658b01a7695f08dd7a2
--
Galder Zamarre?o
Infinispan, Red Hat



From galder at redhat.com  Thu Jan 26 08:12:00 2017
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Thu, 26 Jan 2017 14:12:00 +0100
Subject: [infinispan-dev] Infinispan 9.0.0.Beta2 and 8.2.6.Final are out!
In-Reply-To: <1722935770.394930.1485340366305@mail.yahoo.com>
References: <F6ABB431-95CB-43C9-9077-845D9E0A899E@redhat.com>
	<1722935770.394930.1485340366305@mail.yahoo.com>
Message-ID: <AFF2D0FA-D666-4D36-B1C4-D59D063FE79D@redhat.com>

Hmmmm, strange... [1]. Maybe it just needs time to sync up? I'm looking into it. 

The artifacts are present in our JBoss repos [2], so you could add the JBoss repos manually in the mean time [3].

Thanks for heads up! :)

Cheers,

[1] https://repo.maven.apache.org/maven2/org/infinispan/infinispan-core/9.0.0.Beta2/
[2] https://repository.jboss.org/nexus/content/groups/public-jboss/org/infinispan/infinispan-core/9.0.0.Beta2/
[3] http://infinispan.org/docs/stable/contributing/contributing.html#maven
--
Galder Zamarre?o
Infinispan, Red Hat

> On 25 Jan 2017, at 11:32, Andrea Cosentino <ancosen1985 at yahoo.com> wrote:
> 
> Just noticed the artifacts aren't promoted on Maven central.
> 
> Cheers,
> Andrea
> 
> Il mar, 24 gen, 2017 alle 14:57, Galder Zamarre?o
> <galder at redhat.com> ha scritto:
> You can read all about these releases here:
> http://blog.infinispan.org/2017/01/infinispan-900beta2-and-826final-are-out.html
> 
> Cheers,
> --
> Galder Zamarre?o
> Infinispan, Red Hat
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev



From ttarrant at redhat.com  Thu Jan 26 08:22:07 2017
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Thu, 26 Jan 2017 14:22:07 +0100
Subject: [infinispan-dev] Infinispan 9.0.0.Beta2 and 8.2.6.Final are out!
In-Reply-To: <AFF2D0FA-D666-4D36-B1C4-D59D063FE79D@redhat.com>
References: <F6ABB431-95CB-43C9-9077-845D9E0A899E@redhat.com>
	<1722935770.394930.1485340366305@mail.yahoo.com>
	<AFF2D0FA-D666-4D36-B1C4-D59D063FE79D@redhat.com>
Message-ID: <f2a004ff-f3b3-d468-94e4-b1b0b0c2155c@redhat.com>

This is being tracked at:

https://issues.sonatype.org/browse/MVNCENTRAL-1512

Tristan

On 26/01/17 14:12, Galder Zamarre?o wrote:
> Hmmmm, strange... [1]. Maybe it just needs time to sync up? I'm looking into it.
>
> The artifacts are present in our JBoss repos [2], so you could add the JBoss repos manually in the mean time [3].
>
> Thanks for heads up! :)
>
> Cheers,
>
> [1] https://repo.maven.apache.org/maven2/org/infinispan/infinispan-core/9.0.0.Beta2/
> [2] https://repository.jboss.org/nexus/content/groups/public-jboss/org/infinispan/infinispan-core/9.0.0.Beta2/
> [3] http://infinispan.org/docs/stable/contributing/contributing.html#maven
> --
> Galder Zamarre?o
> Infinispan, Red Hat
>
>> On 25 Jan 2017, at 11:32, Andrea Cosentino <ancosen1985 at yahoo.com> wrote:
>>
>> Just noticed the artifacts aren't promoted on Maven central.
>>
>> Cheers,
>> Andrea
>>
>> Il mar, 24 gen, 2017 alle 14:57, Galder Zamarre?o
>> <galder at redhat.com> ha scritto:
>> You can read all about these releases here:
>> http://blog.infinispan.org/2017/01/infinispan-900beta2-and-826final-are-out.html
>>
>> Cheers,
>> --
>> Galder Zamarre?o
>> Infinispan, Red Hat
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat

From rvansa at redhat.com  Thu Jan 26 08:30:25 2017
From: rvansa at redhat.com (Radim Vansa)
Date: Thu, 26 Jan 2017 14:30:25 +0100
Subject: [infinispan-dev] REPL async semantics in the context of
 Hibernate 2LC
In-Reply-To: <9AF3DDDD-22BE-489B-AC42-6810EE651E72@redhat.com>
References: <9AF3DDDD-22BE-489B-AC42-6810EE651E72@redhat.com>
Message-ID: <dae76aa0-3bc0-2f92-84f5-d4eab33ce272@redhat.com>

Hi Galder,

I think that this was changed in Infinispan version 5.3 or so :) The 
reason for this is that updates even in async cache are applied in the 
same order on all owners. If you'd update local node A first to X, and 
then asynchronously update the other node B, there could be a concurrent 
update to Y on the other node B, and then the cluster would likely end 
up with A having Y and B having X, without anything eventually resolving 
this. Some locking has to be involved, too, and the algorithm in 5.3 
actually did not allow the values to diverge, but caused a deadlock.

In 2LC, this can be eliminated in some cases, though - e.g. if we do 
putIfAbsents with the same value, it's safe to apply the value locally 
and sent the update asynchronously to the other node. For removals, it's 
safe, too. Therefore, I have recently replaced distribution & locking 
interceptors with 'optimized' version [1][2].

While I am strong adversary of the *_ASYNC modes in general, I think 
that the consistent order of updates should be preserved there. And if 
you do an async put to dist cache, you can't be sure that following read 
will return the value either (and repl is just read-optimized+failure 
resilient case of dist).

Radim

[1] 
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/main/java/org/hibernate/cache/infinispan/access/UnorderedDistributionInterceptor.java
[2] 
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/main/java/org/hibernate/cache/infinispan/access/LockingInterceptor.java

On 01/26/2017 01:24 PM, Galder Zamarre?o wrote:
> Hi all,
>
> Forgive me if we've discussed this before (I vaguely remember...), but the current async semantics always through me off a bit, let me explain:
>
> I've been working on/off on Hibernate 2LC tutorial that demonstrates how to run 2LC on embedded, Wildfly and Spring set ups, and for each of them, explains how it all works in local vs clustered mode.
>
> One of the sections involves working with queries, updating an entity that's part of the query, and seeing how that query gets re-executed from the db. When an entity is updated, that entity's update timestamp gets updated in a cache, which in a cluster environment is configured with repl async.
>
> If you have two nodes A and B, it was expected that if you updated the entity in node A, you'd want to wait a tiny bit to run the query in node B so that the timestamp update would propagate to node B.
>
> However, recent async semantics work in such way that if you updated the entity in node A and wanted to execute the query in node A, you still might want to add a little delay...
>
> The reason for that is that the logic changes based on whether the ownership of entity type key in the update timestamp cache is in node A or node B. If the owner is node A, the cache is updated directly by the main thread. So you can execute a query on node A immediately after the update and it'll be fine.
>
> However, if the owner is node B, even if the update was done in node A, node A will only be updated asynchronously. So, if after calling an update on node A, you do a query on node A, in this scenario you'd get outdated results for a small period of time. [1]
>
> So, my question here is: can we do anything to make this more predictable from a users perspective? Or is it just not worth doing it? Or is it just a side effect that we must be aware off?
>
> Cheers,
>
> [1] https://gist.github.com/galderz/676f689884969658b01a7695f08dd7a2
> --
> Galder Zamarre?o
> Infinispan, Red Hat
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From slaskawi at redhat.com  Thu Jan 26 14:38:44 2017
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Thu, 26 Jan 2017 20:38:44 +0100
Subject: [infinispan-dev] Infinispan 9.0.0.Beta2 and 8.2.6.Final are out!
In-Reply-To: <f2a004ff-f3b3-d468-94e4-b1b0b0c2155c@redhat.com>
References: <F6ABB431-95CB-43C9-9077-845D9E0A899E@redhat.com>
	<1722935770.394930.1485340366305@mail.yahoo.com>
	<AFF2D0FA-D666-4D36-B1C4-D59D063FE79D@redhat.com>
	<f2a004ff-f3b3-d468-94e4-b1b0b0c2155c@redhat.com>
Message-ID: <CAA9R9O6hP2VR3UBPk6rLkeVf2ooDWeEZLijjJVDti3w0X5vXhQ@mail.gmail.com>

As far as I know we run sync with Maven Central every few days (every 2
days if I remember correctly but this could have changed).

So as Galder mentioned, if you want to use the latest bits, please use
repository.jboss.org.

Thanks,
Sebastian

On Thu, Jan 26, 2017 at 2:22 PM, Tristan Tarrant <ttarrant at redhat.com>
wrote:

> This is being tracked at:
>
> https://issues.sonatype.org/browse/MVNCENTRAL-1512
>
> Tristan
>
> On 26/01/17 14:12, Galder Zamarre?o wrote:
> > Hmmmm, strange... [1]. Maybe it just needs time to sync up? I'm looking
> into it.
> >
> > The artifacts are present in our JBoss repos [2], so you could add the
> JBoss repos manually in the mean time [3].
> >
> > Thanks for heads up! :)
> >
> > Cheers,
> >
> > [1] https://repo.maven.apache.org/maven2/org/infinispan/
> infinispan-core/9.0.0.Beta2/
> > [2] https://repository.jboss.org/nexus/content/groups/public-
> jboss/org/infinispan/infinispan-core/9.0.0.Beta2/
> > [3] http://infinispan.org/docs/stable/contributing/
> contributing.html#maven
> > --
> > Galder Zamarre?o
> > Infinispan, Red Hat
> >
> >> On 25 Jan 2017, at 11:32, Andrea Cosentino <ancosen1985 at yahoo.com>
> wrote:
> >>
> >> Just noticed the artifacts aren't promoted on Maven central.
> >>
> >> Cheers,
> >> Andrea
> >>
> >> Il mar, 24 gen, 2017 alle 14:57, Galder Zamarre?o
> >> <galder at redhat.com> ha scritto:
> >> You can read all about these releases here:
> >> http://blog.infinispan.org/2017/01/infinispan-900beta2-
> and-826final-are-out.html
> >>
> >> Cheers,
> >> --
> >> Galder Zamarre?o
> >> Infinispan, Red Hat
> >>
> >>
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170126/4e0f1ec3/attachment-0001.html 

From ancosen1985 at yahoo.com  Fri Jan 27 04:15:30 2017
From: ancosen1985 at yahoo.com (Andrea Cosentino)
Date: Fri, 27 Jan 2017 09:15:30 +0000 (UTC)
Subject: [infinispan-dev] Infinispan 9.0.0.Beta2 and 8.2.6.Final are out!
In-Reply-To: <CAA9R9O6hP2VR3UBPk6rLkeVf2ooDWeEZLijjJVDti3w0X5vXhQ@mail.gmail.com>
References: <F6ABB431-95CB-43C9-9077-845D9E0A899E@redhat.com>
	<1722935770.394930.1485340366305@mail.yahoo.com>
	<AFF2D0FA-D666-4D36-B1C4-D59D063FE79D@redhat.com>
	<f2a004ff-f3b3-d468-94e4-b1b0b0c2155c@redhat.com>
	<CAA9R9O6hP2VR3UBPk6rLkeVf2ooDWeEZLijjJVDti3w0X5vXhQ@mail.gmail.com>
Message-ID: <693524115.160053.1485508530662@mail.yahoo.com>

Thanks guys!

 
--
Andrea Cosentino 
----------------------------------
Apache Camel PMC Member
Apache Karaf Committer
Apache Servicemix Committer
Email: ancosen1985 at yahoo.com
Twitter: @oscerd2
Github: oscerd


On Thursday, January 26, 2017 8:39 PM, Sebastian Laskawiec <slaskawi at redhat.com> wrote:



As far as I know we run sync with Maven Central every few days (every 2 days if I remember correctly but this could have changed). 

So as Galder mentioned, if you want to use the latest bits, please use repository.jboss.org.

Thanks,
Sebastian


On Thu, Jan 26, 2017 at 2:22 PM, Tristan Tarrant <ttarrant at redhat.com> wrote:

This is being tracked at:
>
>https://issues.sonatype.org/ browse/MVNCENTRAL-1512
>
>Tristan
>
>
>On 26/01/17 14:12, Galder Zamarre?o wrote:
>> Hmmmm, strange... [1]. Maybe it just needs time to sync up? I'm looking into it.
>>
>> The artifacts are present in our JBoss repos [2], so you could add the JBoss repos manually in the mean time [3].
>>
>> Thanks for heads up! :)
>>
>> Cheers,
>>
>> [1] https://repo.maven.apache.org/ maven2/org/infinispan/ infinispan-core/9.0.0.Beta2/
>> [2] https://repository.jboss.org/ nexus/content/groups/public- jboss/org/infinispan/ infinispan-core/9.0.0.Beta2/
>> [3] http://infinispan.org/docs/ stable/contributing/ contributing.html#maven
>> --
>> Galder Zamarre?o
>> Infinispan, Red Hat
>>
>>> On 25 Jan 2017, at 11:32, Andrea Cosentino <ancosen1985 at yahoo.com> wrote:
>>>
>>> Just noticed the artifacts aren't promoted on Maven central.
>>>
>>> Cheers,
>>> Andrea
>>>
>>> Il mar, 24 gen, 2017 alle 14:57, Galder Zamarre?o
>>> <galder at redhat.com> ha scritto:
>>> You can read all about these releases here:
>>> http://blog.infinispan.org/ 2017/01/infinispan-900beta2- and-826final-are-out.html
>>>
>>> Cheers,
>>> --
>>> Galder Zamarre?o
>>> Infinispan, Red Hat
>>>
>>>
>>> ______________________________ _________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/ mailman/listinfo/infinispan- dev
>>
>>
>> ______________________________ _________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/ mailman/listinfo/infinispan- dev
>>
>
>--
>Tristan Tarrant
>Infinispan Lead
>JBoss, a division of Red Hat
>
>
>______________________________ _________________
>infinispan-dev mailing list
>infinispan-dev at lists.jboss.org
>https://lists.jboss.org/ mailman/listinfo/infinispan- dev