[
https://issues.apache.org/jira/browse/UIMA-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654937#action_12654937
]
Marshall Schor commented on UIMA-1227:
--------------------------------------
I think that at initialization time, a service already returns the type system
it is using in its getMeta reply; the client already uses this information as
an input to create its merged type system. So the information needed to
implement this test is already available at the client, and there is no need to
send anything extra, or to send a hashcode, etc.
Perhaps the merge code, which already needs to compare the service's type
system with the one its building up (in order to merge it), could be modified
to do this verification?
> Help users debug binary CAS serialization problems
> --------------------------------------------------
>
> Key: UIMA-1227
> URL: https://issues.apache.org/jira/browse/UIMA-1227
> Project: UIMA
> Issue Type: Improvement
> Components: Async Scaleout
> Reporter: Eddie Epstein
>
> In order to use binary CAS serialization for remote services, both client and
> service must have identical type systems. If not the same, binary
> deserialization is likely to throw exceptions. The service request handler
> should catch these exceptions when using binary deserialization and add
> message suggesting a likely cause of the problem: unequal type systems.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
