[JBoss JIRA] (ISPN-2057) Allow storage of Lucene indexes in an indexed cache
by Sanne Grinovero (JIRA)
Sanne Grinovero created ISPN-2057:
-------------------------------------
Summary: Allow storage of Lucene indexes in an indexed cache
Key: ISPN-2057
URL: https://issues.jboss.org/browse/ISPN-2057
Project: Infinispan
Issue Type: Enhancement
Components: Lucene Directory, Querying
Reporter: Sanne Grinovero
Assignee: Sanne Grinovero
Fix For: 5.2.0.ALPHA1
I think it should be better to keep them using separate caches, still it's easier for many cases in which top efficiency is not required to allow this.
(Today you'd get an exception similar to:
{quote}
java.lang.IllegalArgumentException: Indexing only works with entries keyed on Strings, primitives and classes that have the @Transformable annotation - you passed in a class org.infinispan.lucene.FileListCacheKey.{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (ISPN-2139) ping_on_startup ignored
by Michal Linhard (JIRA)
Michal Linhard created ISPN-2139:
------------------------------------
Summary: ping_on_startup ignored
Key: ISPN-2139
URL: https://issues.jboss.org/browse/ISPN-2139
Project: Infinispan
Issue Type: Bug
Affects Versions: 5.1.5.FINAL
Reporter: Michal Linhard
Assignee: Manik Surtani
When a configuration property
infinispan.client.hotrod.ping_on_startup=false
is passed to the properties of RemoteCacheManager, this
avoids ping in RemoteCacheManager.start() but
RemoteCacheManager.getCache() does ping without checking this property
and thus rendering this setting useless for scenario
where we want to specify
infinispan.client.hotrod.server_list
with list of servers with some of the servers possibly not available yet.
In such case we would expect the client to failover to first working server
and retrying the first operation we want to do with the cache.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (ISPN-2032) MarshalledValue improvements
by Manik Surtani (JIRA)
Manik Surtani created ISPN-2032:
-----------------------------------
Summary: MarshalledValue improvements
Key: ISPN-2032
URL: https://issues.jboss.org/browse/ISPN-2032
Project: Infinispan
Issue Type: Enhancement
Components: Core API, Marshalling
Affects Versions: 5.1.4.FINAL
Reporter: Manik Surtani
Assignee: Galder Zamarreño
Fix For: 5.1.x, 5.2.0.ALPHA1, 5.2.0.FINAL
Improve MarshalledValues by using custom streams (instead of ExposedByteArrayOutputStream) which incurs a penalty of the JDK's BAOS constructor when allocating the initial byte array which is then thrown away. This patch also changes the signature of getRaw() to return the reusable buffer and prevent an unnecessary array copy.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (ISPN-2096) Duplicate join requests break destabilizes the cluster
by Dan Berindei (JIRA)
Dan Berindei created ISPN-2096:
----------------------------------
Summary: Duplicate join requests break destabilizes the cluster
Key: ISPN-2096
URL: https://issues.jboss.org/browse/ISPN-2096
Project: Infinispan
Issue Type: Bug
Components: State transfer
Affects Versions: 5.1.5.FINAL
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 5.2.0.ALPHA1
When the coordinator receives a {{CacheViewControlCommand(REQUEST_JOIN)}} command from a node that's already a member of the cache, it should just ignore it. Currently it tries to install a new cache view with a duplicate member, and the new cache view installation fails with this error:
{noformat}
[13:37:08,442] [WARN] (CacheViewControlCommand.java:141) - ISPN000071: Caught exception when handling command CacheViewControlCommand{cache=Demo, type=PREPARE_VIEW, sender=ppl-poz-nb0074/testy, newViewId=2, newMembers=[PPL-POZ-NB0074-33316, PPL-POZ-NB0074-33316], oldViewId=1, oldMembers=[PPL-POZ-NB0074-33316]}
java.lang.IllegalStateException: Cannot prepare new view CacheView{viewId=2, members=[PPL-POZ-NB0074-33316, PPL-POZ-NB0074-33316]} on cache Demo, we are currently preparing view CacheView{viewId=2, members=[PPL-POZ-NB0074-33316, PPL-POZ-NB0074-33316]}
at org.infinispan.cacheviews.CacheViewInfo.prepareView(CacheViewInfo.java:102)
at org.infinispan.cacheviews.CacheViewsManagerImpl.handlePrepareView(CacheViewsManagerImpl.java:481)
at org.infinispan.commands.control.CacheViewControlCommand.perform(CacheViewControlCommand.java:126)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (ISPN-1948) Invalid magic number
by Michal Linhard (JIRA)
Michal Linhard created ISPN-1948:
------------------------------------
Summary: Invalid magic number
Key: ISPN-1948
URL: https://issues.jboss.org/browse/ISPN-1948
Project: Infinispan
Issue Type: Bug
Affects Versions: 5.1.3.CR1
Reporter: Michal Linhard
Assignee: Galder Zamarreño
Here we have the good old "invalid magic number" problem again (JDG 6.0.0.ER5 testing):
https://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-REPORTS-RESILIENCE/...
{code}
2012-03-26 15:18:43,524 253444 ERROR [org.jboss.smartfrog.edg.loaddriver.DriverNode] (Client-477:) Error doing PUT(key410977) to node node02 (lastOpTime 1 ms)
org.infinispan.client.hotrod.exceptions.InvalidResponseException:: Invalid magic number. Expected 0xa1 and received 0x0
at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:92)
at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:78)
at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:72)
at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:52)
at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:41)
at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:68)
at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:219)
at org.infinispan.CacheSupport.put(CacheSupport.java:52)
at org.jboss.qa.edg.adapter.HotRodAdapter$HotRodRemoteCacheAdapter.put(HotRodAdapter.java:249)
at org.jboss.qa.edg.adapter.HotRodAdapter$HotRodRemoteCacheAdapter.put(HotRodAdapter.java:234)
at org.jboss.smartfrog.edg.loaddriver.DriverNodeImpl$ClientThread.makeRequest(DriverNodeImpl.java:244)
at org.jboss.smartfrog.edg.loaddriver.DriverNodeImpl$ClientThread.run(DriverNodeImpl.java:375)
{code}
The exception repeats many times in the log and the "received" part of "Expected 0xa1 and received 0xXX" takes on different values.
Also happens in both PUT and GET operations.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] Created: (ISPN-1346) Transactional listeners method order problem
by Tomas Fecko (JIRA)
Transactional listeners method order problem
--------------------------------------------
Key: ISPN-1346
URL: https://issues.jboss.org/browse/ISPN-1346
Project: Infinispan
Issue Type: Bug
Components: Listeners
Affects Versions: 5.0.0.FINAL
Environment: fedora, windows
Reporter: Tomas Fecko
Assignee: Manik Surtani
I'm using listeners as from the @Listener javadoc examples. When I register listener on VM where the cache is and put items to it, the methods of my listener are called in this order:
@TransactionRegistered
startTransaction
@CacheEntryCreated
handleEvent
@CacheEntryCreated
handleEvent
@TransactionCompleted
endTransaction
which is as it should be, but when I register listener on second node, and put to cache in first node, methods on listener on second node are called in order:
handleEvent
handleEvent
startTransaction
endTransaction
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months