Details
-
Bug
-
Resolution: Done
-
Major
-
4.2.0.Final, 4.2.1.CR3
-
Low
Description
When a Java Hot Rod client requests a non-existing cache, RemoteCacheManager throws a rather cryptic exception:
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)
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.
Attachments
Issue Links
- relates to
-
-
- Closed
-
