• State Not Answered
  • Replies 3 replies
  • Subscribers 96 subscribers
  • Views 148 views
  • Users 0 members are here
Options
Related

method not found

alberto bugoloni_20369
6 days ago

Hi everyone,
I'm facing a serious issue in the production environment. After extending a custom table with two new fields, I sometimes encounter the error: Method not found: 'Void VI.DB.Model.CCC_Table.set_FieldName' during process execution. Unfortunately, this happens even when those specific fields aren't directly used.

I suspect the error occurs even when I just instantiate the object of type CCC_Table.
Keep in mind that the OI application is deployed on multiple servers, and it seems like only one of them is causing problems—the one running IIS that handles the API (script-based) calls, which are failing. I cleaned ALL the caches on every server, recompiled several times but no way i solved the problem.

I don't have the same error in development environment, so I think this issue is somehow linked to something wrong happened in prod.

Does anyone have any ideas? Thanks in advance!

Alberto

Parents
  • 0 6 days ago

    I do not have a real solution just asking some questions.

    • When you say API, does it run in the API Server or via the AppServer REST API?
    • If it is on the API Serer, are you using the generic typed wrapper objects (like in DialogScripts) or a module-based typed wrapper as described in the API Samples (for the API Server)? If the latter is the case, is the custom CCC.TypedWrappers.dll present on the server?
  • 0 6 days ago in reply to Markus Weiss-Ehlers

    Hi Markus, thanks for always being there for us!

    So, last night we left the production environment not working. This morning, by 7:00 AM, the issue was gone—no errors for a few hours now. It seems (I say "seems" because we want to wait a few more hours before celebrating) that everything resolved itself without any intervention.

    We believe the issue involves the AppServer, not the APIServer.
    The AppServer is installed on two separate servers managed by a load balancer. Yesterday afternoon, we tried shutting down IIS and services on both servers, clearing the service user’s cache and the cache under the INETPUB/WWWROOT directory, recompiling the entire database, and restarting IIS and services. But the problem still persisted.

    This morning, as mentioned, it seems everything is back to normal. If you have any ideas about what might have happened, that would be fantastic, as this is the second time it's occurred. The first time, clearing the cache and recompiling was enough, with minimal disruption.

    By the way, if you’re willing to share, I’d really appreciate some insight into how DLLs are managed across the different servers—because at this point, we realize we might not fully understand how that works.

    Thanks a lot again
    A

  • 0 6 days ago in reply to alberto bugoloni_20369

    "How are DLLs managed across the different servers"?

    - A semaphore in the database is increased if new assemblies are available.
    - Each server checks the semaphore periodically and downloads (Auto-Update) these "script" assemblies.

    I do not have a real explanation. What version are you using? I could check if I find anything regarding script assembly loading. In the meantime, did you check the event log on the AppServer for errors in Assembly loading?

Reply
  • 0 6 days ago in reply to alberto bugoloni_20369

    "How are DLLs managed across the different servers"?

    - A semaphore in the database is increased if new assemblies are available.
    - Each server checks the semaphore periodically and downloads (Auto-Update) these "script" assemblies.

    I do not have a real explanation. What version are you using? I could check if I find anything regarding script assembly loading. In the meantime, did you check the event log on the AppServer for errors in Assembly loading?

Children
No Data