›
Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

Accessing additional SRP Engine Server Info

Luann_DiasLuann_Dias
in SRP DirectConnect Control
Is there a way to access additional info about the SRP Engine's current state using Get_Property? For instance, I'm looking to see if I can get the statuses of each engine, engine count, logs, engine names, etc.

Comments

  • KevinFournierKevinFournier
    Sorry, that is not an available feature. We don't have plans currently to add this, but I have included it in my feature request list. It's not likely you'll get access to all the statistics you're after. The logs you should be able to get by just reading the log files. The engine count and engine names should be known because you define them in the INI.
  • Luann_DiasLuann_Dias
    No worries, that's fine. I'll see if it'll let me read the engine logs if they aren't locked. The reason I needed that info is to prevent a process from restarting in case it has any engines are in the middle of "PROCESSING" a previous request.
  • KevinFournierKevinFournier
    Is it not sufficient that the SRP Engine Server queues requests to be processed once an engine is freed?
  • DonBakkeDonBakke
    Since OI uses semaphore locks, you can just place a lock on an arbitrary key (such as the name of your process) at the beginning of the process (or from the code that calls the process) and only proceed if you get the lock. When the process completes, it just releases the lock.
  • Luann_DiasLuann_Dias
    @KevinFournier, it is sufficient however we recently had the idea to restart the process again once all engines were freed up due to the amount of requests being sent. This is a process that will be getting triggered periodically throughout the day and for now its being triggered using a TIMER event 15 minutes after it finishes. Instead of using the timer event, we had the idea of restarting this whole process once it receives it's last response from the SRP Engine Server/when all engines are freed up. Not sure if this is the best idea yet, we're still in the middle of experimenting.

    @DonBakke, sorry I wasn't clear. When I said "engine logs if they aren't locked", I was referring to the txt files that get locked when the SRP Engine Server is running when "EnableLogging" is set to True (In the SRPEngineServerLogs folder). The txt files Engine001, Engine002, etc. are always locked and unreadable by Windows when the Engine Server is running, preventing me from attempting to read them using the OSRead statement.
  • KevinFournierKevinFournier
    Do your requests come in batches or continuously? The SRP Engine Server is most efficient when requests are queued up. That way everything gets processed ASAP.

    I'm sure it's more complicated than what you're able to describe in this thread, though.
  • Luann_DiasLuann_Dias
    Batches. Actually the main process loops through all active tasks and determines whether or not if that task has assignments that need to get done. If there are assignments, it creates a batch record with a set of assignments and sends a request for that task to go run for that particular batch ID that got created. Once the task is finished, the batch ID then gets returned to the event handler (OnEngineResponse) and goes into a "gateway" routine that determines the next step for that batch, which eventually ends up getting sent as a request again back to the SRP Engine. Since each task has thousands of assignments, we extract a set of those assignments and create a batch. The next batch for that task won't get created until the main process gets triggered again by the TIMER event. We went down this route instead of creating multiple batches during each instance for two reasons:

    1. Due to the amount of changes happening by our users, the status of each assignment could change while it's queued up (i.e., an assignment that's part of a batch no longer needs to get run). Therefore, creating multiple batches and requesting for it to get triggered during each instance could be an issue for assignments that have already been taken care of.
    2. Hardware resources. Although its running on a virtual machine and we can allocate more memory, I'm still in the middle of testing resources to see how many engines we'll be able to spin up. This might be a temporary problem, I just need to talk to my IT team. For the time being, I can't hog up all the resources due to the environment I'm in.

    All in all, this whole process is a workflow engine that I recently just started and the SRP Engine Server has been fantastic. I'm still in the middle of experimenting and I wouldn't doubt if some of this will be subject to change. The additional server info question I had was simply just a thought we had that might simplify the process but I could be wrong.
Sign In or Register to comment.