[infinispan-dev] JIRAs for a 7.0.3 release

Fri Dec 19 10:04:29 EST 2014

On 12/19/2014 02:55 PM, Sanne Grinovero wrote:
> It's possible I could get you an upgrade to Hibernate Search
> 5.0.0.Final & related HQL Parser 1.1.0.Final soon, but I'm currently
> in trouble with regressions of the Infinispan testsuite.
>
> @Pedro, that draft commit you had sent me made wonders. You think you
> could finish that and get it integrated?
> Until that's solved I'm not going to bother spending time on Infinispan ;-)

Which commit? The performance regression because of the remote refactor? 
that commit was already integrated :)

If you found another one let me know :P

Pedro

>
> On 19 December 2014 at 13:52, Tristan Tarrant <ttarrant at redhat.com> wrote:
>> 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
>>
>> _______________________________________________
>> 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
>