[infinispan-dev] JIRAs for a 7.0.3 release

Fri Dec 19 08:52:53 EST 2014

Hi all,

this is the current status of the 7.0.x branch:

ISPN-5027     OutOfMemoryError in entry retriever when state transfer 
chunk size is Integer.MAX_VALUE
ISPN-5053     Modules inheriting directly from the BOM use Java 1.5
ISPN-5008     7.0.x missing cachestore-remote and extended-statistics 
modules
ISPN-5007     Enhance the distribution script to detect missing artifacts
ISPN-5052     Lock timeout details prints out null for local locks
ISPN-4989     infinispan-transport thread name is undefined
ISPN-5030     NPE during node rebalance after a leave
ISPN-4975     Cross site state transfer - status of push gets stuck at 
"SENDING" after being cancelled
ISPN-4444     After state transfer, a node is able to read keys it no 
longer owns from its data container
ISPN-4979     CacheStatusResponse map uses too much memory
ISPN-4949     Split brain: inconsistent data after merge
ISPN-3561     A joining cache should receive the rebalancedEnabled flag 
from the coordinator.
ISPN-5000     Cleanup rebalance confirmation collector when node is not 
coord
ISPN-5040     Upgrade to JGroups 3.6.1.Final
ISPN-5011     CacheManager not stopping when search factory not initialized
ISPN-5048     Relocate some imported packages in uberjars and remove any 
javax.* classes
ISPN-4948     Package embedded CLI as uberjar
ISPN-5017     Include the CLI uberjar in the distribution zip
ISPN-5029     Infinispan 7.0.2 not fully backwards compatible with 6.0.x
ISPN-5026     The Infinispan 7.0.2's GUI demo cannot be properly 
launched in Windows 7
ISPN-5018     Add test for protobuf marshalling of primitives
ISPN-5006     Upgrade to Hibernate Search 5.0.0.Beta3
ISPN-5005     Upgrade to Hibernate HQL Parser 1.1.0.Beta1
ISPN-5032     Create dedicated GetCacheEntryCommand to simplify code and 
save memory on GetKeyValueCommand

The remaining wishlist items are:

ISPN-4546     Possible stale lock when the primary owner leaves during 
rebalance
ISPN-4586     Too many OutdatedTopologyExceptions in non-transactional 
caches
ISPN-5037     Do not replicate value from backup owner
ISPN-5042     Remote gets caused by writes could be replicated only to 
the primary owner
ISPN-5076     Pessimistic transactions can lose their locks when the 
primary owner changes
ISPN-5088     Deleted entries from (FineGrained)AtomicMap reappear in 
subsequent transaction

which I have tagged with the label "7.0".
It seems like ISPN-5088 has a chance to be fixed quickly and since I'd 
like to do a 7.0.3 sooner rather than later we'll wait for that and then 
release. Anything else can be postponed to 7.0.4 or 7.1.0.Final (which 
is due by Jan 31).

Tristan

On 16/12/2014 11:03, Emmanuel Bernard wrote:
> While we are on a wish list for 7.0.3.
> We have found a regression from Infinispan 6 on (FineGrained)AtomicMap that is seriously impacting Hibernate OGM.
>
> ISPN-5088
>
> We should get this one quickly to avoid people tripping over the concurrency concern the workaround implies.
>
> Emmanuel
>
>> On 15 Dec 2014, at 21:50, Erik Salter <an1310 at hotmail.com> wrote:
>>
>> Hi all,
>>
>> I have a few more that might be candidates for the 7.0.x branch.  The
>> critical ones (for me) have to do with state transfer and locks.  Some of
>> these are still pending, though.
>>
>> ISPN-5076
>> ISPN-5030
>> ISPN-5000
>> ISPN-4546
>>
>> There are a few optimizations. ISPN-5042, in particular, seems like a
>> quick win.  For ISPN-5037 and ISPN-5032, I'll probably implement on my own.
>>
>> Also under the heading of optimizations -- one thing that's a real problem
>> with my cache configuration is the verbose nature of
>> OutdatedTopologyExceptions.  They're thrown as RemoteExceptions, which
>> cause stack traces all over the place when a NonTx cache retries its
>> operation.  (These actually crashed an indexer on my analytics engine
>> during a performance state transfer test.)  Also, if the key ownership
>> hasn't changed, why throw them at all?
>>
>> ISPN-4695
>> ISPN-4586
>>
>> (If I'm on Santa's naughty list, I may have a crack at implementing them.)
>>
>> There are a few minor cosmetic things that are easily ported.
>>
>> ISPN-4989
>> ISPN-5040
>> ISPN-5052
>>
>>
>> Thanks all,
>>
>> Erik
>>
>> On 12/4/14, 10:22 AM, "Erik Salter" <an1310 at hotmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I was asked to vote on a list of JIRAs for 7.0.3 and send it to the
>>> mailing list.  The next iteration of my application is migrating from
>>> 5.2.x to 7.0.x, so I'm really focused on hardening and stability,
>>> especially WRT state transfer.  Here are the ones I was looking at, mostly
>>> related to state transfer:
>>>
>>> - ISPN-5000
>>>
>>> - ISPN-4949 (and related ISPN-5030)
>>> - ISPN-4975
>>> - ISPN-5027
>>>
>>> Notes on a few others I was looking at:
>>> - ISPN-4444, from the description, looks serious enough to include.  I
>>> haven't looked at the commit in-depth; appears to be limited to keys in
>>> L1?
>>> - ISPN-4979 appears to be a substantial change.  I would defer to the team
>>> about how risky of a change it is.
>>>
>>> And if ISPN-3561 makes it into a 7.0.3, I'd consider it a personal favor.
>>>
>>> Regards,
>>>
>>> Erik
>>>
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> 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