[UVM:styleguide] best end of test practices

from #22 a discussion on where and how to use objections has been started.
to not clutter that PR too much I have taken discussion this into its own issue.
The original suggestion is to avoid objections in drivers and monitors and instead add them in the scoreboard.
I will try to make an argument why monitors is the perfect place for objections and why they should only go into phase_ready_to_end()
one of the Arguments of why it is nice to have objections in the scoreboard is given by @sriyerg
I took the liberty of quoting it here:

I see some valid usecases in allowing raising/dropping objections in the scoreboard; example: in xbar type DUT, raise obj when transaction enters the DUT and drop only when it exits. This objection (that helps ensure that the test does not exit prematurely) cannot be captured in the monitor and has to be captured in a higher level component. It cannot be captured in the test either since it only generates and sends C-R stimulus to the driver. It has no knowledge of when the transactions actually enter and exit the DUT.
We keep the performance impact low by raising objection exactly once (dont raise if it is already raised), which is what the line implies. You can find that logic in our base scoreboard (hw/dv/sv/dv_lib/dv_base_scoreboard.sv). If by deadlocks you mean hangs, then there is an obvious problem either in the design or dv, that needs fixing. We avoid hanging forever through reasonable test timeouts.

I have two arguments against this - the first one being simply performance.
every time you raise and drop an objection is causing the component hierarchy to be traversed.
so for shallow environments this might be a minor impact but as the hierarchy gets deeper this quickly gets expensive.
The other argument is that implementing this in the scoreboard requires a watchdog timer to be implemented a long the side to avoid deadlocks.
Here is what I suggest
Most modules have deterministic input to output latency and does not need any objections besides test case objections and a good choice of drain time. this should be the default go to.
objections should only be used outside the test when the DUT latency is not detministic!
Some modules does not have deterministic latency. an example can be some sort of packet builder where input packets are grouped in larger chunks and these chunks are only forwarded when reaching a certain size.
Modules like this usually have an internal timeout to flush out undersized chunks.
In such a scenario it will be hard to raise objections in a scoreboard as the scoreboard cannot easily predict the number of outputs based on the number of inputs.
and the suggested objection method would be insufficient.
instead I suggest putting the objetion inside the phase_ready_to_end() function.
this is called once all modules have dropped their run_phase objections and the test is trying to end the run phase.
here is what is currently in my scoreboard (AES)
 virtual function void phase_ready_to_end(uvm_phase phase);
    if (phase.get_name() != "run") return;
    if ( (dut_fifo.num() != 0 ) || (ref_fifo.num() != 0) ) begin
      phase.raise_objection(this, "fifos still has data");
      fork begin
        wait_fifo_empty();
        phase.drop_objection(this);
      end
      join_none
    end
  endfunction

  virtual task wait_fifo_empty();
    wait ((dut_fifo.num() == 0 ) && (ref_fifo.num() == 0));
  endtask

  // ...
endclass

This ensures the Objection is ever only raised once!
obviously this still has the deadlock issue so a time would need to be implemented in parallel to the ''' wait_for_fifo_empty ''' function.
But this is still sub-optimal because the scoreboard should be a 0-time and there for it does not have any knowledge of clock frequency and one would have to guess what number of milliseconds is enough for any used clock frequency.
I believe the better choice is to implement a function in the monitor that detects traffic and keeps the phase from ending for /# number of clocks.
this is very similar to drain time but where drain time is for the full environment this implementation will work even when  multiple environments are cascaded to form a top level verification environment.
the idea is to start a timer when phase_ready_to_end is called.
if no traffic is seen before a timer runs out - it is ok to end.
here is an example I did
function void phase_ready_to_end(uvm_phase phase);
      uvm_phase current_phase;
      string str ="";
      uvm_object objectors[$];
      current_phase = phase;

      if (phase.is(uvm_main_phase::get())) begin
      // Start watchdog
        fork
          watchdog_ok_to_end();
        join_none;
        if (!ok_to_end) begin
          phase.raise_objection(this);
          fork begin
            wait_for_ok_end();
            phase.drop_objection(this);

            // see who is still objecting
            current_phase.get_objection().get_objectors(objectors); // get all that has raised objections
            str = $sformatf("\n\n\t |--------------------| Who Is Still OBJECTNG |------------------------|");
            str = {str, $sformatf("\n\t  current phase: %s ", current_phase.get_name())};
            str = {str, $sformatf("\n\t Hierarchical Name                                              Class Type")};
            foreach(objectors[i]) begin
              str = {str, $sformatf("\n\t%-60s%s\n\n", objectors[i].get_full_name(), objectors[i].get_type_name())};
            end
            `uvm_info({LOG_NAME, "*"}, str, UVM_HIGH);
          end join_none;
        end
      end
    endfunction

    //-----------------------
    // Wait until ok_to_end is set. Only checks ok_to_end every timeout_delay cycles since this is the length of the watchdog cycle
    task wait_for_ok_end();
      forever begin
        repeat(timeout_delay) @(posedge vif.clk_i);
        if (ok_to_end) break;
      end
    endtask // wait_for_ok_end

 // Watchdog waits timeout_delay cycles while checking if there is any data on the interface. If there is then !ok_to_end else ok_to_end.
    task watchdog_ok_to_end();
      bit        reset_timer = 0;
      fork
        begin
          forever begin
            @(posedge vif.clk_i);
            if(vif.vif.rd) begin
              reset_timer = 1;
            end
          end
        end
        begin
          forever begin
            ok_to_end = 0;
            repeat(timeout_delay) @(posedge vif.clk_i); // stay here until #timeout delay clocks has passed
            if(!reset_timer) begin
              ok_to_end = 1;
              break;
            end else begin
              `uvm_info(LOG_NAME, $sformatf(" Resetting timer"), UVM_FULL);
              reset_timer = 0;
            end
          end
        end
      join_any
    endtask

I hope this at least shows some of the drawbacks of putting objections in the run phase.
and secondly in the scoreboard.
If there is a big desire to but objections in the scoreboard I think that is ok, but I think we should require objections to only go in the phase_ready_to_end function when outside of the test.

@rasmus-madsen thanks for bringing this up.
I didn't use phase_ready_to_end before. After do some study, I think it's a good idea.
With raise/drop objection in test and drain time, the other components just need to use phase_ready_to_end to make sure last transaction completes gracefully. This reduces a lot of raise/drop objection and simplify the objection logic as well.
I personally prefer the way you did in aes. I modified a little bit for reuse.
// this function can be put in base scoreboard (dv_base_scoreboard) and reused by the other IPs
 virtual function void phase_ready_to_end(uvm_phase phase);
    if (phase.get_name() != "run") return;
    // perhaps remove this IP specific code and raise this objection anyway
    //if ( (dut_fifo.num() != 0 ) || (ref_fifo.num() != 0) ) begin
      phase.raise_objection(this, "fifos still has data");
      fork begin
        wait_fifo_empty();
        phase.drop_objection(this);
      end
      join_none
    //end
  endfunction

  // each IP should override this task
  virtual task wait_fifo_empty();
   // # (drain_time); // wait for some drain time if necessary
    wait ((dut_fifo.num() == 0 ) && (ref_fifo.num() == 0));
  endtask

A scoreboard may have transactions from multiple agents, like xbar (10+ agents), uart (2 agents).
I feel we should raise objection in phase_ready_to_end in monitor when bus isn't idle. And this part can be easily reused cross project since it's in agent.
Then scoreboard can just use its available high-level info (like fifo size) to determine if it's ready to end.
I think I would try this in spi_device. Thanks again for bring this idea to opentitan.

thank you @weicaiyang I also find this solution very elegant.
I still think checking fifo fill levels is valid - but I think this should be done in the check_phase() at the end of test
I suggest we

