[JBoss JIRA] Created: (JBCACHE-752) Look into using JBC Marshaller implementations for responses as well as requests
9:51 a.m.
Look into using JBC Marshaller implementations for responses as well as requests
--------------------------------------------------------------------------------
Key: JBCACHE-752
URL: http://jira.jboss.com/jira/browse/JBCACHE-752
Project: JBoss Cache
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Replication
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: 2.0.0
In JGroups 2.4 the ability to use a Marshaller for responses as well as requests was
added. At some point JGroups may require that the *same* marshaller instance handle both.
JBC's current marshallers can't do this; need to look into what it would take to
do it.
Should be simple, as RPC responses in JBC are either null, an exception, or a byte[] (for
RPC based state transfer).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:37 a.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-752) Look into using JBC Marshaller implementations for responses as well as requests
[ http://jira.jboss.com/jira/browse/JBCACHE-752?page=comments#action_12342321 ]
Manik Surtani commented on JBCACHE-752:
---------------------------------------
Currently, all RPC calls go through the VersionAwareMarshaller.
Correct that most RPC calls in JBoss Cache do not have return values so this is not a
problem that comes up often, but certain features (clustered cache loader, data
gravitation in buddy replication) rely on return values.
Look into using JBC Marshaller implementations for responses as well
as requests
--------------------------------------------------------------------------------
Key: JBCACHE-752
URL: http://jira.jboss.com/jira/browse/JBCACHE-752
Project: JBoss Cache
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Replication
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: 2.0.0
In JGroups 2.4 the ability to use a Marshaller for responses as well as requests was
added. At some point JGroups may require that the *same* marshaller instance handle both.
JBC's current marshallers can't do this; need to look into what it would take to
do it.
Should be simple, as RPC responses in JBC are either null, an exception, or a byte[] (for
RPC based state transfer).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:53 a.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-752) Look into using JBC Marshaller implementations for responses as well as requests
[ http://jira.jboss.com/jira/browse/JBCACHE-752?page=comments#action_12343243 ]
Manik Surtani commented on JBCACHE-752:
---------------------------------------
See JBCACHE-766.
Some methods - put(fqn, key, value) and remove(fqn, key) - return the old value of the
attribute. Thi sreturn value is only used in the "local" version of the method.
The return value is not used in "remote" versions.
Returning nulls for these (if remote) will simplify classloading and improve marshalling
(of return values) performance, and reduce network traffic.
Look into using JBC Marshaller implementations for responses as well
as requests
--------------------------------------------------------------------------------
Key: JBCACHE-752
URL: http://jira.jboss.com/jira/browse/JBCACHE-752
Project: JBoss Cache
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Replication
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: 2.0.0
In JGroups 2.4 the ability to use a Marshaller for responses as well as requests was
added. At some point JGroups may require that the *same* marshaller instance handle both.
JBC's current marshallers can't do this; need to look into what it would take to
do it.
Should be simple, as RPC responses in JBC are either null, an exception, or a byte[] (for
RPC based state transfer).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:01 a.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-752) Look into using JBC Marshaller implementations for responses as well as requests
[ http://jira.jboss.com/jira/browse/JBCACHE-752?page=comments#action_12343245 ]
Manik Surtani commented on JBCACHE-752:
---------------------------------------
Note that JBCACHE-766 was only applied to the 1.4.0 branch - not the 2.0.0 one
Look into using JBC Marshaller implementations for responses as well
as requests
--------------------------------------------------------------------------------
Key: JBCACHE-752
URL: http://jira.jboss.com/jira/browse/JBCACHE-752
Project: JBoss Cache
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Replication
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: 2.0.0
In JGroups 2.4 the ability to use a Marshaller for responses as well as requests was
added. At some point JGroups may require that the *same* marshaller instance handle both.
JBC's current marshallers can't do this; need to look into what it would take to
do it.
Should be simple, as RPC responses in JBC are either null, an exception, or a byte[] (for
RPC based state transfer).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:04 p.m.
New subject: [JBoss JIRA] Updated: (JBCACHE-752) Look into using JBC Marshaller implementations for responses as well as requests
[ http://jira.jboss.com/jira/browse/JBCACHE-752?page=all ]
Brian Stansberry updated JBCACHE-752:
-------------------------------------
Fix Version/s: 2.0.0.BETA1
(was: 2.0.0.GA)
Assignee: Manik Surtani (was: Brian Stansberry)
Manik, will you be able to look at this, or maybe ask Galder? If not, assign back to me.
Look into using JBC Marshaller implementations for responses as well
as requests
--------------------------------------------------------------------------------
Key: JBCACHE-752
URL: http://jira.jboss.com/jira/browse/JBCACHE-752
Project: JBoss Cache
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Replication
Reporter: Brian Stansberry
Assigned To: Manik Surtani
Fix For: 2.0.0.BETA1
In JGroups 2.4 the ability to use a Marshaller for responses as well as requests was
added. At some point JGroups may require that the *same* marshaller instance handle both.
JBC's current marshallers can't do this; need to look into what it would take to
do it.
Should be simple, as RPC responses in JBC are either null, an exception, or a byte[] (for
RPC based state transfer).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:28 p.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-752) Look into using JBC Marshaller implementations for responses as well as requests
[ http://jira.jboss.com/jira/browse/JBCACHE-752?page=comments#action_12349844 ]
Manik Surtani commented on JBCACHE-752:
---------------------------------------
I'll take care of it. Linked it to a bigger issue about using marshallers
consistently.
Look into using JBC Marshaller implementations for responses as well
as requests
--------------------------------------------------------------------------------
Key: JBCACHE-752
URL: http://jira.jboss.com/jira/browse/JBCACHE-752
Project: JBoss Cache
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Replication
Reporter: Brian Stansberry
Assigned To: Manik Surtani
Fix For: 2.0.0.BETA1
In JGroups 2.4 the ability to use a Marshaller for responses as well as requests was
added. At some point JGroups may require that the *same* marshaller instance handle both.
JBC's current marshallers can't do this; need to look into what it would take to
do it.
Should be simple, as RPC responses in JBC are either null, an exception, or a byte[] (for
RPC based state transfer).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:20 a.m.
New subject: [JBoss JIRA] Closed: (JBCACHE-752) Look into using JBC Marshaller implementations for responses as well as requests
[ http://jira.jboss.com/jira/browse/JBCACHE-752?page=all ]
Manik Surtani closed JBCACHE-752.
---------------------------------
Resolution: Done
Look into using JBC Marshaller implementations for responses as well
as requests
--------------------------------------------------------------------------------
Key: JBCACHE-752
URL: http://jira.jboss.com/jira/browse/JBCACHE-752
Project: JBoss Cache
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Replication
Reporter: Brian Stansberry
Assigned To: Manik Surtani
Fix For: 2.0.0.BETA1
In JGroups 2.4 the ability to use a Marshaller for responses as well as requests was
added. At some point JGroups may require that the *same* marshaller instance handle both.
JBC's current marshallers can't do this; need to look into what it would take to
do it.
Should be simple, as RPC responses in JBC are either null, an exception, or a byte[] (for
RPC based state transfer).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6489
days inactive
6628
days old
6 comments
2 participants
participants (2)
-
Brian Stansberry (JIRA) -
Manik Surtani (JIRA)