[JBoss JIRA] (ISPN-5728) Implement all the default methods in Java 8's Map interface
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5728?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5728:
----------------------------------
Fix Version/s: 8.1.0.Alpha2
(was: 8.1.0.Alpha1)
> Implement all the default methods in Java 8's Map interface
> -----------------------------------------------------------
>
> Key: ISPN-5728
> URL: https://issues.jboss.org/browse/ISPN-5728
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Affects Versions: 8.0.0.Final
> Reporter: Dan Berindei
> Fix For: 8.1.0.Alpha2
>
>
> Java 8 added many new methods to the {{Map}} interface. Some of them were already present in {{ConcurrentMap}}, but others are new: {{getOrDefault()}}, {{forEach()}}, {{replaceAll()}}, {{computeIfAbsent()}}, {{computeIfPresent()}}, {{compute()}}, {{merge()}}.
> We should try to write Infinispan-specific implementations wherever that would improve correctness and/or performance.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (ISPN-5787) Issues with aggregation queries using Date objects
by Jakub Markos (JIRA)
Jakub Markos created ISPN-5787:
----------------------------------
Summary: Issues with aggregation queries using Date objects
Key: ISPN-5787
URL: https://issues.jboss.org/browse/ISPN-5787
Project: Infinispan
Issue Type: Bug
Reporter: Jakub Markos
Assignee: Adrian Nistor
I found 2 problems, not sure if they have a common cause:
1.
This query
{code}
Query q = qf.from(getModelFactory().getTransactionImplClass())
.select("date")
.having("date").between(makeDate("2013-02-15"), makeDate("2013-03-15")).toBuilder()
.groupBy("date")
.build();
List<Object[]> list = q.list();
{code}
fails with
{code}
org.hibernate.hql.ParsingException: HQL000002: The query SELECT _gen0.date FROM org.infinispan.query.dsl.embedded.testdomain.hsearch.TransactionHS _gen0 WHERE (date >= Fri Feb 15 01:00:00 CET 2013) AND (date <= Fri Mar 15 01:00:00 CET 2013) is not valid; Parser error messages: [[statement, statementElement, selectStatement, queryExpression, querySpec, whereClause, logicalExpression, expression, logicalOrExpression, logicalAndExpression, negatedExpression, equalityExpression, relationalExpression, concatenation, additiveExpression, multiplyExpression, unaryExpression, atom]: line 1:116 mismatched token: [@35,116:118='Feb',<75>,1:116]; expecting type RIGHT_PAREN].
{code}
The query works after removing the groupBy.
2.
This query
{code}
Query q = qf.from(getModelFactory().getTransactionImplClass())
.select(Expression.count("date"), Expression.min("date"))
.having("description").eq("Hotel").toBuilder()
.groupBy("id")
.build();
List<Object[]> list = q.list();
{code}
returns in the 2nd column the numeric representation of the Date (i.e. 20130227000000000) instead of an object. Selecting only the minimum, select(Expression.min("date")), the query returns a Date object.
Both queries are supposed to be run inside the QueryDslConditionsTest test class.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (ISPN-5786) Provide ability to rename a cache
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5786?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant commented on ISPN-5786:
---------------------------------------
Alternatively introduce the possibility to have cache aliases.
> Provide ability to rename a cache
> ---------------------------------
>
> Key: ISPN-5786
> URL: https://issues.jboss.org/browse/ISPN-5786
> Project: Infinispan
> Issue Type: Feature Request
> Components: Server
> Reporter: Van Halbert
>
> Provide the ability to rename a cache.
> The benefit of this would enable the primary cache to remain available while a secondary cache gets totally refreshed. And once the refresh is complete, perform the cache rename. This would eliminate the down time of the primary cache.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (ISPN-3496) Infinispan library breaks Hibernate 2LC with java.lang.ClassCastException: org.infinispan.remoting.ReplicationQueueImpl cannot be cast to org.infinispan.remoting.ReplicationQueue
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3496?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3496:
-----------------------------------------------
Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1002931|https://bugzilla.redhat.com/show_bug.cgi?id=1002931] from VERIFIED to CLOSED
> Infinispan library breaks Hibernate 2LC with java.lang.ClassCastException: org.infinispan.remoting.ReplicationQueueImpl cannot be cast to org.infinispan.remoting.ReplicationQueue
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3496
> URL: https://issues.jboss.org/browse/ISPN-3496
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.1.Final
> Environment: EAP 6.1.0 and 6.1.1. This is a regression since EAP 6.0.1
> Reporter: Martin Gencur
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 620
> Fix For: 5.2.8.Final
>
>
> A WAR deployment containing its own infinispan (such as JDG helloworld quickstart) and also having persistence.xml with second level cache enabled fails to deploy on EAP 6.1 HA configuration (standalone-ha.xml or standalone-full-ha.xml)
> Version-Release number of selected component (if applicable):
> EAP 6.1.0, EAP 6.1.1.ER4.
> Note: This does not happen with EAP 6.0.1 so it's a regression.
> Steps to Reproduce:
> 1. Get JDG 6.1 helloworld-jdg quickstart (or see the attachment)
> 2. Add persistence.xml with 2lc, e.g.:
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <persistence xmlns="http://java.sun.com/xml/ns/persistence"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
> version="2.0">
> <persistence-unit name="entityManager">
> <jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source>
> <properties>
> <property name="hibernate.hbm2ddl.auto" value="create-drop"/>
> <property name="hibernate.cache.use_second_level_cache" value="true"/>
> <property name="hibernate.cache.use_query_cache" value="true"/>
> </properties>
> </persistence-unit>
> </persistence>
> {code}
> 3. deploy the helloworld-jdg on standalone-ha.xml or standalone-full-ha.xml configuration of EAP 6.1.
> This happens also when standalone.xml file is used to start EAP.
> The resulting error:
> {code}
> 10:26:20,759 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 53) MSC000001: Failed to start service jboss.persistenceunit."jboss-as-helloworld-jdg.war#entityManager": org.jboss.msc.service.StartException in service jboss.persistenceunit."jboss-as-helloworld-jdg.war#entityManager": javax.persistence.PersistenceException: [PersistenceUnit: entityManager] Unable to build EntityManagerFactory
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:103)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final-redhat-1.jar:2.1.0.Final-redhat-1]
> Caused by: javax.persistence.PersistenceException: [PersistenceUnit: entityManager] Unable to build EntityManagerFactory
> at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:930)
> at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:904)
> at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:92)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.createContainerEntityManagerFactory(PersistenceUnitServiceImpl.java:200)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.access$600(PersistenceUnitServiceImpl.java:57)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:99)
> ... 4 more
> Caused by: org.hibernate.service.spi.ServiceException: Unable to create requested service [org.hibernate.engine.spi.CacheImplementor]
> at org.hibernate.service.internal.AbstractServiceRegistryImpl.createService(AbstractServiceRegistryImpl.java:186)
> at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:150)
> at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:264)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1762)
> at org.hibernate.ejb.EntityManagerFactoryImpl.<init>(EntityManagerFactoryImpl.java:94)
> at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:920)
> ... 9 more
> Caused by: org.hibernate.cache.CacheException: Unable to start region factory
> at org.hibernate.cache.infinispan.InfinispanRegionFactory.start(InfinispanRegionFactory.java:323)
> at org.hibernate.internal.CacheImpl.<init>(CacheImpl.java:70)
> at org.hibernate.engine.spi.CacheInitiator.initiateService(CacheInitiator.java:40)
> at org.hibernate.engine.spi.CacheInitiator.initiateService(CacheInitiator.java:35)
> at org.hibernate.service.internal.SessionFactoryServiceRegistryImpl.initiateService(SessionFactoryServiceRegistryImpl.java:91)
> at org.hibernate.service.internal.AbstractServiceRegistryImpl.createService(AbstractServiceRegistryImpl.java:176)
> ... 15 more
> Caused by: java.lang.ClassCastException: org.infinispan.remoting.ReplicationQueueImpl cannot be cast to org.infinispan.remoting.ReplicationQueue
> at org.infinispan.configuration.cache.LegacyConfigurationAdaptor.adapt(LegacyConfigurationAdaptor.java:306)
> at org.infinispan.manager.DefaultCacheManager.defineConfiguration(DefaultCacheManager.java:468)
> at org.infinispan.manager.DefaultCacheManager.defineConfiguration(DefaultCacheManager.java:443)
> at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.defineConfiguration(DefaultEmbeddedCacheManager.java:77)
> at org.hibernate.cache.infinispan.InfinispanRegionFactory.defineGenericDataTypeCacheConfigurations(InfinispanRegionFactory.java:492)
> at org.hibernate.cache.infinispan.InfinispanRegionFactory.start(InfinispanRegionFactory.java:318)
> ... 20 more
> 10:26:20,968 ERROR [org.jboss.as.server] (management-handler-thread - 4) JBAS015870: Deploy of deployment "jboss-as-helloworld-jdg.war" was rolled back with the following failure message:
> {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jboss-as-helloworld-jdg.war#entityManager\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jboss-as-helloworld-jdg.war#entityManager\": javax.persistence.PersistenceException: [PersistenceUnit: entityManager] Unable to build EntityManagerFactory
> Caused by: javax.persistence.PersistenceException: [PersistenceUnit: entityManager] Unable to build EntityManagerFactory
> Caused by: org.hibernate.service.spi.ServiceException: Unable to create requested service [org.hibernate.engine.spi.CacheImplementor]
> Caused by: org.hibernate.cache.CacheException: Unable to start region factory
> Caused by: java.lang.ClassCastException: org.infinispan.remoting.ReplicationQueueImpl cannot be cast to org.infinispan.remoting.ReplicationQueue"}}
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (ISPN-4220) RemoteCacheManager.getCache may ignore the forceReturnValue flag
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4220?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4220:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1259914|https://bugzilla.redhat.com/show_bug.cgi?id=1259914] from NEW to MODIFIED
> RemoteCacheManager.getCache may ignore the forceReturnValue flag
> ----------------------------------------------------------------
>
> Key: ISPN-4220
> URL: https://issues.jboss.org/browse/ISPN-4220
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 6.0.2.Final, 7.0.0.Alpha3
> Reporter: Radim Vansa
> Assignee: Galder Zamarreño
> Fix For: 8.0.0.Beta3, 7.2.4.Final
>
>
> {code}
> RemoteCacheManager manager = ...;
> Cache noReturnCache = manager.getCache("foo", false);
> Cache returnValueCache = manager.getCache("foo", true);
> {code}
> The second returned cache will use forceReturnValue=false, although it was retrieved with forceReturnValue=true. The reason is that caches are stored in a map by name, ignoring this flag.
> There should be two such maps. The question is what should getCache("foo") return if previously only getCache("foo", true) was called.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (ISPN-5786) Provide ability to rename a cache
by Van Halbert (JIRA)
Van Halbert created ISPN-5786:
---------------------------------
Summary: Provide ability to rename a cache
Key: ISPN-5786
URL: https://issues.jboss.org/browse/ISPN-5786
Project: Infinispan
Issue Type: Feature Request
Components: Server
Reporter: Van Halbert
Provide the ability to rename a cache.
The benefit of this would enable the primary cache to remain available while a secondary cache gets totally refreshed. And once the refresh is complete, perform the cache rename. This would eliminate the down time of the primary cache.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (ISPN-5783) Cache.put(null, null) leaks an implicit transaction
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5783?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5783:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 8.1.0.Final
Resolution: Done
> Cache.put(null, null) leaks an implicit transaction
> ---------------------------------------------------
>
> Key: ISPN-5783
> URL: https://issues.jboss.org/browse/ISPN-5783
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.0.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 8.1.0.Alpha1, 8.1.0.Final
>
>
> {{null}} keys and values are not supported, and {{Cache.put(null, null)}} will throw a {{NullPointerException}}. But the null check happens after the implicit transaction was created, and it doesn't clean it up before throwing the exception.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (ISPN-5785) Make the GMS join timeout overridable in the server
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5785?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5785:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 8.1.0.Final
Resolution: Done
> Make the GMS join timeout overridable in the server
> ---------------------------------------------------
>
> Key: ISPN-5785
> URL: https://issues.jboss.org/browse/ISPN-5785
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 8.1.0.Alpha1, 8.1.0.Final
>
>
> The default JGroups configuration in the server has a join timeout of 15s, causing the server in clustered or domain mode to take >20s to start (in non clustered it takes < 5s). Ideally this timeout should be easily configured via command line so that integration tests and docker images can benefit from it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (ISPN-5785) Make the GMS join timeout overridable in the server
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-5785?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-5785:
------------------------------------
Status: Open (was: New)
> Make the GMS join timeout overridable in the server
> ---------------------------------------------------
>
> Key: ISPN-5785
> URL: https://issues.jboss.org/browse/ISPN-5785
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 8.1.0.Alpha1
>
>
> The default JGroups configuration in the server has a join timeout of 15s, causing the server in clustered or domain mode to take >20s to start (in non clustered it takes < 5s). Ideally this timeout should be easily configured via command line so that integration tests and docker images can benefit from it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months