recommend objections to be put in the monitor
recommend that fifo fill levels in the scoreboard is checked during the check_phase (not in the ready to end phase)
Require objections are put in phase ready to end.

this would still allow for objections in the scoreboard, but enforce that they are in the phase_ready_to_end() function.
@sriyerg @udinator
what are your thoughts?

@rasmus-madsen can you elaborate what to do in phase_ready_to_end in monitor and scoreboard?
For monitor, raise objection at phase_ready_to_end when bus isn't idle?
For scoreboard, since fifo level is checked during check_phase and bus idle is checked in monitor, what would you suggest to do in phase_ready_to_end of scoreboard?

@weicaiyang
for the monitor I am suggesting implementing a watchdog that is activated when the monitors phase_ready_to_end() function is called this watch dog raises and objection.
if a transaction is seen on the bus in before the watchdog times out the watchdog timer is reset.
else the watchdog will end and the monitor will drop the objection and allow the phase to end.
I am suggesting not putting anything in the ready_to_end_phase() for the scoreboard as it is simply not needed if the monitors are coded correctly and the drain time in the base test is set to something that resembles the maximum latency through the DUT.
the output monitor will catch any transactions that will be passed to the scoreboard - and since the scoreboard handles these in 0 time there will never be an actual need to wait for the scoreboard to finish.
The problem with having something in scoreboards phase_ready_to_end is that it would be waiting for something to finish i.e a fifo being emptied which it can ALWAYS lead to a deadlock if what you are waiting for never comes unless you have a timeout running in parallel.
in the monitor you are actually checking that nothing happens which will NEVER lead to a deadlock.
But I think we should allow objections in the scoreboard as long a we recommend not to.
and insist on adding a watchdog timer in parallel.
I can make some example code if needed

@rasmus-madsen thanks for the explanation.
It sounds good to me. Looks like we can implement most of codes in base monitor (dv_base_monitor) to handle this and all the monitors can reuse that.

The style guide still needs updating with the sections above.
While this may not be urgent - I consider it fairly important as the current content is suggesting methods that the suggestion above discourages.

@rasmus-madsen - Something that was just recently brought up in a PR for the Icache testbench is the uvm_heartbeat mechanism (described in this paper) to be used for EOT, which would have the side effect of removing the need for a global test timeout due to the watchdog nature of this mechanism.
I personally am not familiar with this approach, so just wanted to start a discussion about any potential benefits/drawbacks of this mechanism for EOT checking versus the proposed approach of using phase_ready_to_end in the monitors. What do you think?

