You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Eddie Epstein (JIRA)" <ui...@incubator.apache.org> on 2008/11/07 18:06:45 UTC

[jira] Created: (UIMA-1227) Help users debug binary CAS serialization problems

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.


[jira] Commented: (UIMA-1227) Help users debug binary CAS serialization problems

Posted by "Marshall Schor (JIRA)" <ui...@incubator.apache.org>.
    [ 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.


[jira] Commented: (UIMA-1227) Help users debug binary CAS serialization problems

Posted by "Eddie Epstein (JIRA)" <ui...@incubator.apache.org>.
    [ https://issues.apache.org/jira/browse/UIMA-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649933#action_12649933 ] 

Eddie Epstein commented on UIMA-1227:
-------------------------------------

Will a compatible hashcode be a problem for non-Java services?

yes, the binary version of the typesystem should be human readable strings.
All that is necessary should be:

Types: 1:uima.cas.TOP, 2:uima.cas.Integer, 3:uima.cas.Float, 4:uima.cas.String, ...
Features: 1:uima.cas.NonEmptyFSList:head, 2:uima.cas.NonEmptyFSList:tail, ...
FeatureRangeTypes: 1, 11, 3, 14, 2, 17, 4, 20, 2, 4, 4, 1, 4, ...

Other parts of the CAS definition may still be different, such as the type hierarchy. Do we care?


> 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.


[jira] Commented: (UIMA-1227) Help users debug binary CAS serialization problems

Posted by "Marshall Schor (JIRA)" <ui...@incubator.apache.org>.
    [ https://issues.apache.org/jira/browse/UIMA-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649477#action_12649477 ] 

Marshall Schor commented on UIMA-1227:
--------------------------------------

If it was an issue, instead of returning the whole type system in some binary format, we could compute a hashcode for the type system on both sides, and send that over for comparison.

> 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.


[jira] Updated: (UIMA-1227) Help users debug binary CAS serialization problems

Posted by "Marshall Schor (JIRA)" <ui...@incubator.apache.org>.
     [ https://issues.apache.org/jira/browse/UIMA-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marshall Schor updated UIMA-1227:
---------------------------------

    Affects Version/s: 2.3AS

deferred beyond 2.3.0 release - requires changes to core to support comparing type systems

> 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
>    Affects Versions: 2.3AS
>            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.


[jira] Commented: (UIMA-1227) Help users debug binary CAS serialization problems

Posted by "Burn Lewis (JIRA)" <ui...@incubator.apache.org>.
    [ https://issues.apache.org/jira/browse/UIMA-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649526#action_12649526 ] 

Burn Lewis commented on UIMA-1227:
----------------------------------

If we construct the getMeta reply on each service by serializing its binary typesystem, then comparing the string form of the typesystem should be equivalent to comparing the binary form.  And require no changes to the message formats.


> 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.


[jira] Commented: (UIMA-1227) Help users debug binary CAS serialization problems

Posted by "Eddie Epstein (JIRA)" <ui...@incubator.apache.org>.
    [ https://issues.apache.org/jira/browse/UIMA-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647001#action_12647001 ] 

Eddie Epstein commented on UIMA-1227:
-------------------------------------

In conversation, Bhavani has pointed out that type system differences may not cause exceptions during CAS serialization, but only later, during access to CAS feature structures either in service code or back in client code. She suggested that the better way of handling this problem is to verify at initialization that the service has an identical type system. 

A protocol would be something like this:

1. For services marked to use binary serialization, this info would be sent to the service on the getMeta call. In return, the getMeta reply would contain a binary version of the type system, as arrays of type codes, feature codes and feature range types. This info would not be used to define the client type system.

2. After the client merged all delegate type systems it would compare the binary type system info against that of services using binary serialization. Initialization would fail on differences.


> 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.


[jira] Commented: (UIMA-1227) Help users debug binary CAS serialization problems

Posted by "Jerry Cwiklik (JIRA)" <ui...@incubator.apache.org>.
    [ https://issues.apache.org/jira/browse/UIMA-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672272#action_12672272 ] 

Jerry Cwiklik commented on UIMA-1227:
-------------------------------------

This JIRA depends on core UIMA-1290. The core frameworks should provide an API to enable validation of typesystems.

> 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.