[JBoss JIRA] Created: (ISPN-944) RemoteCacheManager.getCache() should be friendlier when cache does not exist
9:46 a.m.
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
9:51 a.m.
New subject: [JBoss JIRA] Work started: (ISPN-944) RemoteCacheManager.getCache() should be friendlier when cache does not exist
[
https://issues.jboss.org/browse/ISPN-944?page=com.atlassian.jira.plugin.s...
]
Work on ISPN-944 started by Galder Zamarreño.
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.0.Final, 4.2.1.CR3
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Labels: hotrod,
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
3:03 a.m.
New subject: [JBoss JIRA] Commented: (ISPN-944) RemoteCacheManager.getCache() should be friendlier when cache does not exist
[
https://issues.jboss.org/browse/ISPN-944?page=com.atlassian.jira.plugin.s...
]
Galder Zamarreño commented on ISPN-944:
---------------------------------------
There's a couple of things that are not right here:
"Exception in thread "main"
org.infinispan.client.hotrod.exceptions.HotRodClientException: id [2] code [133] "
According to the code, that exception should show the error message from the server, i.e.
"Cache with name 'Undefined1234' not found amongst the configured
caches", but it's not doing so.
The other thing that's not very user friendly is "id [2] code [133] ", that
should say: "Put response (opcode=2) returned server error (status=0x85): ..." -
I'm opening a separate JIRA for this.
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.0.Final, 4.2.1.CR3
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Labels: hotrod,
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
3:10 a.m.
New subject: [JBoss JIRA] Updated: (ISPN-944) RemoteCacheManager.getCache() should be friendlier when cache does not exist
[
https://issues.jboss.org/browse/ISPN-944?page=com.atlassian.jira.plugin.s...
]
Galder Zamarreño updated ISPN-944:
----------------------------------
Labels: hotrod java_hotrod_client (was: hotrod,)
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.0.Final, 4.2.1.CR3
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Labels: hotrod, java_hotrod_client
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
3:50 a.m.
New subject: [JBoss JIRA] Updated: (ISPN-944) Server error messages not being returned to clients
[
https://issues.jboss.org/browse/ISPN-944?page=com.atlassian.jira.plugin.s...
]
Galder Zamarreño updated ISPN-944:
----------------------------------
Summary: Server error messages not being returned to clients (was:
RemoteCacheManager.getCache() should be friendlier when cache does not exist)
Server error messages not being returned to clients
---------------------------------------------------
Key: ISPN-944
URL: https://issues.jboss.org/browse/ISPN-944
Project: Infinispan
Issue Type: Bug
Components: Cache Server
Affects Versions: 4.2.0.Final, 4.2.1.CR3
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Labels: hotrod, java_hotrod_client
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
3:54 a.m.
New subject: [JBoss JIRA] Commented: (ISPN-944) Server error messages not being returned to clients
[
https://issues.jboss.org/browse/ISPN-944?page=com.atlassian.jira.plugin.s...
]
Galder Zamarreño commented on ISPN-944:
---------------------------------------
https://github.com/infinispan/infinispan/pull/180
Server error messages not being returned to clients
---------------------------------------------------
Key: ISPN-944
URL: https://issues.jboss.org/browse/ISPN-944
Project: Infinispan
Issue Type: Bug
Components: Cache Server
Affects Versions: 4.2.0.Final, 4.2.1.CR3
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Labels: hotrod, java_hotrod_client
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
8:14 a.m.
New subject: [JBoss JIRA] Resolved: (ISPN-944) Server error messages not being returned to clients
[
https://issues.jboss.org/browse/ISPN-944?page=com.atlassian.jira.plugin.s...
]
Sanne Grinovero resolved ISPN-944.
----------------------------------
Resolution: Done
Server error messages not being returned to clients
---------------------------------------------------
Key: ISPN-944
URL: https://issues.jboss.org/browse/ISPN-944
Project: Infinispan
Issue Type: Bug
Components: Cache Server
Affects Versions: 4.2.0.Final, 4.2.1.CR3
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Labels: hotrod, java_hotrod_client
Fix For: 4.2.1.FINAL, 5.0.0.BETA1
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
8:14 a.m.
New subject: [JBoss JIRA] Updated: (ISPN-944) Server error messages not being returned to clients
[
https://issues.jboss.org/browse/ISPN-944?page=com.atlassian.jira.plugin.s...
]
Sanne Grinovero updated ISPN-944:
---------------------------------
Fix Version/s: 5.0.0.BETA1
Server error messages not being returned to clients
---------------------------------------------------
Key: ISPN-944
URL: https://issues.jboss.org/browse/ISPN-944
Project: Infinispan
Issue Type: Bug
Components: Cache Server
Affects Versions: 4.2.0.Final, 4.2.1.CR3
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Labels: hotrod, java_hotrod_client
Fix For: 4.2.1.FINAL, 5.0.0.BETA1
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
6:24 a.m.
New subject: [JBoss JIRA] Updated: (ISPN-944) Server error messages not being returned to clients
[
https://issues.jboss.org/browse/ISPN-944?page=com.atlassian.jira.plugin.s...
]
Manik Surtani updated ISPN-944:
-------------------------------
Fix Version/s: 4.2.1.CR4
Server error messages not being returned to clients
---------------------------------------------------
Key: ISPN-944
URL: https://issues.jboss.org/browse/ISPN-944
Project: Infinispan
Issue Type: Bug
Components: Cache Server
Affects Versions: 4.2.0.Final, 4.2.1.CR3
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Labels: hotrod, java_hotrod_client
Fix For: 4.2.1.CR4, 4.2.1.FINAL, 5.0.0.BETA1
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
10:36 a.m.
New subject: [JBoss JIRA] Updated: (ISPN-944) Server error messages not being returned to clients
[
https://issues.jboss.org/browse/ISPN-944?page=com.atlassian.jira.plugin.s...
]
Galder Zamarreño updated ISPN-944:
----------------------------------
Fix Version/s: 5.0.0.ALPHA4
(was: 5.0.0.BETA1)
Server error messages not being returned to clients
---------------------------------------------------
Key: ISPN-944
URL: https://issues.jboss.org/browse/ISPN-944
Project: Infinispan
Issue Type: Bug
Components: Cache Server
Affects Versions: 4.2.0.Final, 4.2.1.CR3
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Labels: hotrod, java_hotrod_client
Fix For: 4.2.1.CR4, 4.2.1.FINAL, 5.0.0.ALPHA4
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
4803
days inactive
4837
days old
infinispan-issues@lists.jboss.org
9 comments
3 participants
participants (3)
-
Galder Zamarreño (JIRA) -
Manik Surtani (JIRA)
-
Sanne Grinovero (JIRA)