Did you remove your comment again I don’t see in GIT?
I was not aware of his class
I only scanned the document briefly so I will need to do a deeper dive into it.
but It looks like this one looks for objections rather than transactions
Which I at least for now does not find very useful as I advocate for limiting the number of objections.
as these are very expensive due to the traversing of the hierarchy.
But thank you for the paper I will do some more exploration into the subject.
Rasmus Madsen
Technologist
Western Digital®
Email: rasmus.madsen@wdccom
Mobile: +45-3161-3969
From: udinator<EMAIL_ADDRESS>Sent: Friday, April 24, 2020 2:53 AM
To: lowRISC/style-guides<EMAIL_ADDRESS>Cc: Rasmus Madsen<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [lowRISC/style-guides] [UVM:styleguide] best end of test practices (#30)
@rasmus-madsenhttps://github.com/rasmus-madsen - Something that was just recently brought up in a PR for the Icache testbench is the uvm_heartbeat mechanism (described in this paperhttp://www.synapse-da.com/Uploads/PDFFiles/04_UVM-Heartbeat.pdf) to be used for EOT, which would have the side effect of removing the need for a global test timeout due to the watchdog nature of this mechanism.
I personally am not familiar with this approach, so just wanted to start a discussion about any potential benefits/drawbacks of this mechanism for EOT checking versus the proposed approach of using phase_ready_to_end in the monitors. What do you think?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/lowRISC/style-guides/issues/30#issuecomment-618743198, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AM3LL76BVYMFBHUIP2DNS6TRODPFVANCNFSM4LCOOVWQ.

I agree that the heartbeat mechanism isn't really related to end-of-test (unless something bad happens!), so probably isn't relevant here. I also got the email and can't see the message: maybe Udi deleted it when he realised the same?

Ah sorry! I did indeed delete the comment when I realized that the heartbeat is not really an EOT mechanism; I'll re-send the link to the paper about this approach.
@rasmus-madsen - as far as the EOT method that you propose using phase_ready_to_end, I think this is a cleaner approach as well, I will prepare a PR to update the EOT section of the style guide with this method that should hopefully be out early next week.

Thanks @udinator
I will update cip_lib to use phase_ready_to_end next week

@udinator Great thank you

I think we can close this now?
@weicaiyang do you agree?

I think we can close this now?
@weicaiyang do you agree?

Yes, let me close it. Thanks


Running npm run serve:dev throws an error

Describe the bug
Same error shows up on npm run build:dev throws this error:
ERROR in ./src/main.js 3:0-28
Module not found: Error: Can't resolve 'css-loader' in '/path/to/project'

To Reproduce
Steps to reproduce the behavior:

Clone repository
Run npm install
Run npm run serve:dev

Expected behavior
Expected the app to run without errors

Desktop (please complete the following information):

OS: Ubuntu 20.04
Browser: Chrome
Version: 92.0.4515.107 (Official Build) (64-bit)
Node Version: 14.17.0
NPM Version: 6.14.13

I am not managing to reproduce this error, I am using:

Node Version: 15.8.0
NPM Version: 7.20.0

Would it be an option for you to update your node/npm versions and see if it works?

@Aridez - Apologies should've thought to try it on other versions. It was pretty late and my brain was being lazy.
Works with these versions:
Node: 15.6.0
NPM: 7.4.0
Thank you.

Glad to see that it worked! I didn't think about trying out the compatibility with older versions, I'll add a recommendation to the  README to use at least version 15 of Node and 7 of NPM


Replace CLI with config (resolves #245, resolves #259, resolves #262)

Removed STAR/RSEM naming requirements for contents inside tarball
Pipeline now modular (STAR/RSEM or Kallisto can be run based on inputs)
Input method now changed to manifest or --samples
README overhauled
Test rewritten to use config

Upload failed (400): Invalid URI: u'UNKNOWN'
error: Upload failed (400): Invalid URI: u'UNKNOWN'

Jenkins, test this please

Jenkins, test this please.

@hannes-ucsc — Error was non-deterministic.  Ready for review!


libusb issues during multi-board flashing on Windows 10

Hi,
I'm facing multiple issues w.r.t the libusb during multi-board flashing on Windows 10 PC.
I'm using uuu version 1.3.102 and specifying two different USB port/path numbers for 2 i.MX8 platforms.
During my single board trials, I didn't see any issues. However, Multi-board (2 boards) flashing is not reliable with the same set-up and binaries. Sometimes, it will flash without any issues. Other times, it will show USB_ERROR_PIPE for rootfs or larger files. Also, I'm getting USB_ERROR_TIMEOUT rarely. Moreover, the USB flashing will hang after started the flashing without any further prints in some cases (I need to close and start again in this case).
Hence, I would like to know whether the libusb is reliable on Windows 10 during the multi-board flashing. Whether I need to take care of any know issues in the 2 board flashing time?
Initially, we were using USB3.0 and then switched to USB 2.0 ports from the PC, still the issues remaining same. It will be difficult to go ahead with these issues from the production point of view.
Could anyone please let me know faced such issues and how to resolve these issues?

Did you power MX28 by USB port?

Did you power MX28 by USB port?

Sorry, I didn't get what is MX28.
I would like to inform that, we are using a  custom i.MX8 board. Regarding the power, we are using a separate power adapter. The USB cable is connecting from Windows 10 PC to the board directly only for the flashing purpose.

Did you use mini linux kernel or uboot to burn Image?

Did you use mini linux kernel or uboot to burn Image?

I'm using U-boot to burn the images. The default flashing procedure is followed from the NXP i.MX8 board flashing. However, we also have other images (application side) to be copied apart from the U-boot, Kernel and rootfs.
Could you please let me know whether anyone come across this kind of reliability issues earlier? Also, possible solutions to make sure everything works fine too.

It passed 4 boards (imx8MM) stress test. I fix some cirtical issue on libusb.
Maybe you can use below workaround to burn multi board.
lanuch many uuu instance with -m  option.

I'm already running 2 board parallel flashing with -m option to specify the USB ports. Still this issue is observed.
May I know the fix for critical issues of libusb applicable to uuu version 1.3.102?

https://github.com/libusb/libusb/commits?author=nxpfrankli

https://github.com/libusb/libusb/commits?author=nxpfrankli

I checked the above link. However, it is not clear to me that, UUU version 1.3.102 is using these libusb fixes.
Could you please confirm that, the 1.3.102 version UUU using these fixes?

Yes, it should include the fix

Hi @ajithpv,
it's been some years since you encountered the issue described above. But as I'm currently facing pretty much the same problem (see #392), it would be great to learn how you fixed it at the time.
Did it help to simply switch to another version of the UUU tool + libusb? If so, which versions did work for you?
Thank you very much in advance!


chore: Upgrade axios dep

Problem
Fixes https://github.com/PostHog/posthog-js-lite/issues/121
Changes
User mentioned our axios dep is somewhat outdated. The vulnerability mentioned shouldn't affect us given we only call our own endpoint, but nonetheless worth keeping up to date.
Release info Sub-libraries affected
Bump level

[ ] Major
[ ] Minor
[x] Patch

Libraries affected

[ ] All of them
[ ] posthog-web
[x] posthog-node
[ ] posthog-react-native

Testing
Tested locally with the example and all seemed fine

Ack! This breaks all non-Node runtimes (ex. Cloudflare) because Axios v1 doesn’t provide the correct non-Node ESM exports, which leads them to try and import a bunch of node modules, which they can’t.
A few potential fixes off the top of my head:

Replace Axios with fetch (now that fetch is in all LTS versions, this might not be unreasonable; it would also mean non-Node runtimes don’t have to add fetch as a parameter when instantiating PostHog)
Agitate Axios to fix axios/axios#5495
Patch it
Split the package into Node and non-Node in package.json#exports


Allow arrow annotation to be rotated

This PR allows the arrow annotation to be rotated. This ended up being a bit trickier than I had expected, but the basic idea to to leverage the built in WWT ability to convert from pixel <---> sky coordinates to do the rotation in pixel coordinates (which are flat), then convert back to sky coordinates. (Performing the rotation in sky coordinates directly leads to a sheared arrow). This necessitates drawing the arrow after the WWT view arrives at M101 during setup.
I don't know what angle we want the arrow to be rotated by, but once we decide I can do any final tweaks to make it look better.

Just a note that the rotation angle that's used is set in line 835

It took a bit, but I figured out why the arrow needed additional tweaking after the rotation. Moving the coordinates to/from screen space ultimately depends on the screen size, meaning that we were losing some resolution just by being zoomed out. The fix I've used here is to very briefly zoom in and create the arrow at a greater zoom, then immediately zoom back out.


Added reference to Bean Binding documentation

Within this document there is a reference to a "Bean Binding" mechanism. I have added a link to the documentation explaining the mechanism.

Thanks


Prevent KeyError when reading self.attributes

This partially solves the issue for me: It's starting now, but no time_tts entity is showing up.
Let me know if you have any objections or need further infromation!
fixes #2

Thanks for fix! I didn't think it


Preventing loss of data on shutdown

When using the default data store for Hoverfly, everything is stored in memory. This is fast, but it means the user must remember to call export before stopping it, otherwise the data is lost. It would be good if Hoverfly provided an endpoint what states whether the data has been exported or not since it's last change. This means clients such as the CLI can decide to prompt on calling stop for the user to export their saved changes.

You can persist data using the -db flag in Hoverfly. I have to admit I'd forgotten that is an option.


Integrate Indexer into verifier service tests after the Nomos DA Certificate is merged into da-protocol-v1

https://github.com/logos-co/nomos-node/pull/650 tests the verifier service, but for complete e2e flow, kzgrs-backend needs to implement Certificate and related nomos-core traits.
Create a new PR for updating verifier integrations tests in nomos-da-tests to include creation of certificate after the attestations are received and pushing it the mempool service. Then use indexer service to receive data blobs for appid and index.

Not using VID certificate anymore.


"input_aft_feature_delete_default_vpcs_enabled" control only delete AFT Management Account's default VPCs

Hi there,
Is this logic intended to only delete the Default VPC in AFT management account only?
https://github.com/aws-ia/terraform-aws-control_tower_account_factory/blob/f8a3a30627f1dfe228dda7db6d64e72957cecece/src/aft_lambda/aft_feature_options/aft_delete_default_vpc.py#L61-L81
It's a bit confusing from AWS documentation (Delete the AWS default VPC) descriptions, and the module README as well .
I have the impression of by turning on this feature the AFT pipeline will helps to delete all regions default VPCs for the new account created by AFT/CTLZ. However from the code logic it's only delete AFT Management Account's default VPCs.
Besides, the code looks strange as well, if this option is only intended deleted AFT management account default VPCs only, may I know why it extract the list of regions by target account's session ?
https://github.com/aws-ia/terraform-aws-control_tower_account_factory/blob/f8a3a30627f1dfe228dda7db6d64e72957cecece/src/aft_lambda/aft_feature_options/aft_delete_default_vpc.py#L51-L60

Hi @oceannic,
Thanks for reaching out. The somewhat confusing behavior of this option can be considered a known issue that will not be fixed in AFT v1 due to the risk of breaking changes for customers. Please see our comment in https://github.com/aws-ia/terraform-aws-control_tower_account_factory/issues/200#issuecomment-1178227617 for more detailed information.
Reading the documentation - I agree that is a bit confusing regarding the current behavior. It might be more clear to read it as:
Delete the AWS default VPC

When this option is enabled, the AFT pipeline deletes the associated AWS default VPCs for the AFT management account in all AWS Regions, even if you don’t have AWS Control Tower resources deployed in those Regions.

The AFT pipeline does not delete the AWS default VPCs automatically for any AWS Control Tower accounts that AFT provisions, or for existing AWS accounts that you enroll in AWS Control Tower by means of AFT.

To enable this option, set the following feature flag to True in your AFT deployment input configuration.

I've created a backlog item for our team to clarify the documentation.

Noted, and thanks for feedbacks @stumins.

Dear @stumins ,
It has been almost 2 years and it seems like this behaviour has not changed yet.
Can you provide an update on this? Is it still in the backlog? When can we expect AFT v2 with this change?
BR
Fabian


Code cleanup

Added a standard header to each code module and removed obsolete comments.
Re-named several of the sub-structs in the project struct and re-arranged some of their contents.
Re-named _defaultModel to _defaultProject.
Removed the need to call EN_createproject and EN_deleteproject when working with the default project.
Made X & Y coords. part of Snode properties instead of a separate struct.
Moved the non-API functions in epanet.c into a new module named project.c.
Re-factored the quality module so that it uses the same nodal adjacency lists as the hydraulics solver.
Re-factored the sparse matrix module (smatrix.c) to be more memory efficient.
Restricted line lengths to < 90 columns.
Grouped the placement of functions in EPANET2.H and EPANET.C by category.

Unit tests are failing. They need to be updated with the changes made to the API.

Yes - no more ProjectHandle. I'll fix it and re-submit.

Do you know that you can commit the changes to lrossman-dev and they will automatically be added to the PR?

I suspect test_setid is failing. See Issue #339

test_net_builder and test_toolkit both pass and both call EN_saveinpfile. Also, my local test of test_setid passes (I replace the BOOST_REQUIRE calls with calls to cout  -- see the code for test_addrule). Is there any way to tell at what line the CI test is failing? If we put debug print statements in the unit test will the CI run echo these (like it does for the build process)?

The bug is intermittent.

Hold on - I spoke too soon. My local test does show a failure in picking up a test of an illegal id name. I will check further and hopefully get test_setid to work.

If you build the test in Debug configuration you can get more diagnostic information about it.

The only thing in the hydraulics solver that was changed was the way that parallel links are detected when the nodal adjacency lists are built for use in the sparse matrix routines. I did this so that the same lists could be used in the water quality solver as well (instead of creating a separate, duplicate set of lists just for water quality).
It turns out that the EXNET network has 98 parallel links. So my guess is that the revised parallel link routine is causing a slightly different node re-ordering which, as we've seen before, can lead to small differences in the computed results (we're talking really small in this particular case).
To ease everyone's mind I will restore the previous parallel link detection code, but still allow the re-use of the adjacency lists for water quality. I hope no one will merge with dev in the meantime since the effort to manually resolve diffs with this current commit with all of its cleaned up code could be enormous.

A side note here: I would encourage small merges as a normal course of practice. The dev branch is meant to be in flux, so small incremental (even breaking?) merges would be preferred to huge (read: conflict-prone) merges.

Everything checks out OK now. I encourage review of the standardized header I placed at the top of each module and the way that the contents of TYPES.H were re-organized.

Close Issue #342 #343 #345 #346

@michaeltryby from my comment above, what I was trying to say had more to do with merge frequency than with what branch it happens on.

@michaeltryby again, merging such a large contribution within one day does not allow real review :(

@LRossman Thanks for your PR. We really appreciate it! :smile:

what I was trying to say had more to do with merge frequency than with what branch it happens on.

@samhatchett yeah, I understand. I would have liked to have seen this one broken down into 4 or 5 individual PRs each addressing a specific aspect of the cleanup.
Pairing an Issue with a PR creates a scope for the code changes and makes it easier for other developers to understand. Breaking blocks of changes down into smaller more frequent commits is also helpful. Especially, when using git history to try and identify bugs.


Ollama add OkhttpClient inject

Context
see #586
Change
Add OkhttpClient injection in Ollama models
Checklist
Before submitting this PR, please check the following points:

[x] I have added unit and integration tests for my change
[x] All unit and integration tests in the module I have added/changed are green
[x] All unit and integration tests in the core and main modules are green
[ ] I have added/updated the documentation
[ ] I have added an example in the examples repo (only for "big" features)
[ ] I have added my new module in the BOM (only when a new module is added)

Checklist for adding new embedding store integration

[ ] I have added a {NameOfIntegration}EmbeddingStoreIT that extends from either EmbeddingStoreIT or EmbeddingStoreWithFilteringIT

@langchain4j Hi! I've change it without OkhttpClient in constructor. Please have a look. BTW, there seems no official docker image with Auth, but I found some community docker image which implement it with Caddy, such as ollama-auth and ollama_proxy_server. Maybe we need to choose community docker image to test custom headers. But it seems not a good way due to consistency...WDYT? Do you have any idea to test it with official docker image?

@Martin7-1 regarding testing, we can do manual testing here if there is no easy way to automate it.

@Martin7-1 regarding testing, we can do manual testing here if there is no easy way to automate it.

Ok. I will add some tests.

@Martin7-1 Could you please add this new parameter to https://github.com/langchain4j/langchain4j-spring/blob/main/langchain4j-ollama-spring-boot-starter/src/main/java/dev/langchain4j/ollama/spring/AutoConfig.java?

@langchain4j ok. I've done it in langchain4j-spring#21.


add worker liveness check in reward calc

Mask weights used in reward calculation if the worker has insufficient inferences in the past reward epoch.
Increment the underlying mapping when new inferences are added.
Remove these counts across all topics entirely at end of global reward calc.

all of the emit rewards tests are failing now because the masking is setting the expected rewards amounts to zero instead. So the tests will need to have mocked inferences added to the test to make the number of inferences nonzero

Closing cuz I rebased in:
https://github.com/allora-network/allora-chain/pull/34


Let's include units in the force field file

We can do what SMIRNOFF force field format does:
https://github.com/openforcefield/openforcefield/blob/master/The-SMIRNOFF-force-field-format.md
For example
<HarmonicAngleForce angle_unit="radian" k_unit="kilojoules_per_mole/radian**2">
I'm not a fan of kilojoules_per_mole/radian**2 and would rather kJ/(mole radian**2) but whatever way we decide, should be 'machine readable' so code could do unit conversions, as well as a human.

This is a good idea.  Until this change is put into place, I suggest all force field files should start with a comment that clearly states the expected units.

Yeah having just filled in a force field, I would have much preferred to have used the native units.  It's a lot easier to check that a typo hasn't been made!

Ours (SMIRNOFF) are parsed by simtk.unit so that's where the kilojoules_per_mole/radian**2 comes from.

[ ] units
[ ] functional forms
[ ]  things like r_cut, shifted

We can add them first as xml comments, then add it to the schema, if the ff doesn't care about r_cut, we can either suggest a default, or not list one

I’m pretty sure all FFs have a defined cutoff they were made for (and others are technically wrong) so it’s very integral to include this.

On Mar 11, 2019 at 12:50 PM,  <Mike Henry (mailto:notifications@github.com)>  wrote:
units
functional forms
things like r_cut, shifted
We can add them first as xml comments, then add it to the schema, if the ff doesn't care about r_cut, we can either suggest a default, or not list one
—
You are receiving this because you commented.
Reply to this email directly,   view it on GitHub (https://github.com/mosdef-hub/foyer/issues/176#issuecomment-471672785), or   mute the thread (https://github.com/notifications/unsubscribe-auth/AI0jB5hXPOIBi2SNzwcC6OkxyEcT5xcwks5vVqV2gaJpZM4V2LNN).

The difficulty here is defining at the engine level exactly what's in the "setup" part and what's in the "details of MD setup" part. There are some things that fit neatly into one or the other (force field constants are in the setup side, timestep is on the MD side) but some like FF cutoff are a little more amorphous. In GROMACS it's in the .mdp file with other MD parameters but in other engines it's stored more closely to the force field.
However, the cutoff distance and cutoff handling are inarguably a part of faithfully reproducing the force field (assuming the authors are diligent enough to specify it!) so it can't be ignored. At bare minimum we should try to store it as metadata and print out to the user, i.e. "ok this XML is supposed to have a cutoff of 12 A and no tail correction"

I don't know if this comment belongs here or #220, but I think these issues could use a boost! As a user I spend too much time confused about what units I'm in through the conversion from mbuild/parmed/openbabel/openmm. I realize veteran users probably know these by heart, but for a new user it is very confusing. And it seems many unit conversions in our workflows are silent, which is even more confusing. It'd be nice if the standard units were listed in the docs or there were a way to query the units in the code!

@jennyfothergill I think this will come into play as the gmso backend starts to be integrated into foyer (soon, I hope!). I could perhaps be talked into working on an overhaul of the foyer docs. I had started this a few weeks back but time.

Thanks, Ryan! It's hard to justify a big revamp of the docs when big changes are on the way, but I think it is a great idea to make sure to document things like units moving forward. I love the explicit units in gmso, so I really hope to see that used in future.


print1ton(recursion) added

@aanchalsharmaa1024 please add problem number and name in commit message
for eg. 148_printfrom1toN

@aanchalsharmaa1024 also add solution link to readme section in same row where problem exist


Does pundler support group?

I think this is useful for different environment development, test, production
similar to http://bundler.io/groups.html

not yet, need to figure out how to do this right.

Just pushed support for envs. It use standard python approach like requirements_dev.txt etc.


OIDCInfoHook problems encountered in 2.4.5 and later versions

Dear developers, I am using “<redirect_uri>?info=json” to get the user name, when I upgrade to 2.4.5 or later, OIDCInfoHook seems not to work, I can not get the user name, <IP_ADDRESS> can also get the user name

server debug logs would help, as mentioned in the other thread as well; please pick it up there

[Tue Sep 14 15:29:58.751368 2021] [ssl:info] [pid 9792:tid<PHONE_NUMBER>48448] [client <IP_ADDRESS>:56530] AH01964: Connection to child 203   established (server test-zinrai-translation.bicc.css.fujitsu.com:443)
[Tue Sep 14   15:29:58.751487 2021] [ssl:info] [pid 9553:tid<PHONE_NUMBER>48896] [client   <IP_ADDRESS>:50432] AH01964: Connection to child 0 established (server   test-zinrai-translation.bicc.css.fujitsu.com:443)
[Tue Sep 14   15:29:58.751538 2021] [ssl:debug] [pid 9792:tid<PHONE_NUMBER>48448]   ssl_engine_kernel.c(2395): [client <IP_ADDRESS>:56530] AH02043: SSL virtual   host for servername test-zinrai-translation.bicc.css.fujitsu.com found
[Tue Sep 14   15:29:58.751551 2021] [core:debug] [pid 9792:tid<PHONE_NUMBER>48448]   protocol.c(2349): [client <IP_ADDRESS>:56530] AH03155: select protocol from ,   choices=h2,http/1.1 for server test-zinrai-translation.bicc.css.fujitsu.com
[Tue Sep 14   15:29:58.751585 2021] [ssl:debug] [pid 9553:tid<PHONE_NUMBER>48896]   ssl_engine_kernel.c(2395): [client <IP_ADDRESS>:50432] AH02043: SSL virtual   host for servername test-zinrai-translation.bicc.css.fujitsu.com found
[Tue Sep 14   15:29:58.751597 2021] [core:debug] [pid 9553:tid<PHONE_NUMBER>48896]   protocol.c(2349): [client <IP_ADDRESS>:50432] AH03155: select protocol from ,   choices=h2,http/1.1 for server test-zinrai-translation.bicc.css.fujitsu.com
[Tue Sep 14   15:29:58.871343 2021] [ssl:debug] [pid 9792:tid<PHONE_NUMBER>48448]   ssl_engine_kernel.c(2257): [client <IP_ADDRESS>:56530] AH02041: Protocol:   TLSv1.2, Cipher: ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
[Tue Sep 14   15:29:58.871350 2021] [ssl:debug] [pid 9553:tid<PHONE_NUMBER>48896]   ssl_engine_kernel.c(2257): [client <IP_ADDRESS>:50432] AH02041: Protocol:   TLSv1.2, Cipher: ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
[Tue Sep 14   15:29:58.872153 2021] [ssl:debug] [pid 9553:tid<PHONE_NUMBER>48896]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:50432] AH02034: Initial (No.1)   HTTPS request received for child 0 (server   test-zinrai-translation.bicc.css.fujitsu.com:443)
[Tue Sep 14   15:30:03.878084 2021] [ssl:debug] [pid 9553:tid<PHONE_NUMBER>56192]   ssl_engine_io.c(1115): [client <IP_ADDRESS>:50432] AH02001: Connection closed   to child 1 with standard shutdown (server   test-zinrai-translation.bicc.css.fujitsu.com:443)
[Tue Sep 14   15:30:07.898294 2021] [ssl:debug] [pid 9792:tid<PHONE_NUMBER>48448]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:56530] AH02034: Initial (No.1)   HTTPS request received for child 203 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://login.microsoftonline.com/
[Tue Sep 14   15:30:08.866419 2021] [ssl:debug] [pid 9792:tid<PHONE_NUMBER>55744]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:56530] AH02034: Subsequent   (No.2) HTTPS request received for child 204 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://login.microsoftonline.com/
[Tue Sep 14   15:30:08.867473 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>55744]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:08.867484 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>55744]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 0 : lbstatus 2500
[Tue Sep 14   15:30:08.867489 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>55744]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:08.867491 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>55744]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:08.867495 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>55744]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:08.867564 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>55744]   proxy_util.c(3019): AH00951: http: backend socket is disconnected.
[Tue Sep 14   15:30:08.868094 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>55744]   proxy_util.c(3187): AH02824: http: connection established with   <IP_ADDRESS>:50080 (<IP_ADDRESS>)
[Tue Sep 14   15:30:08.868106 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>55744]   proxy_util.c(3371): AH00962: http: connection complete to <IP_ADDRESS>:50080   (<IP_ADDRESS>)
[Tue Sep 14   15:30:08.869476 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>55744]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.182162 2021] [ssl:debug] [pid 9792:tid<PHONE_NUMBER>63040]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:56530] AH02034: Subsequent   (No.3) HTTPS request received for child 205 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:09.183210 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>63040]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.183223 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>63040]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 0 : lbstatus 2500
[Tue Sep 14   15:30:09.183228 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>63040]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.183230 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>63040]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.183235 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>63040]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.183942 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>63040]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.274716 2021] [ssl:info] [pid 9792:tid<PHONE_NUMBER>70336] [client   <IP_ADDRESS>:56746] AH01964: Connection to child 206 established (server   test-zinrai-translation.bicc.css.fujitsu.com:443)
[Tue Sep 14   15:30:09.274720 2021] [ssl:info] [pid 9554:tid<PHONE_NUMBER>92224] [client   <IP_ADDRESS>:49318] AH01964: Connection to child 81 established (server   test-zinrai-translation.bicc.css.fujitsu.com:443)
[Tue Sep 14   15:30:09.274843 2021] [ssl:debug] [pid 9792:tid<PHONE_NUMBER>70336]   ssl_engine_kernel.c(2395): [client <IP_ADDRESS>:56746] AH02043: SSL virtual   host for servername test-zinrai-translation.bicc.css.fujitsu.com found
[Tue Sep 14   15:30:09.274857 2021] [core:debug] [pid 9792:tid<PHONE_NUMBER>70336]   protocol.c(2349): [client <IP_ADDRESS>:56746] AH03155: select protocol from ,   choices=h2,http/1.1 for server test-zinrai-translation.bicc.css.fujitsu.com
[Tue Sep 14   15:30:09.274863 2021] [ssl:info] [pid 9555:tid<PHONE_NUMBER>70336] [client   <IP_ADDRESS>:50714] AH01964: Connection to child 142 established (server   test-zinrai-translation.bicc.css.fujitsu.com:443)
[Tue Sep 14   15:30:09.274892 2021] [ssl:debug] [pid 9554:tid<PHONE_NUMBER>92224]   ssl_engine_kernel.c(2395): [client <IP_ADDRESS>:49318] AH02043: SSL virtual   host for servername test-zinrai-translation.bicc.css.fujitsu.com found
[Tue Sep 14   15:30:09.274908 2021] [core:debug] [pid 9554:tid<PHONE_NUMBER>92224]   protocol.c(2349): [client <IP_ADDRESS>:49318] AH03155: select protocol from ,   choices=h2,http/1.1 for server test-zinrai-translation.bicc.css.fujitsu.com
[Tue Sep 14   15:30:09.275015 2021] [ssl:debug] [pid 9555:tid<PHONE_NUMBER>70336]   ssl_engine_kernel.c(2395): [client <IP_ADDRESS>:50714] AH02043: SSL virtual   host for servername test-zinrai-translation.bicc.css.fujitsu.com found
[Tue Sep 14   15:30:09.275018 2021] [ssl:info] [pid 9554:tid<PHONE_NUMBER>99520] [client   <IP_ADDRESS>:51778] AH01964: Connection to child 82 established (server   test-zinrai-translation.bicc.css.fujitsu.com:443)
[Tue Sep 14   15:30:09.275030 2021] [core:debug] [pid 9555:tid<PHONE_NUMBER>70336]   protocol.c(2349): [client <IP_ADDRESS>:50714] AH03155: select protocol from ,   choices=h2,http/1.1 for server test-zinrai-translation.bicc.css.fujitsu.com
[Tue Sep 14   15:30:09.275096 2021] [ssl:debug] [pid 9554:tid<PHONE_NUMBER>99520]   ssl_engine_kernel.c(2395): [client <IP_ADDRESS>:51778] AH02043: SSL virtual   host for servername test-zinrai-translation.bicc.css.fujitsu.com found
[Tue Sep 14   15:30:09.275108 2021] [core:debug] [pid 9554:tid<PHONE_NUMBER>99520]   protocol.c(2349): [client <IP_ADDRESS>:51778] AH03155: select protocol from ,   choices=h2,http/1.1 for server test-zinrai-translation.bicc.css.fujitsu.com
[Tue Sep 14   15:30:09.280257 2021] [ssl:info] [pid 9555:tid<PHONE_NUMBER>97376] [client   <IP_ADDRESS>:56930] AH01964: Connection to child 132 established (server   test-zinrai-translation.bicc.css.fujitsu.com:443)
[Tue Sep 14   15:30:09.280364 2021] [ssl:debug] [pid 9555:tid<PHONE_NUMBER>97376]   ssl_engine_kernel.c(2395): [client <IP_ADDRESS>:56930] AH02043: SSL virtual   host for servername test-zinrai-translation.bicc.css.fujitsu.com found
[Tue Sep 14   15:30:09.280376 2021] [core:debug] [pid 9555:tid<PHONE_NUMBER>97376]   protocol.c(2349): [client <IP_ADDRESS>:56930] AH03155: select protocol from ,   choices=h2,http/1.1 for server test-zinrai-translation.bicc.css.fujitsu.com
[Tue Sep 14   15:30:09.301295 2021] [ssl:debug] [pid 9792:tid<PHONE_NUMBER>77632]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:56530] AH02034: Subsequent   (No.4) HTTPS request received for child 207 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:09.302289 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>77632]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.302299 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>77632]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 0 : lbstatus 2500
[Tue Sep 14   15:30:09.302304 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>77632]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.302307 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>77632]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.302311 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>77632]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.302784 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>77632]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.388580 2021] [ssl:debug] [pid 9554:tid<PHONE_NUMBER>92224]   ssl_engine_kernel.c(2257): [client <IP_ADDRESS>:49318] AH02041: Protocol:   TLSv1.2, Cipher: ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
[Tue Sep 14   15:30:09.388760 2021] [ssl:debug] [pid 9554:tid<PHONE_NUMBER>92224]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:49318] AH02034: Initial (No.1)   HTTPS request received for child 81 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:09.388794 2021] [ssl:debug] [pid 9792:tid<PHONE_NUMBER>70336]   ssl_engine_kernel.c(2257): [client <IP_ADDRESS>:56746] AH02041: Protocol:   TLSv1.2, Cipher: ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
[Tue Sep 14   15:30:09.388866 2021] [ssl:debug] [pid 9792:tid<PHONE_NUMBER>70336]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:56746] AH02034: Initial (No.1)   HTTPS request received for child 206 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:09.388909 2021] [ssl:debug] [pid 9554:tid<PHONE_NUMBER>99520]   ssl_engine_kernel.c(2257): [client <IP_ADDRESS>:51778] AH02041: Protocol:   TLSv1.2, Cipher: ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
[Tue Sep 14   15:30:09.388956 2021] [ssl:debug] [pid 9554:tid<PHONE_NUMBER>99520]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:51778] AH02034: Initial (No.1)   HTTPS request received for child 82 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:09.389161 2021] [ssl:debug] [pid 9555:tid<PHONE_NUMBER>70336]   ssl_engine_kernel.c(2257): [client <IP_ADDRESS>:50714] AH02041: Protocol:   TLSv1.2, Cipher: ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
[Tue Sep 14   15:30:09.390246 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>70336]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.390258 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>70336]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 0 : lbstatus 2500
[Tue Sep 14   15:30:09.390262 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>70336]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.390265 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>70336]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.390269 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>70336]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.390374 2021] [ssl:debug] [pid 9555:tid<PHONE_NUMBER>70336]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:50714] AH02034: Initial (No.1)   HTTPS request received for child 142 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:09.390778 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>70336]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.390981 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>99520]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.390997 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>99520]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 0 : lbstatus 2500
[Tue Sep 14   15:30:09.391002 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>99520]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.391005 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>99520]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.391008 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>99520]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.391079 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>99520]   proxy_util.c(3019): AH00951: http: backend socket is disconnected.
[Tue Sep 14   15:30:09.391448 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>92224]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.391457 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>92224]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 1 : lbstatus 2500
[Tue Sep 14   15:30:09.391461 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>92224]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.391463 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>92224]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.391466 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>92224]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.391786 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>92224]   proxy_util.c(3187): AH02824: http: connection established with   <IP_ADDRESS>:50080 (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.391796 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>92224]   proxy_util.c(3371): AH00962: http: connection complete to <IP_ADDRESS>:50080   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.392045 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>92224]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.392092 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>70336]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.392100 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>70336]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 2 : lbstatus 2500
[Tue Sep 14   15:30:09.392104 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>70336]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.392106 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>70336]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.392118 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>70336]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.392181 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>70336]   proxy_util.c(3019): AH00951: http: backend socket is disconnected.
[Tue Sep 14   15:30:09.392298 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>99520]   proxy_util.c(3187): AH02824: http: connection established with   <IP_ADDRESS>:50080 (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.392311 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>99520]   proxy_util.c(3371): AH00962: http: connection complete to <IP_ADDRESS>:50080   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.392439 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>70336]   proxy_util.c(3187): AH02824: http: connection established with   <IP_ADDRESS>:50080 (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.392466 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>70336]   proxy_util.c(3371): AH00962: http: connection complete to <IP_ADDRESS>:50080   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.392599 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>99520]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.392753 2021] [ssl:debug] [pid 9555:tid<PHONE_NUMBER>97376]   ssl_engine_kernel.c(2257): [client <IP_ADDRESS>:56930] AH02041: Protocol:   TLSv1.2, Cipher: ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
[Tue Sep 14   15:30:09.392794 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>70336]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.393642 2021] [ssl:debug] [pid 9555:tid<PHONE_NUMBER>97376]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:56930] AH02034: Initial (No.1)   HTTPS request received for child 132 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:09.394666 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>97376]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.394676 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>97376]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 0 : lbstatus 2500
[Tue Sep 14   15:30:09.394684 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>97376]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.394687 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>97376]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.394691 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>97376]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.395094 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>97376]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.418671 2021] [ssl:debug] [pid 9792:tid<PHONE_NUMBER>84928]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:56530] AH02034: Subsequent   (No.5) HTTPS request received for child 208 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:09.419525 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>84928]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.419535 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>84928]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 0 : lbstatus 2500
[Tue Sep 14   15:30:09.419539 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>84928]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.419542 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>84928]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.419545 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>84928]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.419893 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>84928]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.509018 2021] [ssl:debug] [pid 9555:tid<PHONE_NUMBER>12640]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:50714] AH02034: Subsequent   (No.2) HTTPS request received for child 128 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:09.509142 2021] [ssl:debug] [pid 9554:tid<PHONE_NUMBER>06816]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:51778] AH02034: Subsequent   (No.2) HTTPS request received for child 83 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:09.509987 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>12640]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.509997 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>12640]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 0 : lbstatus 2500
[Tue Sep 14   15:30:09.510001 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>12640]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.510004 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>12640]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.510008 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>12640]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.510241 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>06816]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.510249 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>06816]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 1 : lbstatus 2500
[Tue Sep 14   15:30:09.510253 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>06816]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.510255 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>06816]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.510258 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>06816]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.510493 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>12640]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.510644 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>06816]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.511847 2021] [ssl:debug] [pid 9554:tid<PHONE_NUMBER>14112]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:49318] AH02034: Subsequent   (No.2) HTTPS request received for child 84 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:09.512790 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>14112]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.512801 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>14112]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 0 : lbstatus 2500
[Tue Sep 14   15:30:09.512805 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>14112]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.512809 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>14112]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.512812 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>14112]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.512983 2021] [ssl:debug] [pid 9555:tid<PHONE_NUMBER>75488]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:56930] AH02034: Subsequent   (No.2) HTTPS request received for child 129 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:09.513110 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>14112]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.513893 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>75488]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.513904 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>75488]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 0 : lbstatus 2500
[Tue Sep 14   15:30:09.513908 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>75488]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.513911 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>75488]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.513914 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>75488]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.514010 2021] [ssl:debug] [pid 9792:tid<PHONE_NUMBER>92224]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:56746] AH02034: Subsequent   (No.2) HTTPS request received for child 209 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:09.514196 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>75488]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.514891 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>92224]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.514901 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>92224]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 0 : lbstatus 2500
[Tue Sep 14   15:30:09.514905 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>92224]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.514907 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>92224]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.514910 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>92224]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.515186 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>92224]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.535144 2021] [ssl:debug] [pid 9792:tid<PHONE_NUMBER>99520]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:56530] AH02034: Subsequent   (No.6) HTTPS request received for child 210 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:09.535979 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>99520]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.535987 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>99520]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 0 : lbstatus 2500
[Tue Sep 14   15:30:09.535991 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>99520]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.535993 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>99520]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.535996 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>99520]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.536411 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>99520]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.629205 2021] [ssl:debug] [pid 9555:tid<PHONE_NUMBER>82784]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:56930] AH02034: Subsequent   (No.3) HTTPS request received for child 130 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:09.629215 2021] [ssl:debug] [pid 9555:tid<PHONE_NUMBER>90080]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:50714] AH02034: Subsequent   (No.3) HTTPS request received for child 131 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:09.630112 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>82784]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.630121 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>82784]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 0 : lbstatus 2500
[Tue Sep 14   15:30:09.630126 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>82784]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.630129 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>82784]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.630131 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>82784]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.630277 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>90080]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.630288 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>90080]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 1 : lbstatus 2500
[Tue Sep 14   15:30:09.630292 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>90080]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.630295 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>90080]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.630299 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>90080]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.630514 2021] [ssl:debug] [pid 9554:tid<PHONE_NUMBER>21408]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:51778] AH02034: Subsequent   (No.3) HTTPS request received for child 85 (server   test-zinrai-translation.bicc.css.fujitsu.com:443)
[Tue Sep 14   15:30:09.630625 2021] [ssl:debug] [pid 9554:tid<PHONE_NUMBER>28704]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:49318] AH02034: Subsequent   (No.3) HTTPS request received for child 86 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:09.630698 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>82784]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.630777 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>90080]   proxy_util.c(3187): AH02824: http: connection established with   <IP_ADDRESS>:50080 (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.630788 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>90080]   proxy_util.c(3371): AH00962: http: connection complete to <IP_ADDRESS>:50080   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.631123 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>90080]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.631485 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>21408]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.631492 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>21408]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 0 : lbstatus 2500
[Tue Sep 14   15:30:09.631496 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>21408]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.631498 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>21408]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.631501 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>21408]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.631639 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>28704]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.631649 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>28704]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 1 : lbstatus 2500
[Tue Sep 14   15:30:09.631654 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>28704]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.631657 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>28704]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.631660 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>28704]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.632010 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>28704]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.636945 2021] [ssl:debug] [pid 9792:tid<PHONE_NUMBER>06816]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:56746] AH02034: Subsequent   (No.3) HTTPS request received for child 211 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:09.637847 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>06816]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.637858 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>06816]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 1 : lbstatus 2500
[Tue Sep 14   15:30:09.637862 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>06816]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.637866 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>06816]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.637868 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>06816]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.638168 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>06816]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.652311 2021] [ssl:debug] [pid 9792:tid<PHONE_NUMBER>14112]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:56530] AH02034: Subsequent   (No.7) HTTPS request received for child 212 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:09.653207 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>14112]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.653215 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>14112]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 1 : lbstatus 2500
[Tue Sep 14   15:30:09.653219 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>14112]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.653221 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>14112]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.653224 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>14112]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.653673 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>14112]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.685856 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>21408]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.743471 2021] [ssl:debug] [pid 9555:tid<PHONE_NUMBER>14112]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:56930] AH02034: Subsequent   (No.4) HTTPS request received for child 148 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:09.744221 2021] [ssl:debug] [pid 9555:tid<PHONE_NUMBER>99520]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:50714] AH02034: Subsequent   (No.4) HTTPS request received for child 146 (server   test-zinrai-translation.bicc.css.fujitsu.com:443)
[Tue Sep 14   15:30:09.744458 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>14112]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.744468 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>14112]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 0 : lbstatus 2500
[Tue Sep 14   15:30:09.744473 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>14112]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.744476 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>14112]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.744480 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>14112]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.745129 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>14112]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.745264 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>99520]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.745274 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>99520]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 0 : lbstatus 2500
[Tue Sep 14   15:30:09.745279 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>99520]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.745281 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>99520]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.745285 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>99520]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.745337 2021] [ssl:debug] [pid 9554:tid<PHONE_NUMBER>41152]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:49318] AH02034: Subsequent   (No.4) HTTPS request received for child 74 (server   test-zinrai-translation.bicc.css.fujitsu.com:443)
[Tue Sep 14   15:30:09.746240 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>41152]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.746250 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>41152]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 1 : lbstatus 2500
[Tue Sep 14   15:30:09.746255 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>41152]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.746258 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>41152]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.746261 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>41152]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.746950 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>41152]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.758401 2021] [ssl:debug] [pid 9792:tid<PHONE_NUMBER>21408]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:56746] AH02034: Subsequent   (No.4) HTTPS request received for child 213 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:09.759501 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>21408]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.759512 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>21408]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 1 : lbstatus 2500
[Tue Sep 14   15:30:09.759516 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>21408]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.759518 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>21408]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.759521 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>21408]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.760020 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>21408]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.771486 2021] [ssl:debug] [pid 9792:tid<PHONE_NUMBER>28704]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:56530] AH02034: Subsequent   (No.8) HTTPS request received for child 214 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:09.772456 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>28704]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.772467 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>28704]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 1 : lbstatus 2500
[Tue Sep 14   15:30:09.772471 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>28704]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.772474 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>28704]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.772478 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>28704]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.772841 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>28704]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.817643 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>99520]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.857826 2021] [ssl:debug] [pid 9555:tid<PHONE_NUMBER>21408]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:56930] AH02034: Subsequent   (No.5) HTTPS request received for child 149 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:09.858736 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>21408]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.858746 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>21408]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 0 : lbstatus 2500
[Tue Sep 14   15:30:09.858750 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>21408]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.858753 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>21408]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.858756 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>21408]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.859316 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>21408]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.872499 2021] [ssl:debug] [pid 9792:tid<PHONE_NUMBER>36000]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:56746] AH02034: Subsequent   (No.5) HTTPS request received for child 215 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:09.873348 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>36000]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.873359 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>36000]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 0 : lbstatus 2500
[Tue Sep 14   15:30:09.873363 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>36000]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.873366 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>36000]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.873370 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>36000]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.873740 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>36000]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.886732 2021] [ssl:debug] [pid 9792:tid<PHONE_NUMBER>43296]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:56530] AH02034: Subsequent   (No.9) HTTPS request received for child 216 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:09.887748 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>43296]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.887757 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>43296]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 0 : lbstatus 2500
[Tue Sep 14   15:30:09.887761 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>43296]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.887763 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>43296]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.887766 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>43296]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.888129 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>43296]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.956220 2021] [ssl:debug] [pid 9554:tid<PHONE_NUMBER>12640]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:49318] AH02034: Subsequent   (No.5) HTTPS request received for child 64 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:09.957190 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>12640]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.957201 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>12640]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 0 : lbstatus 2500
[Tue Sep 14   15:30:09.957205 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>12640]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.957208 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>12640]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.957211 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>12640]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.957803 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>12640]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.973536 2021] [ssl:debug] [pid 9555:tid<PHONE_NUMBER>28704]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:56930] AH02034: Subsequent   (No.6) HTTPS request received for child 150 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:09.974442 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>28704]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.974453 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>28704]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 0 : lbstatus 2500
[Tue Sep 14   15:30:09.974457 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>28704]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.974459 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>28704]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.974463 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>28704]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.974922 2021] [proxy:debug] [pid 9555:tid<PHONE_NUMBER>28704]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.987303 2021] [ssl:debug] [pid 9792:tid<PHONE_NUMBER>12640]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:56746] AH02034: Subsequent   (No.6) HTTPS request received for child 192 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:09.988171 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>12640]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:09.988179 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>12640]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 0 : lbstatus 2500
[Tue Sep 14   15:30:09.988183 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>12640]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:09.988186 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>12640]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:09.988189 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>12640]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:09.988679 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>12640]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:10.002196 2021] [ssl:debug] [pid 9792:tid<PHONE_NUMBER>75488]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:56530] AH02034: Subsequent   (No.10) HTTPS request received for child 193 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:10.003073 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>75488]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:10.003084 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>75488]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 0 : lbstatus 2500
[Tue Sep 14   15:30:10.003088 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>75488]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:10.003090 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>75488]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:10.003094 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>75488]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:10.003432 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>75488]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:10.076065 2021] [ssl:debug] [pid 9554:tid<PHONE_NUMBER>75488]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:49318] AH02034: Subsequent   (No.6) HTTPS request received for child 65 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:10.076973 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>75488]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:10.076984 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>75488]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 0 : lbstatus 2500
[Tue Sep 14   15:30:10.076989 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>75488]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:10.076992 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>75488]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:10.076996 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>75488]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:10.077439 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>75488]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:10.194701 2021] [ssl:debug] [pid 9554:tid<PHONE_NUMBER>82784]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:49318] AH02034: Subsequent   (No.7) HTTPS request received for child 66 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:10.195010 2021] [ssl:debug] [pid 9792:tid<PHONE_NUMBER>82784]   ssl_engine_kernel.c(422): [client <IP_ADDRESS>:56530] AH02034: Subsequent   (No.11) HTTPS request received for child 194 (server   test-zinrai-translation.bicc.css.fujitsu.com:443), referer:   https://test-zinrai-translation.bicc.css.fujitsu.com/
[Tue Sep 14   15:30:10.195971 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>82784]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:10.195978 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>82784]   proxy_util.c(1344): AH10122: proxy: Entering byrequests for BALANCER   (balancer://htcluster)
[Tue Sep 14   15:30:10.195982 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>82784]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 0 : lbstatus 2500
[Tue Sep 14   15:30:10.195985 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>82784]   proxy_util.c(1437): AH10123: proxy: byrequests selected worker   "http://<IP_ADDRESS>:50080" : busy 0 : lbstatus 5000
[Tue Sep 14   15:30:10.195986 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>82784]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:10.195989 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>82784]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:10.195990 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>82784]   proxy_util.c(2040): AH00924: worker http://<IP_ADDRESS>:50080 shared already   initialized
[Tue Sep 14   15:30:10.195993 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>82784]   proxy_util.c(2097): AH00926: worker http://<IP_ADDRESS>:50080 local already   initialized
[Tue Sep 14   15:30:10.195993 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>82784]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:10.195998 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>82784]   proxy_util.c(2440): AH00942: http: has acquired connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:10.196406 2021] [proxy:debug] [pid 9792:tid<PHONE_NUMBER>82784]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:10.196524 2021] [proxy:debug] [pid 9554:tid<PHONE_NUMBER>82784]   proxy_util.c(2455): AH00943: http: has released connection for   (<IP_ADDRESS>)
[Tue Sep 14   15:30:14.686332 2021] [ssl:debug] [pid 9554:tid<PHONE_NUMBER>90080]   ssl_engine_io.c(1115): [client <IP_ADDRESS>:51778] AH02001: Connection closed   to child 67 with standard shutdown (server   test-zinrai-translation.bicc.css.fujitsu.com:443)
[Tue Sep 14   15:30:14.817839 2021] [ssl:debug] [pid 9555:tid<PHONE_NUMBER>36000]   ssl_engine_io.c(1115): [client <IP_ADDRESS>:50714] AH02001: Connection closed   to child 151 with standard shutdown (server   test-zinrai-translation.bicc.css.fujitsu.com:443)
[Tue Sep 14   15:30:14.975357 2021] [ssl:debug] [pid 9555:tid<PHONE_NUMBER>43296]   ssl_engine_io.c(1115): [client <IP_ADDRESS>:56930] AH02001: Connection closed   to child 152 with standard shutdown (server   test-zinrai-translation.bicc.css.fujitsu.com:443)
[Tue Sep 14   15:30:14.989979 2021] [ssl:debug] [pid 9792:tid<PHONE_NUMBER>90080]   ssl_engine_io.c(1115): [client <IP_ADDRESS>:56746] AH02001: Connection closed   to child 195 with standard shutdown (server   test-zinrai-translation.bicc.css.fujitsu.com:443)
[Tue Sep 14   15:30:15.196561 2021] [ssl:debug] [pid 9792:tid<PHONE_NUMBER>97376]   ssl_engine_io.c(1115): [client <IP_ADDRESS>:56530] AH02001: Connection closed   to child 196 with standard shutdown (server   test-zinrai-translation.bicc.css.fujitsu.com:443)
[Tue Sep 14   15:30:15.196794 2021] [ssl:debug] [pid 9554:tid<PHONE_NUMBER>97376]   ssl_engine_io.c(1115): [client <IP_ADDRESS>:49318] AH02001: Connection closed   to child 68 with standard shutdown (server   test-zinrai-translation.bicc.css.fujitsu.com:443)


adapt the telemetry playbooks to the new name and structure

Depends-On: https://github.com/openstack-k8s-operators/ci-framework/pull/528

This is linked to the new functionality of dataplane-operator: https://github.com/openstack-k8s-operators/dataplane-operator/pull/392

recheck

recheck

recheck

recheck

recheck

recheck