[JBoss JIRA] Created: (ISPN-833) Revisit cache name predefinition limitation for cache servers
by Galder Zamarreño (JIRA)
Revisit cache name predefinition limitation for cache servers
-------------------------------------------------------------
Key: ISPN-833
URL: https://issues.jboss.org/browse/ISPN-833
Project: Infinispan
Issue Type: Feature Request
Components: Cache Server
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Fix For: 5.0.0.BETA1, 5.0.0.Final
There're are two primary reasons why Infinispan servers require predefined caches to be started up on startup, and do not allow invocations to undefined caches:
1. Concurrent cache startups were resulting in NPEs (ISPN-635) - This is already solved since the 4.2.x days.
2. Infinispan has issues dealing with asymmetric clusters (ISPN-658).
Once these two issues have been resolved, revisit the limitation.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] Created: (ISPN-847) Eviction with strategy but no maxEntries does not make sense
by Galder Zamarreño (JIRA)
Eviction with strategy but no maxEntries does not make sense
------------------------------------------------------------
Key: ISPN-847
URL: https://issues.jboss.org/browse/ISPN-847
Project: Infinispan
Issue Type: Bug
Components: Configuration, Eviction
Affects Versions: 5.0.0.ALPHA1, 4.2.0.Final
Reporter: Galder Zamarreño
Assignee: Vladimir Blagojevic
Priority: Minor
Fix For: 5.0.0.BETA1, 5.0.0.Final
A configuration like this can be confusing cos no maxEntries is set, and without it there's no trigger to start evicting stuff:
<default>
<eviction strategy="FIFO" wakeUpInterval="6000" /><!-- 6 seconds -->
</default>
So, we should come up with some WARN/ERROR message indicating that maxEntries is missing unless NONE strategy is used.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] Created: (ISPN-942) Add an (automatic) validation process to infinispan releases
by Mircea Markus (JIRA)
Add an (automatic) validation process to infinispan releases
-------------------------------------------------------------
Key: ISPN-942
URL: https://issues.jboss.org/browse/ISPN-942
Project: Infinispan
Issue Type: Task
Affects Versions: 4.2.1.CR3
Reporter: Mircea Markus
Assignee: Manik Surtani
Fix For: 4.2.1.FINAL
In order to avoid problems with releases a release validation process should be created. The following problems were encountered in the past and should be checked by this release process:
- incorrect XSD (ISPN-934)
- upload problems to SF (e.g. today the release script silently failed to upload the binaries to SF as they changed their certificate)
- wrong binaries being deployed under the "right" name(e.g. a 4.x release was performed from trunk and not from the 4.2.x branch)
Any others?
All these cause a lot of community frustration and time to debug and fix.
These can potentially be automated.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] Created: (ISPN-898) Migrate Hudson from DummyTM to JBossTM
by Mircea Markus (JIRA)
Migrate Hudson from DummyTM to JBossTM
---------------------------------------
Key: ISPN-898
URL: https://issues.jboss.org/browse/ISPN-898
Project: Infinispan
Issue Type: Feature Request
Components: Transactions
Affects Versions: 4.2.0.Final
Reporter: Mircea Markus
Assignee: Mircea Markus
Fix For: 5.0.0.BETA1
This implies fixing some tests as well. These tests failed on migration:
>>> org.infinispan.api.mvcc.PutForExternalReadTest.org.infinispan.api.mvcc.PutForExternalReadTest-testMemLeakOnSuspendedTransactions 30.021 3
>>> org.infinispan.api.mvcc.repeatable_read.RepeatableReadLockTest.org.infinispan.api.mvcc.repeatable_read.RepeatableReadLockTest-testRepeatableReadWithNullRemoval 0.0030 3
>>> org.infinispan.distribution.InvalidationFailureTest.org.infinispan.distribution.InvalidationFailureTest-testH1Invalidated 0.0050 3
>>> org.infinispan.distribution.SyncDistImplicitLockingTest.org.infinispan.distribution.SyncDistImplicitLockingTest-testReplaceNonExistentKey 0.375 3
>>> org.infinispan.jmx.TxInterceptorMBeanTest.org.infinispan.jmx.TxInterceptorMBeanTest-testCommit 0.0030 3
>>> org.infinispan.jmx.TxInterceptorMBeanTest.org.infinispan.jmx.TxInterceptorMBeanTest-testRemoteCommit 0.0020 3
>>> org.infinispan.lock.EagerLockingSingleLockTest.org.infinispan.lock.EagerLockingSingleLockTest-testLockOwnerFailure 0.5 3
>>> org.infinispan.replication.AsyncReplTest.org.infinispan.replication.AsyncReplTest-testWithTx 0.049 3
>>> org.infinispan.replication.SyncReplImplicitLockingTest.org.infinispan.replication.SyncReplImplicitLockingTest-testReplaceNonExistentKey 0.394 3
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] Created: (ISPN-868) Running out of memory using Infinispan after adding a small number of entities
by Tom Waterhouse (JIRA)
Running out of memory using Infinispan after adding a small number of entities
------------------------------------------------------------------------------
Key: ISPN-868
URL: https://issues.jboss.org/browse/ISPN-868
Project: Infinispan
Issue Type: Bug
Affects Versions: 4.2.0.Final
Environment: JBossJTA 4.14.0/Hibernate 3.6.0.Final/Spring 3.0.5
Reporter: Tom Waterhouse
Assignee: Manik Surtani
While running a load test data builder for our application we ran out of memory very quickly. A simple test case (attached) was created to duplicate the issue. We found running the simple test case illustrates that Infinispan uses a large amount of heap space.
As a reference the same test was run using EHCache 2.2. Memory usage was much lower; we never ran out of heap space. Note that EHCache was used as a reference only, our goal is to go to production with Infinispan.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] Created: (ISPN-943) Websocket demo not working
by Galder Zamarreño (JIRA)
Websocket demo not working
--------------------------
Key: ISPN-943
URL: https://issues.jboss.org/browse/ISPN-943
Project: Infinispan
Issue Type: Bug
Affects Versions: 4.2.1.CR3, 4.2.0.Final
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Fix For: 4.2.1.FINAL
>From Burr:
"I am trying to build a websocket prototype/demo. That means I am looking at things like Jetty, Resin and Kaazing. AND I would love it if I could just make the demo work with Infinispan - since the final demo vision calls for Infinispan anyway.
However, with 4.2 - I can't make it work - my guess is the config is off some place.
Steps:
1) startserver -r websocket
2) Open file://localhost/D:/tools/infinispan-4.2.0.FINAL/etc/sample-websocket-client.html
in Opera (with WS enabled) or Chrome
3) Put "Hello" and "World"
4) clear out "World"
5) Get "Hello"
But nothing happens, no error messages on the console nor browser for Opera
with Chrome I get keyChange is not defined and cache is not defined
Visiting http://localhost:8181/infinispan-ws.js in Chrome does return the JS so the server is responding."
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] Created: (ISPN-897) Error message during start multi-nodes cluster
by Changgeng Li (JIRA)
Error message during start multi-nodes cluster
----------------------------------------------
Key: ISPN-897
URL: https://issues.jboss.org/browse/ISPN-897
Project: Infinispan
Issue Type: Enhancement
Components: Core API
Affects Versions: 4.2.1.CR1
Reporter: Changgeng Li
Assignee: Manik Surtani
When start a multiple nodes environment, you may find the following error message:
ERROR [org.infinispan.remoting.InboundInvocationHandlerImpl] Defined caches: [StreamingDeviceCache, TOPOLOGY_QAMNAMETOSERVICEGROUPID, TOPOLOGY_DEVICE, VAID, ASSETINFO_LOCAL_CACHE, CONTENT_VOLUME_LOCAL_CACHE, TOPOLOGY_EDGEDEVICEINPUT, TOPOLOGY_SERVICEGROUP, ODRM_SESSION, eigAllocation, PAID, clientIdToSessionId, exclusion, TOPOLOGY_STREAMINGDEVICE, sopAllocation, TOPOLOGY_QAM, qamAllocation, STREAMING_CONTENT, content, SERVICE_GROUP, billing, accountIdToSessionId, TOPOLOGY_EDGEDEVICE, session, POILIST, TOPOLOGY_SOPGROUP, VAID_LOCAL_CACHE]
This is actually not an ERROR, but it confuse our QA people.
Maybe we can change it to WARN level.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] Created: (ISPN-947) Java Hot Rod client exceptions should be more user friendly
by Galder Zamarreño (JIRA)
Java Hot Rod client exceptions should be more user friendly
-----------------------------------------------------------
Key: ISPN-947
URL: https://issues.jboss.org/browse/ISPN-947
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
Java Hot Rod client exceptions are not friendly:
{code}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]{code}
What is that suppose to mean to clients? The following is much more friendly:
{code}WARNING: Error status received from the server: for message put response (opcode=0x02)
Exception in thread "main" org.infinispan.client.hotrod.exceptions.HotRodClientException: Put response (opcode=0x02) returned server error (status=0x85): ...{code}
This is related to ISPN-944 which should solve the fact that server error messages are not being read by the client properly.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months