[JBoss JIRA] (ISPN-4113) REST Store should support rawValues
by Tristan Tarrant (JIRA)
Tristan Tarrant created ISPN-4113:
-------------------------------------
Summary: REST Store should support rawValues
Key: ISPN-4113
URL: https://issues.jboss.org/browse/ISPN-4113
Project: Infinispan
Issue Type: Bug
Components: Server
Affects Versions: 7.0.0.Alpha1
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
Fix For: 7.0.0.Final, 7.0.0.Alpha2
When the REST Store is used as a connector for Rolling Upgrades it should not attempt to marshall/unmarshall the data but just store it raw for the consumption for the REST Server.
--
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
12 years
[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:
-----------------------------------------------
Jakub Markos <jmarkos(a)redhat.com> changed the Status of [bug 1073612|https://bugzilla.redhat.com/show_bug.cgi?id=1073612] from ON_QA to VERIFIED
> 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
12 years
[JBoss JIRA] (ISPN-3338) DistributionManager operations Locate key & Is key local are not working properly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3338?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3338:
-----------------------------------------------
Tomas Sykora <tsykora(a)redhat.com> changed the Status of [bug 986341|https://bugzilla.redhat.com/show_bug.cgi?id=986341] from ASSIGNED to VERIFIED
> DistributionManager operations Locate key & Is key local are not working properly
> ---------------------------------------------------------------------------------
>
> Key: ISPN-3338
> URL: https://issues.jboss.org/browse/ISPN-3338
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Environment: Tested localy Fedora16
> Reporter: Tomas Sykora
> Assignee: Mircea Markus
> Fix For: 7.0.0.Final, 7.0.0.Alpha2
>
>
> Testing infinispan-rhq-plugin (for InVM).
> DistributionManager operations Locate key & Is key local seem not to working properly. For a nonsense key Locate key operation is returning success with result of a label for cache "home node".
> Is key local operation for nonsense key is returning TRUE which is obviously wrong. This happens even on totally clear, entry-free, cache.
> Operation Could key be affected by a rehash is returning operation success with result false. This is questionable whether it should return failure or not. Again, for nonsense key.
> Please can anyone look at it?
> I don't think this is directly jon/plugin related.
--
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
12 years
[JBoss JIRA] (ISPN-4112) RHQ library plugin: restart cache -- availability report DOWN but cache running
by Tomas Sykora (JIRA)
Tomas Sykora created ISPN-4112:
----------------------------------
Summary: RHQ library plugin: restart cache -- availability report DOWN but cache running
Key: ISPN-4112
URL: https://issues.jboss.org/browse/ISPN-4112
Project: Infinispan
Issue Type: Bug
Components: JMX, reporting and management
Affects Versions: 7.0.0.Alpha1, 6.0.1.Final
Reporter: Tomas Sykora
Assignee: Mircea Markus
When we explicitly call STOP operation on particular cache using RHQ UI, this operation is successfully issued and cache is stopped.
Then, we can issue START operation as well.
Cache is started but RHQ is still not-correctly reporting that cache is DOWN and unavailable.
I will investigate this issue, this is just for proper heads up and for tracking purposes.
--
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
12 years
[JBoss JIRA] (ISPN-4062) Infinispan directory server module is missing some dependecies
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4062?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4062:
-----------------------------------------------
Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1073086|https://bugzilla.redhat.com/show_bug.cgi?id=1073086] from ON_QA to VERIFIED
> Infinispan directory server module is missing some dependecies
> --------------------------------------------------------------
>
> Key: ISPN-4062
> URL: https://issues.jboss.org/browse/ISPN-4062
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 6.0.0.Final
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Labels: 6.3remotequeries, 621
> Fix For: 7.0.0.Final, 7.0.0.Alpha2
>
>
> Configuring an indexed cache with 'infinispan' provider will result in an exception at server startup due to missing dependencies from module.xml:
> {code}
> 19:01:59,862 INFO [org.jboss.as.clustering.infinispan] (CacheStartThread,null,LuceneIndexesData) JBAS010281: Started LuceneIndexesData cache from local container
> 19:01:59,868 INFO [org.infinispan.jmx.CacheJmxRegistration] (CacheStartThread,null,LuceneIndexesLocking) ISPN000031: MBeans were successfully registered to the platform MBean server.
> 19:01:59,868 INFO [org.jboss.as.clustering.infinispan] (CacheStartThread,null,LuceneIndexesLocking) JBAS010281: Started LuceneIndexesLocking cache from local container
> 19:01:59,883 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC00001: Failed to start service jboss.infinispan.local.addressbook: org.jboss.msc.service.StartException in service jboss.infinispan.local.addressbook: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: java.lang.NoClassDefFoundError: javax/management/MBeanRegistrationException
> at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_40]
> at java.lang.Class.forName(Class.java:270) [rt.jar:1.7.0_40]
> at org.jboss.logging.Logger.getMessageLogger(Logger.java:2247)
> at org.jboss.logging.Logger.getMessageLogger(Logger.java:2211)
> at org.infinispan.util.logging.LogFactory.getLog(LogFactory.java:19)
> at org.infinispan.lucene.impl.DirectoryBuilderImpl.<clinit>(DirectoryBuilderImpl.java:23)
> at org.infinispan.lucene.directory.DirectoryBuilder.newDirectoryInstance(DirectoryBuilder.java:25)
> at org.hibernate.search.infinispan.impl.InfinispanDirectoryProvider.start(InfinispanDirectoryProvider.java:103)
> at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:103)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:261)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:528)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManagers(IndexManagerHolder.java:495)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.buildEntityIndexBinding(IndexManagerHolder.java:104)
> at org.hibernate.search.spi.SearchFactoryBuilder.initDocumentBuilders(SearchFactoryBuilder.java:363)
> at org.hibernate.search.spi.SearchFactoryBuilder.buildNewSearchFactory(SearchFactoryBuilder.java:219)
> at org.hibernate.search.spi.SearchFactoryBuilder.buildSearchFactory(SearchFactoryBuilder.java:143)
> at org.infinispan.query.impl.LifecycleManager.getSearchFactory(LifecycleManager.java:213)
> at org.infinispan.query.impl.LifecycleManager.cacheStarting(LifecycleManager.java:73)
> at org.infinispan.factories.ComponentRegistry.notifyCacheStarting(ComponentRegistry.java:228)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:214)
> at org.infinispan.CacheImpl.start(CacheImpl.java:674)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:553)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:516)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:398)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:412)
> at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:89)
> at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:80)
> at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:78)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]
> ... 3 more
> Caused by: java.lang.ClassNotFoundException: javax.management.MBeanRegistrationException from [Module "org.infinispan.lucene:main" from local module loader @136d1b4 (finder: local module finder @19dc4 (roots: /home/adrian/work/cpp-client/infinispan-server-7.0.0-SNAPSHOT/modules,/home/adrian/work/cpp-client/infinispan-server-7.0.0-SNAPSHOT/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) [jboss-modules.jar:1.2.0.CR1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468) [jboss-modules.jar:1.2.0.CR1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456) [jboss-modules.jar:1.2.0.CR1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) [jboss-modules.jar:1.2.0.CR1]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120) [jboss-modules.jar:1.2.0.CR1]
> ... 33 more
> {code}
--
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
12 years
[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:
-----------------------------------------------
Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1059277|https://bugzilla.redhat.com/show_bug.cgi?id=1059277] from ON_QA to VERIFIED
> 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
12 years