March 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4074) Only include public API in JavaDoc

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4074?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4074: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1014655|https://bugzilla.redhat.com/show_bug.cgi?id=1014655] from MODIFIED to ON_QA > Only include public API in JavaDoc > ---------------------------------- > > Key: ISPN-4074 > URL: https://issues.jboss.org/browse/ISPN-4074 > Project: Infinispan > Issue Type: Feature Request > Components: Build process, Documentation-Core > Affects Versions: 7.0.0.Alpha1 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.0.0.Alpha2 > > > Introduce a @public tag and a custom Doclet so that we can filter out non-public interfaces/classes from the Javadocs -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2255) FineGrainedAtomicMap missing key, value pairs in some cluster nodes in distributed mode, embedded infinispan cache

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2255?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2255: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1042861|https://bugzilla.redhat.com/show_bug.cgi?id=1042861] from MODIFIED to ON_QA > FineGrainedAtomicMap missing key,value pairs in some cluster nodes in distributed mode, embedded infinispan cache > ----------------------------------------------------------------------------------------------------------------- > > Key: ISPN-2255 > URL: https://issues.jboss.org/browse/ISPN-2255 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 5.1.5.FINAL > Environment: Details about cluster: > 1. Infinispan 5.1.5 > 2. java 7u5 64bit > 3. linux 64bit (two nodes debian and one node ubuntu) > 4. tomcat 7.0.28 > 5. jbossTM 4.16.0 JTA only > Tomcat integration code is here: > https://github.com/zvrablik/tomcatInfinispanSessionManager/tree/master/to... > 6. all machines are on real hw ( no virtual machines), date and time is synchronized and shouldn't vary more than 1 second > Reporter: Zdenek Henek > Assignee: Pedro Ruivo > Priority: Critical > Labels: 621 > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > Attachments: fgamissueTest2.zip, jgroupsConfig.xml, sessionInfinispanConfigtestLB.xml > > > I am using FineGrainedAtomicMap to store data into clustering distributed cache. When clustering set to replicated doesn't cause any issues or at least I haven't run > into any. When I switch to distributed mode I don't see some key,value pairs in some nodes. This happens randomly. The numOwners is set to two and I have cluster of three nodes. > more details: > https://community.jboss.org/thread/203420?tstart=60 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3871) Server testsuite fixes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3871?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3871: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1073612|https://bugzilla.redhat.com/show_bug.cgi?id=1073612] from MODIFIED to ON_QA > Server testsuite fixes > ---------------------- > > Key: ISPN-3871 > URL: https://issues.jboss.org/browse/ISPN-3871 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Reporter: Jakub Markos > Assignee: Jakub Markos > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > while running the server testsuite on various os configurations, several test issues were found: > - suppress-state-transfer tests on windows were failing because jenkins+windows+cygwin is slow, we're doing something like: "kill node -> verify that views are updated" and during the verification the update is still pending, fixed with sleeps after the kill > - hotrod protocol version bump > - running the testsuite with specific zip distribution on windows > - xsite config example test fix for ibm java -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3947) HotRod client keep trying recover connections to a failed cluster

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3947?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3947: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1058887|https://bugzilla.redhat.com/show_bug.cgi?id=1058887] from MODIFIED to ON_QA > HotRod client keep trying recover connections to a failed cluster > ----------------------------------------------------------------- > > Key: ISPN-3947 > URL: https://issues.jboss.org/browse/ISPN-3947 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Affects Versions: 6.0.1.Final, 7.0.0.Alpha1 > Reporter: Wolf-Dieter Fink > Assignee: Galder Zamarreño > Priority: Critical > Labels: 621, hotrod, hotrod-java-client > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > If an infinispan-server cluster is not longer reachable for some reason, i.e. network disconnect, the hot-rod client try to re-establish the lost connections. > The client library will retry this by a fixed calculation based on the max numbers of connections from the pool or 10 multiplied with the number of available servers. > This can lead in a very long time until the application can continue and react as it will wait for the read- or connect-timeout for each try. > To improve this behaviour there should be a configurable limit of retries per server and/or a timeout in total. > This will give the application the chance to handle a remote-cache failure and reply to the user instead of hanging for minutes (with the default settings) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4053) WriteSkew not throwing an exception for AtomicMap in REPL and DIST mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4053?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4053: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1047908|https://bugzilla.redhat.com/show_bug.cgi?id=1047908] from MODIFIED to ON_QA > WriteSkew not throwing an exception for AtomicMap in REPL and DIST mode > ----------------------------------------------------------------------- > > Key: ISPN-4053 > URL: https://issues.jboss.org/browse/ISPN-4053 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.1.Final > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Labels: 621 > Fix For: 7.0.0.Final, 7.0.0.Alpha2 > > > The writeSkewCheck flag does not work correctly for AtomicMap. When Infinispan runs in REPEATABLE_READ isolation mode for transactions, the writeSkewCheck flag is enabled, and two concurrent transactions read/write data from the same AtomicMap. The WriteSkewException exception is never thrown when committing either of the transactions. > Consequently, the data stored in the AtomicMap might be changed by another transaction, and current transaction will not register this change during commit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3942) HotRod client keep trying recover a connection to a cluster member after shutdown

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3942?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3942: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1059277|https://bugzilla.redhat.com/show_bug.cgi?id=1059277] from MODIFIED to ON_QA > HotRod client keep trying recover a connection to a cluster member after shutdown > --------------------------------------------------------------------------------- > > Key: ISPN-3942 > URL: https://issues.jboss.org/browse/ISPN-3942 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 6.0.1.Final, 7.0.0.Alpha1 > Environment: Infinispan server with HotRod client in server-client mode and replicated caches. > Reporter: Wolf-Dieter Fink > Assignee: Pedro Ruivo > Priority: Critical > Labels: clustered, hotrod, hotrod-java-client > Fix For: 7.0.0.Final, 7.0.0.Alpha2 > > Attachments: hotrod-client.log > > > If a HotRod client is connected to a server cluster and one of the servers do a correct shutdown, the client keep try to reconnect the server after the cluster view has changed. > There is only a replicated cache configured. > From the server-logfile the new cluster view is established > 16:00:22,290 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-3,shared=udp) ISPN000094: Received new cluster view: [node1/clustered|2] (1) [node1/clustered] > There is no failure from the application perspective, but there there is always a retry if the RoundRobin return the unavailable server. > This might end in a performance or failure issue if there is a larger cluster and a part going out of work for some reason. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3868) Deadlock in RemoteCache getAsync

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3868?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3868: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1073331|https://bugzilla.redhat.com/show_bug.cgi?id=1073331] from MODIFIED to ON_QA > Deadlock in RemoteCache getAsync > -------------------------------- > > Key: ISPN-3868 > URL: https://issues.jboss.org/browse/ISPN-3868 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.0.Final > Environment: RemoteCahe component of 6.0.0.Final > Reporter: Alexander Furer > Assignee: Mircea Markus > Labels: remote > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > Here is the implementation of remoteCahe.getAsync() : > {code} > public NotifyingFuture<V> getAsync(final K key) { > assertRemoteCacheManagerIsStarted(); > final NotifyingFutureImpl<V> result = new NotifyingFutureImpl<V>(); > Future<V> future = executorService.submit(new Callable<V>() { > @Override > public V call() throws Exception { > V toReturn = get(key); > result.notifyFutureCompletion(); > return toReturn; > } > }); > result.setExecuting(future); > return result; > } > {code} > 2 problems here : > 1. Callable's call method might be called BEFORE calling client had a chance to add listener (i.e. getAsync is not returned yet), in this case its' listener futureDone method will never be called. > 2. Even case #1 has not happened and notifyFutureCompletion is called on listener, but the future is not resolved yet : "call" has not returned, that's why the future that is passed to listener is not resolved, and calling future.get from listener blocks forever. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3956) L1WriteSynchronizer can cause locking with concurrent gets when value is not present

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3956?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3956: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1059814|https://bugzilla.redhat.com/show_bug.cgi?id=1059814] from MODIFIED to ON_QA > L1WriteSynchronizer can cause locking with concurrent gets when value is not present > ------------------------------------------------------------------------------------ > > Key: ISPN-3956 > URL: https://issues.jboss.org/browse/ISPN-3956 > Project: Infinispan > Issue Type: Bug > Components: L1 > Affects Versions: 6.0.0.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > This has been seen previously only on IBM JDK 6 ISPN-3889, however an end user also now can reproduce this issue https://community.jboss.org/thread/236590 > The issue is that we don't set the remote lookup value to be null when nothing is found and thus any threads that are waiting for the remote lookup were never notified of this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3957) Preload with async cache store is not efficient

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3957?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3957: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1059489|https://bugzilla.redhat.com/show_bug.cgi?id=1059489] from MODIFIED to ON_QA > Preload with async cache store is not efficient > ----------------------------------------------- > > Key: ISPN-3957 > URL: https://issues.jboss.org/browse/ISPN-3957 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Affects Versions: 5.2.7.Final > Reporter: Mircea Markus > Assignee: Dan Berindei > Labels: 621 > Fix For: 5.2.8.Final, 7.0.0.Alpha1, 7.0.0.Final > > > Configuring on a AdvancedCacheLoader preload=true and asyn=true cause it to load each entry in the store in a loop, each entry being loaded through an store read. > This is caused by the way loadAll is implemented in the AsynLoader: in order to enforce consistency with whatever is in memory it does some special handling. The thing is, though, that we don't need this advanced async loader logic during the initial preload, as the async cache loader is empty. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3762) Test org.infinispan.client.hotrod.ClientSocketReadTimeoutTest.testPutTimeout fail on all environments

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3762?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3762: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1034719|https://bugzilla.redhat.com/show_bug.cgi?id=1034719] from MODIFIED to ON_QA > Test org.infinispan.client.hotrod.ClientSocketReadTimeoutTest.testPutTimeout fail on all environments > ----------------------------------------------------------------------------------------------------- > > Key: ISPN-3762 > URL: https://issues.jboss.org/browse/ISPN-3762 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 6.0.0.Final > Reporter: Jiří Holuša > Assignee: Galder Zamarreño > Attachments: log.txt > > > The test org.infinispan.client.hotrod.ClientSocketReadTimeoutTest.testPutTimeout fails every time on all environments. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2014