long delays first time in when calling business entity via DOH - Forum - OpenEdge Development - Progress Community

long delays first time in when calling business entity via DOH

 Forum

long delays first time in when calling business entity via DOH

  • Hi

    We've noticed long delays when running fetches via the DOH. We're using server side paging and the DS fill from start to finish is taking 0.8 seconds but we're looking at a huge amount of time before we see the entry in the log file. I think the DOH is taking an age to work out what to do.

    The catalog fetch works via my own handler and I notice the column labels show instantly. Then I have to wait.

    In my scenario, the catalog fetch occurs. 26 seconds later it calls the read method. Clearly the kendo grid is making the call pretty much immediately. The read call ends 0.8 seconds after its called. So its slow.

    Note that after being called once, a subsequent call is OK and as I would like the first call.

    My .gen file is 6 MB. Is it reading the .gen file thats taking the time. I dont believe it reads it all as a different read call consumes similar delays the first time its made.

    Any ideas?

    -Darren

  • Darren,
     
    The DOH does read the <service-name>.gen file on first request for that service and adds the info to its cache.  There are other caches that are loaded on first contact that may also contribute to that slowness.
     
    You can preload those caches from the session startup procedure using code* similar to
     
    OpenEdge.Web.DataObject.ServiceRegistry:RegisterAllFromFolder(substitute('&1/openedge', os-getenv('CATALINA_BASE'))).
     
    This method loads all .gen and .map files in the given folder.
     
    The ServiceRegistry class also has a RegisterFile() method if you want to load just a single mapping file.
     
    The ServiceRegistryLoader (which does the work) doesn't have any logging showing how long a file takes to load.  I've added OCTA-18558: DataObjectHandler's ServiceRegistryLoader does not log how long files take to load for that. Please contact Tech Support if you'd like your name added to that issue.
     
     
     
    * since we don't ship a session startup procedure we can't automatically pre-load the caches.
     
     
    -- peter
     
     
  • Thanks. I'm afraid that didn't work. After doing this we get an error when making the first call saying it cant find locate the service. In addition with my 12.1, RegisterFile doesn't show up (private perhaps?).

    I think out biggest issue is likely to be the time each agent takes to load it. If there's a 40 second or greater delay, then staring multiple agents up front is likely to lead to the possibility the pas startup will timeout (180 sec by default).

    Is there a way of caching it after its been loaded in a form which makes multiple agents faster?

    -Darren

    .

  • > After doing this we get an error when making the first call saying it cant find locate the service.
     
    Hm. That sounds like a bug …
     
    Just to verify that once cached, things are performing ok?
     
    The DOH's caching per-agent approach is currently only JSON file-based. I think it'd make sense to look into other approaches, so that each session doesn't have to do the parsing of the mapping file, but that'd be a new feature for us.
     
    And just to confirm that the GEN file contains 1 service with many operations?
     
    The load-file method name is OpenEdge.Web.DataObject.ServiceRegistry.RegisterFromFile(pcFile)  .
     
     
     
  • Hi. Its fine once loaded. The .gen file contains a single service with 6 operations per business entity. We have about 400 business entities which explains why the delay exists.

    I'll give it another go.

    -D

  • That works correctly. The RegisterFromFile is functionally correct. I think we're still looking at the same issue on agent startup in terms of time but its better than it not working at all. Our 400 BE's have the same static methods and so I think in a worst case, there may be a need for me to write my own handler and not use the DOH. I don't see the point in that extra work whilst the DOH does the job.

    No immediate rush for now. We're in development  mode.

    Thanks for your help.

    -D