[JBoss JIRA] Updated: (ISPN-186) Smart L1 cache invalidation
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-186?page=com.atlassian.jira.plugin.s... ]
Galder Zamarreño updated ISPN-186:
----------------------------------
Fix Version/s: 5.0.0.ALPHA4
(was: 5.0.0.BETA1)
> Smart L1 cache invalidation
> ---------------------------
>
> Key: ISPN-186
> URL: https://issues.jboss.org/browse/ISPN-186
> Project: Infinispan
> Issue Type: Feature Request
> Components: Distributed Cache
> Reporter: Manik Surtani
> Assignee: Pete Muir
> Labels: l1
> Fix For: 5.0.0.ALPHA4, 5.0.0.FINAL
>
>
> Need to build a mechanism in which L1 invalidation is NOT multicast, but instead is unicast _if necessary_ to specific nodes that may have cached a given entry. This can be detected by maintaining a list of nodes who have requested a key via a remote get, but this would need to be relayed by all data owners.
> Benefits would be performance by removing unnecessary invalidation where this is not needed, and by reducing noise in network stacks of most nodes.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (ISPN-945) Stop query module from relying on a SNAPSHOT Hibernate Search version
by Galder Zamarreño (JIRA)
Stop query module from relying on a SNAPSHOT Hibernate Search version
---------------------------------------------------------------------
Key: ISPN-945
URL: https://issues.jboss.org/browse/ISPN-945
Project: Infinispan
Issue Type: Bug
Components: Querying
Affects Versions: 5.0.0.ALPHA3
Reporter: Galder Zamarreño
Assignee: Sanne Grinovero
Priority: Critical
Fix For: 5.0.0.BETA1
Master's query module is relying on a SNAPSHOT:
{code}<version.hibernate.search>3.4.0-SNAPSHOT</version.hibernate.search>{code}
Which means that the master build now fails with:
{code}[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Compilation failure
/Users/z/Go/code/infinispan.git/query/src/main/java/org/infinispan/query/impl/CacheQueryImpl.java:[222,39] cannot find symbol
symbol : constructor DocumentExtractor(org.hibernate.search.query.QueryHits,org.hibernate.search.engine.SearchFactoryImplementor,java.lang.String[],java.util.Set<java.lang.String>,boolean)
location: class org.hibernate.search.engine.DocumentExtractor
/Users/z/Go/code/infinispan.git/query/src/main/java/org/infinispan/query/impl/CacheQueryImpl.java:[256,39] cannot find symbol
symbol : constructor DocumentExtractor(org.hibernate.search.query.QueryHits,org.hibernate.search.engine.SearchFactoryImplementor,java.lang.String[],java.util.Set<java.lang.String>,boolean)
location: class org.hibernate.search.engine.DocumentExtractor
/Users/z/Go/code/infinispan.git/query/src/main/java/org/infinispan/query/impl/CacheQueryImpl.java:[286,39] cannot find symbol
symbol : constructor DocumentExtractor(org.hibernate.search.query.QueryHits,org.hibernate.search.engine.SearchFactoryImplementor,java.lang.String[],java.util.Set<java.lang.String>,boolean)
location: class org.hibernate.search.engine.DocumentExtractor{code}
Unfortunately ALPHA3 went out with this so query module users might encounter similar issues.
This needs to be resolved by BETA1.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (ISPN-944) RemoteCacheManager.getCache() should be friendlier when cache does not exist
by Galder Zamarreño (JIRA)
RemoteCacheManager.getCache() should be friendlier when cache does not exist
----------------------------------------------------------------------------
Key: ISPN-944
URL: https://issues.jboss.org/browse/ISPN-944
Project: Infinispan
Issue Type: Bug
Components: Cache Server
Affects Versions: 4.2.1.CR3, 4.2.0.Final
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Fix For: 4.2.1.FINAL
When a Java Hot Rod client requests a non-existing cache, RemoteCacheManager throws a rather cryptic exception:
{code}Feb 9, 2011 5:52:48 PM org.infinispan.client.hotrod.impl.operations.HotRodOperation checkForErrorsInResponseStatus
WARNING: Error status received from the server: for message id 2
Exception in thread "main" org.infinispan.client.hotrod.exceptions.HotRodClientException: id [2] code [133]
at org.infinispan.client.hotrod.impl.operations.HotRodOperation.checkForErrorsInResponseStatus(HotRodOperation.java:129)
at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:98)
at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:48)
at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:27)
at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:38)
at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:166)
at org.infinispan.CacheSupport.put(CacheSupport.java:28)
at org.example.Sample.main(Sample.java:14){code}
For 4.2.x, try to cleanup the exception so that it's a more friendly one.
For 5.x, returning null would make more sense. However, I'd rather see this limitation going away (as indicated in ISPN-833) and that would stop getCache() from returning anything other than a running cache of some sort. Bottom line, the end result is to not return null, so not much point in having an intermdiate API change when we're gonna change it again soon after.
To sum up, this jira will be limited to making the exception more user friendly.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (ISPN-948) Support XML marshaling of Configuration instances
by Jürgen Kellerer (JIRA)
Support XML marshaling of Configuration instances
-------------------------------------------------
Key: ISPN-948
URL: https://issues.jboss.org/browse/ISPN-948
Project: Infinispan
Issue Type: Feature Request
Components: Configuration
Affects Versions: 4.2.1.CR3
Reporter: Jürgen Kellerer
Assignee: Manik Surtani
Fix For: 4.2.1.FINAL, 5.0.0.Final
Infinispan supports a very flexible way of configuring caches using multiple levels of inheritance.
While this is really nice, it is sometimes not easy to understand how exactly a particular cache was configured.
(E.g. JPA is just one example where a cache configuration can be adjusted in several ways).
JMX or debuggers help but may not always be available.
What about allowing to convert a configuration instance back to XML to give a quick overview of the really applied settings. _(Optionally it might also be a nice little feature to implement a "toXmlString();" method or override the default and also make this available through JMX)_
JAXB annotations are already present on all configurable options but a couple getters and a @XmlRootElement annotation is missing that would allow to convert an existing instance back to XML. The effort in doing this should be rather low.
---
This feature request may also fit with #ISPN-791 as it would allow to transfer cache configs using XML.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (ISPN-991) Netty should use same logger as Infinispan
by Galder Zamarreño (JIRA)
Netty should use same logger as Infinispan
------------------------------------------
Key: ISPN-991
URL: https://issues.jboss.org/browse/ISPN-991
Project: Infinispan
Issue Type: Bug
Components: Cache Server
Affects Versions: 4.2.1.CR4
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Fix For: 4.2.1.FINAL
When Netty has some issues, it uses a logger which by default directs to the JDK logger. As shown in JBPAPP-6112, this causes issues, so I'd suggest forcing Netty to use the same logger Infinispan does. So, if Infinispan is configured with Log4J, so Netty and that can be forced by calling:
{code}InternalLoggerFactory.setDefaultFactory(new Log4JLoggerFactory());{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months