[ISPN-78] Finalising the API
by Olaf Bergner
After finishing the first iteration of implementing ISPN-961 - Spring
Integration - I would like to turn my attention back to ISPN-78 - Large
Object Support. Specifically, I would like to finalise the API before
concentrating on the hard stuff, namely locking and transaction support.
These are the changes I currently envision:
1. Introduce a dedicated StreamingCache whereas now we have a
StreamingHandler a user obtains via Cache.getStreamingHandler(). A
StreamingCache would be a special kind of cache completely separate from
org.infinispan.Cache. Users would obtain StreamingCache instances from a
CacheManager.
Rationale: Users will IMHO most likely never mix and match "regular" as
well as large objects within a single cache. It is my experience that
(well-behaved) applications are acutely aware of the special treatment
large objects warrant. I therefore suspect that users will reserve a
dedicated cache for large objects anyway. Therefore it doesn't make
sense for such a cache to expose an API for "regular" objects.
Further, we might be able to provide sensible default settings for such
large object caches whereas now "regular" and large object caches share
the same default settings (since INFINISPAN cannot tell the difference).
2. Rename API methods:
void writeToKey(K key, InputStream largeObject) -> void
storeLargeObject(K key, InputStream largeObject)
OutputStream writeToKey(K key) ->
OutputStream newLargeObject(K key)
InputStream readFromKey(K key) ->
InputStream getLargeObject(K key)
boolean removeKey(K key) ->
boolean removeLargeObject(K key)
Rationale: The API should center around large objects, not their keys
and method names should reflect this.
Thoughts?
Cheers,
Olaf
15 years
Re: [infinispan-dev] clustered nodes not receiving TextMessage published on TOPIC in HornetQ
by Pavana Kumari
Hi
I am running two nodes(say node1 and node2), which are in cluster. One node(node1) publishing Text Message on TOPIC. Node1 and node2 acts as subscribers on same TOPIC but node2 is unable to receive subscribed messages.
Regards
Pavana
DISCLAIMER: This email message and all attachments are confidential and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify us immediately by return email or to mailadmin(a)spanservices.com and destroy the original message. Opinions, conclusions and other information in this message that do not relate to the official business of SPAN, shall be understood to be neither given nor endorsed by SPAN.
15 years
JGroupsDistSync and ISPN-83
by Vladimir Blagojevic
Hi,
Would you please confirm my understanding and reading of javadoc for
ReentrantReadWriteLock under section for "lock downgrading". It says:
"Reentrancy also allows downgrading from the write lock to a read lock,
by acquiring the write lock, then the read lock and then releasing the
write lock. However, upgrading from a read lock to the write lock is not
possible." ReentrantReadWriteLock javadoc code example with class
CacheData also shows how a thread owning a read lock first has to
release it in order to obtain a write lock! So a thread owning a read
lock first has to release a read lock in order to obtain a write lock?
This is very symptomatic in logs of ISPN-83 such as this one
https://issues.jboss.org/secure/attachment/12341409/server1.log
Recall how FLUSH stops all invocations on cluster and therefore all read
lock acquisitions in JGroupsDistSync ultimately enabling smooth write
lock acquisitions for state transfer and what not. In conclusion this
leads me wondering if the culprit of all this FLUSH mess is rooted in
read/write lock semantics from above?
Regards,
Vladimir
15 years
Compilation errors in the infinispan-spring module
by Dan Berindei
Hi Olaf,
Did you see any problems with RHQ + Spring interaction that determined
you to exclude the rhq-pluginAnnotations dependency in the spring
module?
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>infinispan-core</artifactId>
<version>${project.version}</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<groupId>org.rhq.helpers</groupId>
<artifactId>rhq-pluginAnnotations</artifactId>
</exclusion>
</exclusions>
</dependency>
I've been getting some weird errors while building the
infinispan-spring module, both with OpenJDK 1.6.0_20 and with Sun JDK
1.6.0_24 and 1.6.0_25, and they seem to appear because the compiler
doesn't have access to the RHQ annotations:
/tmp/privatebuild/home/dan/Work/infinispan/master/core/classes/org/infinispan/manager/DefaultCacheManager.class:
warning: Cannot find annotation method 'displayName()' in type
'org.rhq.helpers.pluginAnnotations.agent.Metric': class file for
org.rhq.helpers.pluginAnnotations.agent.Metric not found
/tmp/privatebuild/home/dan/Work/infinispan/master/core/classes/org/infinispan/manager/DefaultCacheManager.class:
warning: Cannot find annotation method 'dataType()' in type
'org.rhq.helpers.pluginAnnotations.agent.Metric'
An exception has occurred in the compiler (1.6.0_24). Please file a
bug at the Java Developer Connection
(http://java.sun.com/webapps/bugreport) after checking the Bug Parade
for duplicates. Include your program and the following diagnostic in
your report. Thank you.
com.sun.tools.javac.code.Symbol$CompletionFailure: class file for
org.rhq.helpers.pluginAnnotations.agent.DataType not found
Galder has seen it too with Sun JDK 1.6.0_24, but strangely enough
everyone else is able to build without any errors.
I'm thinking of removing the rhq-pluginAnnotations exclusion from the
infinispan-spring pom.xml, the question is whether this would break
something on the Spring side. Do you know of any potential problems,
or did you do this just to reduce the number of dependencies brought
in by infinispan-spring into an application?
Cheers
Dan
15 years
Hot Rod protocol improvements JIRA
by Galder Zamarreño
Guys,
I've create https://issues.jboss.org/browse/ISPN-1090 to track improvements required to the Hot Rod protocol for the next version. I've added a couple that had been in my head for a while.
If you think of any improvements that the protocol needs, make sure you add them there for when we next tackle new functionality in the protocol (i.e. remote querying, or even listeners,...etc)
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
15 years
cache name in logs
by Mircea Markus
Hi,
I'm looking into some logs for the a JBW demo : it has 4 caches deployed on each node and lots of topology changes happen. It's close to impossible to tell which log pertains to which cache, especially around the DistributionInterceptorImpl.
Wouldn't it make sense that, for certain components, to include the name of the cache in the logs? IThis might be achieved with minimal changes by adding an additional param to the LogFactory.getLog(Class) method and let the logger itself do the heavy lifting.
e.g.
Log l = LogFactory.getLog(DistributionManagerImpl.class, "cacheName");
and on each call l.trace("A message") the logger might output, besides underlying log's format, the string "[cacheName] A message".
Wdyt?
Cheers,
Mircea
15 years
IDEA:building non-OSGi libraries...
by Mircea Markus
Hi,
Whenever I'm switching branches from 4.2.x to master the build in IDEA takes ages(even more, about 5 mins!!!). Most of the time is spent is "Building non-OSGi libraries for module..."
Any idea on what can be done to speed things up?
Cheers,
Mircea
15 years
