Object reference datatypes may not be marshalled remotely
 
Forums / SmartComponent Library - Developer Forum / Object reference datatypes may not be marshalled remotely

Object reference datatypes may not be marshalled remotely

4 posts, 0 answered
  1. Roger Blanchard
    Roger Blanchard avatar
    413 posts
    Registered:
    29 Jun 2018
    17 Apr
    Link to this post
    We are randomly seeing Object reference datatypes may not be marshalled remotely to `OERA/support/proSIinvokeMethod.p`. (13224) in our 12.8.1 WebClient application.We will also see it when calling proSIinvokeTask.p. Once the error occurs once every call through the ServiceAdapter will throw this error.   

    This appears to have been caused when the PASOE server was rebooted. We attempted to restart the WebClient application, but the error persisted until we rebooted the WebClient PC. The application has been running since the reboot. If it only happened once, I would not be concerned but this is the third time this has happened. 

    Any ideas?




    24/04/16@07:11:11.625-0500] P-006956 T-002768 1 4GL ORS_ERR        An Progress.Lang.SysError has occurred:

    [24/04/16@07:11:11.625-0500] P-006956 T-002768 1 4GL ORS_ERR        Object reference datatypes may not be marshalled remotely to `OERA/support/proSIinvokeMethod.p`. (13224)

    [24/04/16@07:11:11.625-0500] P-006956 T-002768 1 4GL ORS_ERR        InvokeMethod2 Consultingwerk.OERA.ServiceAdapter at line 1544  (Consultingwerk/OERA/ServiceAdapter.r)
    [24/04/16@07:11:11.625-0500] P-006956 T-002768 1 4GL ORS_ERR        InvokeMethod Consultingwerk.OERA.ServiceAdapter at line 1394  (Consultingwerk/OERA/ServiceAdapter.r)
    [24/04/16@07:11:11.625-0500] P-006956 T-002768 1 4GL ORS_ERR        InvokeMethod Osprey.CustomClasses.OERA.OspreyServiceAdapter at line 328  (Osprey/CustomClasses/OERA/OspreyServiceAdapter.r)
    [24/04/16@07:11:11.625-0500] P-006956 T-002768 1 4GL ORS_ERR        CheckMaintLog Osprey.SQLite.MaintLog.MaintLogMapping at line 901  (Osprey/SQLite/MaintLog/MaintLogMapping.r)
    [24/04/16@07:11:11.625-0500] P-006956 T-002768 1 4GL ORS_ERR        FetchData Osprey.SQLite.MaintLog.MaintLogMapping at line 957  (Osprey/SQLite/MaintLog/MaintLogMapping.r)
    [24/04/16@07:11:11.625-0500] P-006956 T-002768 1 4GL ORS_ERR        ProcessReplication Osprey.SQLite.SQLiteController at line 2364  (Osprey/SQLite/SQLiteController.r)
    [24/04/16@07:11:11.625-0500] P-006956 T-002768 1 4GL ORS_ERR        StartReplication Osprey.SQLite.SQLiteController at line 2541  (Osprey/SQLite/SQLiteController.r)
    [24/04/16@07:11:11.625-0500] P-006956 T-002768 1 4GL ORS_ERR        timer1_Tick Osprey.SQLite.SQLiteContainer at line 429  (Osprey/SQLite/SQLiteContainer.r)
    [24/04/16@07:11:11.625-0500] P-006956 T-002768 1 4GL ORS_ERR        StartSyncManager.r at line 391  (StartSyncManager.r)

    [24/04/16@07:11:11.643-0500] P-006956 T-002768 1 4GL ORS_ERR        An Progress.Lang.SysError has occurred:

    [24/04/16@07:11:11.643-0500] P-006956 T-002768 1 4GL ORS_ERR        Object reference datatypes may not be marshalled remotely to `OERA/support/proSIinvokeTask.p`. (13224)

    [24/04/16@07:11:11.643-0500] P-006956 T-002768 1 4GL ORS_ERR        InvokeTask Consultingwerk.OERA.ServiceAdapter at line 4397  (Consultingwerk/OERA/ServiceAdapter.r)
    [24/04/16@07:11:11.643-0500] P-006956 T-002768 1 4GL ORS_ERR        InvokeTask Osprey.CustomClasses.OERA.OspreyServiceAdapter at line 575  (Osprey/CustomClasses/OERA/OspreyServiceAdapter.r)
    [24/04/16@07:11:11.643-0500] P-006956 T-002768 1 4GL ORS_ERR        RegisterKeepAlive Osprey.SQLite.SQLiteController at line 1458  (Osprey/SQLite/SQLiteController.r)
    [24/04/16@07:11:11.643-0500] P-006956 T-002768 1 4GL ORS_ERR        StartReplication Osprey.SQLite.SQLiteController at line 2542  (Osprey/SQLite/SQLiteController.r)
    [24/04/16@07:11:11.643-0500] P-006956 T-002768 1 4GL ORS_ERR        timer1_Tick Osprey.SQLite.SQLiteContainer at line 429  (Osprey/SQLite/SQLiteContainer.r)
    [24/04/16@07:11:11.643-0500] P-006956 T-002768 1 4GL ORS_ERR        StartSyncManager.r at line 391  (StartSyncManager.r)
  2. Peter Judge
    Peter Judge avatar
    14 posts
    Registered:
    11 Aug 2022
    17 Apr in reply to Roger Blanchard
    Link to this post
    HI Roger,

    The Progress kbase only mentions that error in the context of a version 12 server with an 11 client (or vice versa). And in that case I would expect that every request would fail, not just some requests. (Progress disabled/broke serialization between 11 and 12 when they released 12 , see https://docs.progress.com/bundle/abl-reference/page/ALLOW-PREV-DESERIALIZATION-attribute.html ). The fact that the error persists until the PC is rebooted is also strange.

    It might be worth opening a call with Progress TS.

    -- peter
  3. Roger Blanchard
    Roger Blanchard avatar
    413 posts
    Registered:
    29 Jun 2018
    17 Apr in reply to Peter Judge
    Link to this post
    >> The Progress kbase only mentions that error in the context of a version 12 server with an 11 client (or vice versa

    That is exactly what I saw, and we are 12.8.1 all the way around.

    I will reach out to PTS...thanks for the response.  
  4. Roger Blanchard
    Roger Blanchard avatar
    413 posts
    Registered:
    29 Jun 2018
    5 days and 1 hour ago in reply to Peter Judge
    Link to this post
    Hello Peter,

    This is a bug in the OE WebClient. We have been working with PSC TS for months and they finally have stated that this is a bug. They have provided a PUP that appears to solve the issue. 

    Info from PSC TS below.

    Thank you for your time earlier today with myself and Ken.  We discussed in more detail the functionality of the -connectionLifetime parameter as it relates to your issue.

    As Ken clarified, the bug found has to do with the CONNECTED() method and that after the connectionLifetime is reached (default is 5 minutes), the thread is deleted and a new thread is not started.  The connected method then does nothing. Setting that parameter to a very high value is the workaround to alleviate this. 

    The PUP that was provided to you cleans up this logic behind the connected method.  Also, with this fix, the connectionLifetime high value is not needed. 

     

4 posts, 0 answered