[Remote rendering problem] Auto-Renew Session behaviour is inconsistent and excessive

Describe the problem
If you don't use the Auto-Stop session behaviour, the logic for auto-renew becomes quite important to ensure you're not running ARR sessions for longer than necessary.
There are two problems with the current auto-renew behaviour (version 0.1.76), the criteria from when to extend and the extension duration.
Extension Criteria - The logic for determining when a session should extend is inconsistent depending on the code path.

The first code path is when you're creating a new session from the client. This defines the time at which it should extend to be 25% of the original lease time, before the end of the session. So a 20 mins session would renew 5 mins before the end of the session.
The second code path is when you're connecting to an already existing session. This defines the time at which it should extend to be 20 mins before the end of the session.

Extension Duration - When the logic has determined it's time to extend, the current lease time is doubled. This allows session lengths to grow out of hand. For example, with the 2nd extension criteria from above, you could start a 10-minute session which you stay in for 21 mins and leave, the session length would have been extended to 80 mins.
Expected Behaviour
Auto-Renew default behaviour should be made more intuitive and consistent.
The Azure Remote Rendering asset tool has user-defined extension duration and uses 25% of the extension duration as the trigger to extend. That seems like a reasonable logic. Although, arguably, in this instance, there should just be two user-defined values, extension time and time before the end of the session to auto-extend.

Hi,
thanks for letting us know. We will do a pass over the logic as it seems to be quite unintuitive indeed.
I'll keep you updated.
Cheers,
Florian

Hi,
thanks for letting us know. We will do a pass over the logic as it seems to be quite unintuitive indeed.
I'll keep you updated.
Cheers,
Florian

Release 0.1.81 has been published:
https://github.com/Azure/azure-remote-rendering/releases
It has improved and very transparent session renewal code built into the samples


Support for polling interval with --watch

If using node-sass --watch in an environment where Gaze falls back to polling (e.g. networked file system) the polling can cause unnecessary CPU-load.
Would you consider some method for passing the interval option to Gaze?

Related: #636

Thanks for your feedback.
The watch feature of node-sass certainly needs a major overhauling, even besides the underlying dependency. There is an on-going PR, which will probably improve the situation: https://github.com/sass/node-sass/pull/782.
Currently, we are focusing on implementing the remaining features of libsass API and streamlining the build process. We will probably be able to visit it after v3.0.0.
Nonetheless, the PRs are always welcome; we still have time to include breaking changes in v3. Feel free to chip in. :)

I wonder what a good way to handle this via the CLI is. I don't want to duplicate all of Gaze's CLI options in our CLI.
Handling the API side of this is easy because we can simple pass through a watch object to Gaze.

@jareware I've had some experience troubleshooting performance of NFS and I'd like to know more about your case before we take a stab at fixing it. What kind of environment is this? What is the performance issue you are experiencing? Are you running something like rpc.statd (if it's NFS indeed?)

I suspect this is not a performance issue. I suspect the 500ms polling interval just makes things feel sluggish relative the speed of the rest of the asset compilation tool chain. It's a feeling I can relate to, but I'm not convinced it's something we need to support. I opened a PR purely because it was very little overhead.

NVM I miss that this was a CPU issue. I doubt debugging this over GH issues will productive. Our slack channel is  better medium https://libsass-slack.herokuapp.com/. @jareware feel free to join us here if the issue persists.
Closing this in the interim as is appear to be an isolated case.

@saper, @xzyfer, sorry I was away from civilization for a few weeks. :)
The issue was (as I recall it) that the polling interval was too high, essentially busy-looping when looking for changes, whereas I would have been completely happy with e.g. looking every 250ms. But there was no option for it in node-sass.
Not an issue for me anymore (environment changed), so no need to reopen for me.


REEF-253: Mark unused code paths in the C# Driver with [Obsolete]

@beysims Can you have a look at this one? You know this code well, I believe.

I will take this one.


change akash dark colors

Description

Checklist

[ ] Ran Linting
[ ] Targeted PR against correct branch.
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Wrote unit tests.
[ ] Added an entry to the CHANGELOG.md file.
[ ] Re-reviewed Files changed in the Github PR explorer.

finished changing to Akash theme colors for dark mode

next step:

remove light mode from setting


Find by date

Find command can now find by date field as well.
When finding internships previously, the criteria was any matching word. Now, there must be an exact match between the user input and the Internship object's corresponding attributes. I made a new method matchingStringIgnoreCase in StringUtils.java and used this instead of the previous containsWordIgnoreCase in InternshipContainsKeywordsPredicate.
Updated InternshipContainsKeywordPredicate equals method. Previously, role fields were not taken into account. Now all five fields are taken into account when comparing between InternshipContainsKeywordPredicate objects.

Loos good to merge!


[sobjectizer] Update to 5.8.2.

[x] Changes comply with the maintainer guide.
[x] SHA512s are updated for each updated download.
[ ] The "supports" clause reflects platforms that may be fixed by this new version.
[ ] Any fixed CI baseline entries are removed from that file.
[ ] Any patches that are no longer applied are deleted from the port's directory.
[x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[x] Only one version is added to each modified port's versions file.

is there a particular reason it's still Draft?

No. There was a recommendation to make PR as "draft" for vcpkg, and I still follow that recommendation.

@eao197 If you confirm that the update is completed and there is no need to modify any update content, you can click "Ready for review". We'll review updates and merge them.

Okie dokie, sorry for the confusion. We mark things as 'draft' when we are waiting for folks to make changes because it's a thing people can change themselves and helps filter out what people are still working on vs. who needs an active response.
Thanks for the update!


bump version in package.json to v2.17.7

release version v2.17.7

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


navXUI finds navX, but AHRS does not

I'm not sure if I'm doing something wrong or if the Sim support broke everything. After the Sim support additions, every time I construct an AHRS object, it always uses a SimDevice: navX-Sensor SimDevice created.
When I look through the library code, it looks like it only uses a Serial port if m_simDevice is NULL. And the first thing it always does in the constructor's initialization list is initialize m_simDevice. I use C++, but it appears to have the same logic for Java.
Am I doing something wrong or is this a bug?

We tested C++ serial (both TTL UART and USB and didn’t see a problem.  As long as you are compiling for RoboRIO SimDevice should be null.   Can you be more specific about what’s not working?  Can you post a console log that shows the trace of activity?

Ok maybe it is me then. I'll adjust the title. I guess the issue is that I can't select the navx on this computer, and maybe it falls back to a SimDevice, and I assumed it was a bug with the sim support because I don't see how the code bypasses the SimDevice in real cases.
So navXUI is able to find the navX on COM4. How can I initialize this with an AHRS object?

I don't see how the code bypasses the SimDevice in real cases.

In the real case (compiling for a RoboRIO, running on a RoboRIO), the if(simDevice) clause returns false.  For the simulation on windows desktop case, if(simDevice) evaluates to true.
This sleight-of-hand occurs because the WPI Library SimDevice class overrides the bool() operator.    You can see the header file for SimDevice here, and in it you'll see the bool operator:
https://github.com/wpilibsuite/allwpilib/blob/master/hal/src/main/native/include/hal/SimDevice.h

I guess the issue is that I can't select the navx on this computer
So navXUI is able to find the navX on COM4. How can I initialize this with an AHRS object?

To actually communicate with the navX-sensor via the AHRS class, the robot code you are developing must run on the Roborio.  And the navX-sensor must be connected to the RoboRIO via USB.  And you need to instantiate the navX-sensor in your RoboRIO C++ code like this:
ahrs = new AHRS(SerialPort::Port::kUSB);

Is that what you are currently attempting?

the WPI Library SimDevice class overrides the bool() operator

Ahh I see. Sorry I missed that.
ahrs = new AHRS(SerialPort::Port::kUSB);
That’s the code I have, but I’m running it on a PC with the navX plugged into the PC’s USB. (It’ll be a RPi on the robot.) I thought we had it working this way 2 years ago, which is why I was too quick to assume there was a bug and dint provide all the details. Is there something specific to it running on the RoboRIO rather than any PC?

Since it’s the middle of FRC season, I assume you are trying to write a robot program that runs on a RoboRIO to communicate over uSB with a navX-MXP.  And so you’d want to write something like what’s in this example:  https://pdocs.kauailabs.com/navx-mxp/examples/rotate-to-angle-2/
Can we take a step back - and can you give me a 10,000 foot view of what you are trying to accomplish?

If you want to communicate over USB to navX-sensor, you can use the Linux version of the AHRS class mentioned here:  https://pdocs.kauailabs.com/navx-mxp/software/linux-library/

Not on the RoboRIO. Just a C++ program that can run on a Windows PC or Linux Raspberry Pi. For Linux we’ll use that library.
What about via USB on a Windows PC? navXUI doesn’t appear to be using AHRS in the same way, but it works correctly.

What about via USB on a Windows PC?

There is no AHRS class supported on a Windows PC (except for the FRC library in simulate mode, which doesn't actually talk to the sensor.
We've never had anyone desire access to the AHRS interface on windows.
Note that there is support for saving sensor data to file in navXUI, you might find that helpful.
Ok to close out this issue?

Ah darn. So how does navXUI access the navX via USB on Windows? I could try to do it the same way.

NavX UI uses custom protocol code.  The protocol is documented here:  https://pdocs.kauailabs.com/navx-mxp/advanced/serial-protocol/
Simplest thing is most like to port Linux AHRS class to Windows.

Oh ok, I thought it would use the same library. I could look into porting the Linux class.
Do you know what it is about the WPILib version that only works on the RoboRIO? I don’t usually work with WPILib, but I assumed it just had general serial port classes. Most of the library seems to work anywhere, but maybe IO is specific to the RoboRIO.

WPI Library for roborio uses a ROboRIO hardware abstraction layer.  It can talk to an OS serial port, but only on Linux, not on Windows.

If you would like support while you develop AHRS class for windows, we can help with that; in return, we can make it available open source for anyone else interested (although to be honest, you're the only one who has ever asked at this point).  For that, please contact<EMAIL_ADDRESS>and reference our discussion here.

Ok, thanks. I might look into it in the off-season then. I’m surprised more teams don’t do development on different platforms.

I wonder if something like this is an option, patching serial ports to work cross-platform rather than porting the whole Linux library. Haven’t looked into it much yet, but I’ll do more research later.

WPILib's serial port implementation is based around the RoboRIO's Linux OS with a patch, so trying to run Serial Ports on Windows, Mac and most Linux platforms in simulation just plain won't work, and will probably crash. A lot. To try and get the most rock-solid support for serial ports possible, we're using the 'jssc' library to ensure we get native support on all platforms.

https://github.com/Open-RIO/Cereal

in any case, having a Windows analogue to the Linux library is probably more useful than a Windows patch for the RoboRIO version.

I believe it depends what the use case really is - anything you can do to help clarify what you are really trying to accomplish will help.  Two possibilities exist:

Allow the WPI Library simulation to actually interact with a physical navX-Sensor that happens to be connected to the sensor via USB on WIndows.

Allow code that uses the AHRS class to directly access the navX-Sensor on Windows when it is connected via USB.  But why?  How would this be useful?

Please take the time to review these two cases, and indicate which is the case you are envisioning - and exactly why this is important to you.  It's not clear if your use case is 1), or 2), or something else.  If we can make this clear, we can provide guidance and help.

I envision # 2.
Like I said, I want to write a C++ program that will run on a Raspberry Pi (Linux) and connect to the navX-Sensor via USB. Thus the competition code will need to use the Linux library, not the RoboRIO library. And since we develop with Windows, I would like code that uses the AHRS class to directly access the navX-Sensor on Windows when it is connected via USB. Let me know if that's still unclear.

And since we develop with Windows, I would like code that uses the AHRS class to directly access the navX-Sensor on Windows when it is connected via USB. Let me know if that's still unclear.

Why not simply write the code on the raspberry Pi directly?  That seems like the simplest thing that could possibly work - and it already is available.  And windows and Linux are different enough that it will need to be debugged on both platforms.

Why not simply write the code on the raspberry Pi directly?

A variety of reasons. We're far more limited on number of Raspberry Pis than laptops. Doing anything on the Pi can be slower for hardware reasons, and development on Linux in general can be slower and less familiar for our team than Windows. We also have higher-end  Windows laptops already running the Gazebo simulator and would like to be able to swap in and out our mocks with physical sensors when possible.
I understand that the Linux library is already available and certainly a decent option for our development, but I wanted to get a sense of what's available on Windows and if it would be possible to get full functionality.

I think I should have a PR out tonight.

Thanks for the heads up, sounds great.  I’ll set aside some time to review it.

@kauailabs I have a design question for you while I'm working on this. tl;dr at the bottom.
The Linux SerialPort reads, writes, and waits synchronously. Note that it reads 1 character at a time.
In Windows, "waiting for data or timeout" must be an asynchronous wait. Unfortunately the comms port must be opened with all operations synchronous or all operations asynchronous, which gives me some concern. I see two options here:

The comms port is opened with asynchronous operations. The read, write, and wait methods can be synchronous abstractions over the OS calls. The one concern here is that reading 1 character at a time might be slower if we now have to read and then check the result of each character.
The comms port is opened with synchronous operations. Read and write can be the standard synchronous calls. Since a synchronous wait can't take a timeout, it would wait indefinitely. Thus instead we just perform a static sleep. This, of course, might oversleep.

tl;dr
Under standard behavior for the navX, is it better to have slightly slower reads but always wake up early if there's data, or to optimize reads but always sleep a fixed amount?
My instinct is to go with option 1 unless there is a very large number of bytes read per sleep cycle.

Hopefully option 1 sounds good to you, since that's what I went with. It works well so far!
https://github.com/FRC900/navXTimeSync/pull/4


vscode c# code hinting cann't identify the custom signal name

Godot version
4.1.1
System information
vscode: 1.81.0 OS: Windows 10 x64 10.0.19045
Issue description
the godot can build ok with custom signal,but the vscode hinting cannot identify the custom signal.
1.new a custom signal with c#:
[Signal]
public delegate void RightMouseClickEventHandler();
2.invoke the signal with SignalName like:
EmitSignal(SignalName.RightMouseClick);

3.the godot can build and run ok in editor,seems the vscode hinting issue.
Steps to reproduce
1.new a custom signal with c#:
[Signal]
public delegate void RightMouseClickEventHandler();
2.invoke the signal with SignalName like:
EmitSignal(SignalName.RightMouseClick);
the vscode cann't identify the SignalName.RightMouseClick

Minimal reproduction project
test6.zip

This is a bug in VSCode's C# extension.

Duplicate of https://github.com/godotengine/godot-csharp-vscode/issues/57.


Investigate enabling svg for download image for Gene Expression

Investigate what it would take to enable svg for download image for Gene Expression. Currently the svg isn't a full vectorized image.
Figma
Value - Increase the number of downloads, increase our chances of publishing GE dot plots in publications due to the high-quality SVG, and raise our standards to the gold standard of image quality for users.
Reasoning - We want more users to download our dot plots and use them in their work via publication or the ability to share and collaborate. SVG image quality is much higher than our current format, allowing them to visualize/analyze the dot plot. This reasoning is also consistent with multiple users requesting this via the UXR feedback process.

@seve I might be able to look into this during HQ week! Can you please add some context and discovery work that's been done so far, and I'll take it from there. Thank you!

@seve can you add a little more background on what you've done so far to this ticket? @tihuan are you still picking this up? fyi @dsadgat

I think @dsadgat said to not work on this in Q4, so it's not on my todo list at the moment. But having the context ready from Seve will help resolve the issue faster later for sure!
Thank you 😄

Updating the urgency here because i recently became aware that this might be an issue with eCharts, and we need to understand if implementing this is blocked by the UI tech spike

Echarts supports SVG rendering, so I think this ticket shouldn't be blocked by the tech spike
A solution I have in mind is that when a user wants to download the SVG option, we re-render the heat map in SVG, save the screenshots, and then render the heat map in canvas again for interaction
If things go well, the solution can be done in a day or two!

Generate a new heatmap using Echart's SVG renderer.  All while the heatmap is tinted.

Worth implementing this for both PNG and SVG rendering

Risk: SCG render takes a long time, slowing down the download process

Alternative backups:

Open new window/tab do render there and download
Do rendering and image generation on the server and send the image over the wire

Currently testing out generating SVG for labels ourselves to avoid foreignObject, which is invalid for image editor. Hopefully can be done in 3 days
After that’s done, will go back to adding SVG option in WMG

The new approach of re-creating SVG is working, so I'll split this ticket into smaller chucks to fit into sprints better!


positioning the debugger

Hi!
I really love what you guys are doing with this tool. I'd love to see something similar to the customizability of gaearon/redux-devtools-dock-monitor. Initially, something like toggling visibility with a shortcut and moving the panel around, later on possible something like theming.
Would you be open to a PR around this type of feature?

Thanks!
Absolutely open to a PR. The modules are designed to be reasonably extensible, so if it turns out that you want an external module for a more sophisticated debugger I'm happy to contribute to that project as well.
Can you describe what you mean "toggling visibility with a shortcut" in more depth?

Also, I'm very interested in feature requests. Please don't hesitate to ask if there's something you'd like to see.

@wehriam re: visibility toggling:
visit this page:
http://erikras.github.io/redux-form/#/examples
and press Ctrl-h then, try pressing Ctrl-q a few times.
I'm also interested in creating a middleware that can be used with redux - I have a crude one implemented now that basically fires an action on SHOW_EXPERIMENT and WIN_EXPERIMENT, which then fires some omniture-specific code that we use for tracking. That way, rather than using:
emitter.addPlayListener(function(experimentName, variantName){
  mixpanel.track("Start Experiment", {name: experimentName, variant: variantName});
});

you would just do something like this:
emitter.addPlayListener((experimentName, variantName) => {
  dispatch(startExperiement({name: experimentName, variant: variantName});
});

that way, you can handle all of your analytics outside of the component, which is a pattern we're following already and has really cleaned up our components.
We will be using this lib heavily over the next few months, and on highly trafficked pages - I'll be sure to let you know how it goes and if we see a need for anything!
Thanks again!

Great. I've created two enhancement request issues:
https://github.com/pushtell/react-ab-test/issues/3
https://github.com/pushtell/react-ab-test/issues/4
Please feel free to suggest implementation changes, just wanted to get the threads in place.
If you start working on one or both please let me know, until then they'll be in my development queue.

you can handle all of your analytics outside of the component

Keep in mind the emitter is a singleton used by the components to coordinate, and which can be imported elsewhere. With that said, I see the benefits of routing play/win events as Redux actions and don't think it will be difficult to implement.

in that case, is the emitter for orchestrating "if this test wins, then show this test" kind of behavior?

The emitter was largely designed to coordinate tests, for example if you had header and subheader components in the same experiment with corresponding variants, but in different parts of the page. You can see this in action in the Coordinate Multiple Components usage section or on JSFiddle
While I am unaware of a use case for the "if this test wins, then show this test" behavior, you could do something like:
emitter.defineVariants("Experiment Step 1", ["A", "B", "C"]);
emitter.defineVariants("Experiment Step 2", ["1", "2", "3"]);
emitter.addWinListener("Experiment Step 1", function(experimentName, variantName){
  if(variantName === "B") {
    emitter.setActiveVariant("Experiment Step 2", "2");
  }
});

As long as no "Experiment Step 2" components had mounted when the callback is executed (and thus already have an active variant), variant "2" of "Experiment Step 2" will be displayed.

As a side note, emitter may no longer the best name as it also coordinates events.

Just stumbled over this component after trying react-ab which does not give me programmatic access to the current variant of an experiment (to choose different styles and code paths for instance).
I also like the experiment debugger and would like to integrate it into redux-devtools. I will check how that would be possible. Should be pretty straight-forward.
That would probably a separate project though.


Academic Search API

I am trying to use Academic Search API for getting similarity score between two strings. But it always shows me error "Internal server error"
Here is the api url: https://api.labs.cognitive.microsoft.com/academic/v1.0/similarity?s1=eat&s2=drink
Date: Tue, 16 Jun 2020 19:13:21 GMT
Content-Length: 111
Content-Type: application/json
{
"statusCode": 500,
"message": "Internal server error",
"activityId": "03008f2e-56a9-421e-9bd1-68011d6cbee2"
}

This is happening to me too, any insight into what is going on? Even when sending test requests from the academic function documentation test page. Thanks for any help!

@NicoFigueroa, Yeah, I didn't able to call the api. It's always return error.
However, I went to another way to use that api. After creating account on azure portal and by requesting MAG package, I received the full package on my azure storage. Then I downloaded full package on my local storage and by running the code( c#), I was able to run the api. It was long process.
Here is the link you can follow:
https://docs.microsoft.com/en-us/academic-services/graph/language-similarity


Fix CreateAlastriaID function in AlastriaIdentityManager.sol

It has been detected that the CreateAlastriaID function should receive as parameter a bytes32, referring to the hash of the public key, since the addPublicKey function of the smart contract PublicKeyRegistry now receives as parameter a bytes32 and not a string.
SMART CONTRACT FUNCTION OF THE IDENTITY MANAGER CALLING THE PUBLIC KEY REGISTRY FUNCTION
/**
    * @dev Creates a new AlastriaProxy contract for an owner and recovery and allows an initial forward call which would be to set the registry in our case
    * @param publicKey to be encoded in PublicKeyRegistry call from IdentityManager
    */
    function createAlastriaIdentity(string memory publicKey, uint256 format) public validAddress(msg.sender) isPendingAndOnTime(msg.sender) {
        AlastriaProxy identity = new AlastriaProxy();
        identityKeys[msg.sender] = address(identity);
        pendingIDs[msg.sender] = 0;
        bytes memory addPublicKeyCallData = abi.encodeWithSignature("addPublicKey(string, uin256)", publicKey, format);
        identity.forward(address(alastriaPublicKeyRegistry), 0, addPublicKeyCallData);//must be alastria registry call
    }

SMART CONTRACT FUNCTION OF THE PUBLIC KEY REGISTRY
    function addPublicKey(bytes32 publicKeyHash) public {
        require(!publicKeyRegistry[msg.sender][publicKeyHash].exists);
        uint changeDate = block.timestamp;
        publicKeyRegistry[msg.sender][publicKeyHash] = PublicKey(
            true,
            Status.Valid,
            changeDate,
            0
        );
    }

The changes that would need to be made would be:

Change the CreateAlastriaId input parameter to bytes32.
When building the addPublicKeyCallData pass bytes32 instead of string in addPublicKey function

@Fcocard , please take a look at this Issue: we'll update the SmartContract in order to release v2.2 of AlastriaID
We need to redeploy this SmartContract to alastriaT and alastriaB through the DigitelTS node, and finalize this Issue: https://github.com/alastria/alastria- identity-lib/issues/178

The smart contracts with the new changes have being deployed. They are at:
_redB_addresses.json
_redT_addresses.json


Clarify dependency resolution in delegate lookup feature

The specification is not very clear with regards to the behavior a container should have when looking up a dependency in a delegate container when the delegate container does not contain the dependency. While the answer seems obvious, I would like A) to clarify that my understanding is correct and B) depending on the answer to A, suggest to amend the specification to clarify the expected behavior.
Assuming we are trying to fetch an object A with dependencies B and C from a container Main in which a delegate container Child was set, and where B is defined in Child, C in Main:

A is requested from Main
Main needs B and C to build A

Main delegates resolution of B to Child, which successfully returns its value.
Main delegates resolution of C to Child, which cannot resolve it and throws a NotFoundException.

At that point, am I correct in assuming that Main is allowed to catch the NotFoundException and perform the lookup on itself instead of failing with a NotFoundException ? Or am I totally mistaken ?
In either case, I think the delegate feature should be clarified with regards to the expected behavior for failed lookups in delegate containers, as I believe it should be possible to implement it without having to go through all the discussions/articles that have lead to the spec as it currently stands...
This is by no means a critic (I fully adhere to the interop idea and find it a great initiative), just a question as a total outsider to all of the discussions that have been taking place -- and possibly a fresh eye on the specification.

At that point, am I correct in assuming that Main is allowed to catch the NotFoundException and perform the lookup on itself instead of failing with a NotFoundException ?

No :)
The idea of the delegate container is not the one of a child container (or sub-container).
Simply put: the delegate container is the one we use to get dependencies. That's it. Dependency not found? Nothing much to do except throw an exception…
For example. With 1 container, the container is calling itself: the delegate container is itself. So dependency not found: throw an exception. It doesn't make sense to look into "itself" since it already did.
Code-wise, it means replacing $this->get($subDependency) with $this->delegateContainer->get($subDependency). And by default you can init $this->delegateContainer = $this in the constructor. Of course that's just an example of implementation, the standard doesn't constrain how you implement it :)

And in real situations with 2 containers, what you usually do is have a root container that wraps the 2 containers.
Sub-containers have the root container as "delegate", so when they call the delegate they are actually calling the 2nd container and themselves (in the order defined in the root container).
But again, that's just an example. It's just the common use case.

Thank you for the clear and detailled answer. Guess that raises any doubts I had :)

Glad to know :)


Xcode 7 beta 4 build problems

../Pods/Alamofire/Source/ServerTrustPolicy.swift:166:41: error: cannot invoke 'SecPolicyCreateSSL' with an argument list of type '(Bool, CFString)'
            let policy = validateHost ? SecPolicyCreateSSL(true, host as CFString) : SecPolicyCreateBasicX509()
                                        ^
../Pods/Alamofire/Source/ServerTrustPolicy.swift:166:41: note: expected an argument list of type '(Boolean, CFString?)'
            let policy = validateHost ? SecPolicyCreateSSL(true, host as CFString) : SecPolicyCreateBasicX509()
                                        ^
../Pods/Alamofire/Source/ServerTrustPolicy.swift:172:45: error: cannot invoke 'SecPolicyCreateSSL' with an argument list of type '(Bool, CFString)'
                let policy = validateHost ? SecPolicyCreateSSL(true, host as CFString) : SecPolicyCreateBasicX509()
                                            ^
../Pods/Alamofire/Source/ServerTrustPolicy.swift:172:45: note: expected an argument list of type '(Boolean, CFString?)'
                let policy = validateHost ? SecPolicyCreateSSL(true, host as CFString) : SecPolicyCreateBasicX509()
                                            ^
../Pods/Alamofire/Source/ServerTrustPolicy.swift:176:17: error: cannot invoke 'SecTrustSetAnchorCertificatesOnly' with an argument list of type '(SecTrust, Bool)'
                SecTrustSetAnchorCertificatesOnly(serverTrust, true)
                ^
../Pods/Alamofire/Source/ServerTrustPolicy.swift:176:17: note: expected an argument list of type '(SecTrust, Boolean)'
                SecTrustSetAnchorCertificatesOnly(serverTrust, true)
                ^
../Pods/Alamofire/Source/ServerTrustPolicy.swift:203:45: error: cannot invoke 'SecPolicyCreateSSL' with an argument list of type '(Bool, CFString)'
                let policy = validateHost ? SecPolicyCreateSSL(true, host as CFString) : SecPolicyCreateBasicX509()
                                            ^
../Pods/Alamofire/Source/ServerTrustPolicy.swift:203:45: note: expected an argument list of type '(Boolean, CFString?)'
                let policy = validateHost ? SecPolicyCreateSSL(true, host as CFString) : SecPolicyCreateBasicX509()
                                            ^

../Pods/Alamofire/Source/Manager.swift:75:20: Cannot invoke 'CFStringTransform' with an argument list of type '(CFMutableString, UnsafeMutablePointer<CFRange>, CFString, Bool)'

You need to update to Xcode 7 beta 5.


Read File Error

I’m having trouble opening the data file containing multiple columns. The error I get:
Error trying to read '/Users/ardalan/OneDrive - University of Saskatchewan/Elliot/examples/129_1.dat':

_tmp_file_ = read_xdi('/Users/ardalan/OneDrive - University of Saskatchewan/Elliot/examples/129_1.dat')
^^^
File /Users/ardalan/.larch/init.lar, line 1
File "/Users/ardalan/xraylarch/lib/python3.8/site-packages/larch/closure.py", line 76, in __call__
return self.func(*args, **kwds)
File "/Users/ardalan/xraylarch/lib/python3.8/site-packages/larch/io/xdi.py", line 252, in read_xdi
xdif = XDIFile(filename, labels=labels)
File "/Users/ardalan/xraylarch/lib/python3.8/site-packages/larch/io/xdi.py", line 112, in __init__
self.read(self.filename)
File "/Users/ardalan/xraylarch/lib/python3.8/site-packages/larch/io/xdi.py", line 129, in read
raise ValueError(msg)

ValueError: Error reading XDIFile /Users/ardalan/OneDrive - University of Saskatchewan/Elliot/examples/129_1.dat
non-numeric value in data table

I’ve attached the file:
129_1 copy.txt

@Ardalanhayatifar for me, that file gives an error message ending with
  File "/Users/Newville/xraylarch/lib/python3.9/site-packages/xraylarch-0.9.58.post93+g4004e563.d20220320-py3.9.egg/larch/io/xdi.py", line 129, in read
    raise ValueError(msg)

ValueError: Error reading XDIFile x129_1.xdi
one or fewer rows in data table

which might be a little more helpful: there is one line of actual data.
I would also be cautious about using a file with that many columns.  XDI will definitely ignore columns past 128, and may give many error messages about that.  Have you verified that other such files do, in fact, work?
All that said, it seems reasonable for XAS Viewer to  detect an error from read_xdi() and then try a plain read_ascii(), which is not as complete, and does not attempt to read meta-data, but in this case would actually read successfully, and likely indicate that the file only has one row.

Thanks for checking it out. I reduced the files and columns and got to:
metadata not formatted as Family.Key: Value
I looked at .xdi format documentation and the problem is now fixed when I removed the the first line of the file:
# XDI/1.0
It works fine now.

@Ardalanhayatifar
That is really weird. I definitely do not get that error with the file you posted either.  And I'm pretty sure the XDI reader has not changed in a while.  But your file didn't have any data in it.    So, either you're not telling me everything you did or something is very broken with your installation.
For sure, if you edit a file by hand, you can break the XDI format.  But why would you do that?   And, for sure, if you do edit a file by hand, the only reasonable response I can give is "well, if you broke it, you're going to have to figure out how to fix it".

Here is the full original data file. It gives the previous error when the first line is not removed but works fine when the first line is removed.
129_1.dat.txt

@Ardalanhayatifar Thanks for an actual example. Yeah, I think it is failing because it has more than 128 columns.   I will have XAS_Viewer look for such errors and try to read with "read_ascii()", which does work.
I could also switch to reading XDI files with pure Python, which would alleviate the problem. The original goal for XDI was to have something cross-platform, documented, and with multiple implementations based on the reference C code. We stuck with that approach for a while, but it has not really gained traction and maybe we should just read it with Python.  One fewer C library to support...


Removing copy of headers and using hw_string instead to represent them. Removing copy of body too.

This is my first PR to address #75.
In this PR, I've removed the need to memcpy header keys and values. I've also changed the body to point to a hw_string, and not having to realloc/free upon receiving body chunks.
I don't currently have access to AWS machines to test this, so I had to test it in my local machine only for now. I can't see significant differences between my changes and master, but I'd like to get your thoughts on this @kellabyte before investing any more time.
I added another lua script (pipelined_get_headers.lua) to push some headers to the server as part of the benchmark.
I'll benchmark this with two separate servers some time next week.
Merry Christmas :santa:
PS: I opened #80 as I think we're at a point where we need a more sophisticated benchmark server.

I started with a smaller PR, but I think all changes required for #75 are quite small and related, so I ended up putting it all in one.
I rebased and pushed with another change that changes the place where the request is freed, so it's only freed after writing the response, and not straight after executing the callback.
Benchmark results (running with 4 threads on m4.xlarge with 2 machines):
With these changes
[ec2-user@ip-172-31-5-244 wrk]$ ./wrk -c 100 -t 100 -d 30s -s pipelined_get_headers.lua --latency http://<IP_ADDRESS>:8000
Running 30s test @ http://<IP_ADDRESS>:8000
  100 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.32ms   75.17us   7.24ms   89.44%
    Req/Sec   755.46     46.04     2.36k    99.68%
  Latency Distribution
     50%    1.32ms
     75%    1.35ms
     90%    1.38ms
     99%    1.44ms
  2260900 requests in 30.10s, 340.29MB read
Requests/sec:  75113.22
Transfer/sec:     11.31MB

With master
[ec2-user@ip-172-31-5-244 wrk]$ ./wrk -c 100 -t 100 -d 30s -s pipelined_get_headers.lua --latency http://<IP_ADDRESS>:8000
Running 30s test @ http://<IP_ADDRESS>:8000
  100 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.32ms   77.99us  11.83ms   95.34%
    Req/Sec   755.80     57.92     3.34k    99.69%
  Latency Distribution
     50%    1.32ms
     75%    1.34ms
     90%    1.37ms
     99%    1.43ms
  2260381 requests in 30.10s, 340.60MB read
Requests/sec:  75096.44
Transfer/sec:     11.32MB

Still, no significant changes, but it might be more visible with the faster parser and more CPUs.

Non pipelined POST requests with a reasonably big body yield similar results too (~30k RPS) using the following script:
rguments = {}

init = function(args)
    arguments = args
    wrk.headers["X-Small"] = "Small value"
    wrk.headers["X-Medium"] = "Some header with a medium value"
    wrk.headers["X-Large"] = "Some header with a reasonably large value that will take a bit more memory, just like most user agent strings"

    wrk.method = "POST"
    wrk.body   = "Integer sit amet mi blandit, feugiat massa efficitur, pellentesque diam. Pellentesque nec eros orci. Donec ac semper dolor. Donec aliquet euismod nulla, eu mollis lectus vestibulum at. Mauris orci odio, fermentum ac eleifend a, facilisis ut tortor. Proin diam leo, hendrerit at ipsum non, dapibus bibendum sapien. Maecenas ac rhoncus velit. Sed elit dolor, blandit nec dapibus vitae, posuere nec turpis. Donec pretium pretium ipsum vel imperdiet. Phasellus commodo lacinia vehicula. Donec vehicula gravida tempor. Duis sit amet purus vel leo tempor malesuada. Quisque nec odio efficitur, volutpat libero sit amet, egestas purus. Integer sit amet mi blandit, feugiat massa efficitur, pellentesque diam. Pellentesque nec eros orci. Donec ac semper dolor. Donec aliquet euismod nulla, eu mollis lectus vestibulum at. Mauris orci odio, fermentum ac eleifend a, facilisis ut tortor. Proin diam leo, hendrerit at ipsum non, dapibus bibendum sapien. Maecenas ac rhoncus velit. Sed elit dolor, blandit nec dapibus vitae, posuere nec turpis. Donec pretium pretium ipsum vel imperdiet. Phasellus commodo lacinia vehicula. Donec vehicula gravida tempor. Duis sit amet purus vel leo tempor malesuada. Quisque nec odio efficitur, volutpat libero sit amet, egestas purus. Integer sit amet mi blandit, feugiat massa efficitur, pellentesque diam. Pellentesque nec eros orci. Donec ac semper dolor. Donec aliquet euismod nulla, eu mollis lectus vestibulum at. Mauris orci odio, fermentum ac eleifend a, facilisis ut tortor. Proin diam leo, hendrerit at ipsum non, dapibus bibendum sapien. Maecenas ac rhoncus velit. Sed elit dolor, blandit nec dapibus vitae, posuere nec turpis. Donec pretium pretium ipsum vel imperdiet. Phasellus commodo lacinia vehicula. Donec vehicula gravida tempor. Duis sit amet purus vel leo tempor malesuada. Quisque nec odio efficitur, volutpat libero sit amet, egestas purus. Integer sit amet mi blandit, feugiat massa efficitur, pellentesque diam. Pellentesque nec eros orci. Donec ac semper dolor. Donec aliquet euismod nulla, eu mollis lectus vestibulum at. Mauris orci odio, fermentum ac eleifend a, facilisis ut tortor. Proin diam leo, hendrerit at ipsum non, dapibus bibendum sapien. Maecenas ac rhoncus velit. Sed elit dolor, blandit nec dapibus vitae, posuere nec turpis. Donec pretium pretium ipsum vel imperdiet. Phasellus commodo lacinia vehicula. Donec vehicula gravida tempor. Duis sit amet purus vel leo tempor malesuada. Quisque nec odio efficitur, volutpat libero sit amet, egestas purus. Integer sit amet mi blandit, feugiat massa efficitur, pellentesque diam. Pellentesque nec eros orci. Donec ac semper dolor. Donec aliquet euismod nulla, eu mollis lectus vestibulum at. Mauris orci odio, fermentum ac eleifend a, facilisis ut tortor. Proin diam leo, hendrerit at ipsum non, dapibus bibendum sapien. Maecenas ac rhoncus velit. Sed elit dolor, blandit nec dapibus vitae, posuere nec turpis. Donec pretium pretium ipsum vel imperdiet. Phasellus commodo lacinia vehicula. Donec vehicula gravida tempor. Duis sit amet purus vel leo tempor malesuada. Quisque nec odio efficitur, volutpat libero sit amet, egestas purus."
    wrk.headers["Content-Type"] = "text/plain"
end

It doesn't seem like the memory allocations and copies are the bottleneck using the standard HTTP parser. Maybe it's more apparent under pico parser.

I really need to get the benchmark server going so more than just myself can benefit from it.
I also really need to merge the picohttpparser branch so that we don't have this split. That branch also has the batching implementation. I've made the mistake of accidentally creeping it into a monolithic branch :cry:

Okay I'm ready to merge this if you can rebase it and I'll run some final benchmarks just to ensure everything looks okay. I want to get this and the picoparser branch merged.
The Techempower benchmarks pass a bunch of headers and I think this PR is going to make a significant difference :)

FYI #83 requires this now. I just realized picohttpparser does zero-copy of headers too so this will need to be in place :) Let's get this benchmarked and merged!

@kellabyte I think this is now ready to merge.
Here are some benchmarks (again, 2 m4.xlarge machines with 4 CPUs each). The results aren't much different, so I don't think the allocation is the bottleneck, but I'm interested to see how this performs with a faster parser.
master - single GET requests
[ec2-user@ip-172-31-5-244 wrk]$ ./wrk -c 100 -t 100 -d 30s -s pipelined_get.lua --latency http://<IP_ADDRESS>:8000
Running 30s test @ http://<IP_ADDRESS>:8000
  100 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.32ms  146.57us  14.28ms   98.99%
    Req/Sec   755.83     70.38     4.22k    99.65%
  Latency Distribution
     50%    1.32ms
     75%    1.34ms
     90%    1.37ms
     99%    1.42ms
  2259999 requests in 30.10s, 340.30MB read
Requests/sec:  75086.60
Transfer/sec:     11.31MB

zero-copy - single GET requests
[ec2-user@ip-172-31-5-244 wrk]$ ./wrk -c 100 -t 100 -d 30s -s pipelined_get.lua --latency http://<IP_ADDRESS>:8000
Running 30s test @ http://<IP_ADDRESS>:8000
  100 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.32ms  115.04us  13.04ms   97.95%
    Req/Sec   755.70     69.70     3.86k    99.68%
  Latency Distribution
     50%    1.32ms
     75%    1.35ms
     90%    1.38ms
     99%    1.44ms
  2260167 requests in 30.10s, 340.56MB read
Requests/sec:  75089.32
Transfer/sec:     11.31MB

master - 64 pipelined GET requests
[ec2-user@ip-172-31-5-244 wrk]$ ./wrk -c 100 -t 100 -d 30s -s pipelined_get.lua --latency http://<IP_ADDRESS>:8000 -- 64
Running 30s test @ http://<IP_ADDRESS>:8000
  100 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     5.15ms    2.96ms  39.96ms   57.28%
    Req/Sec     6.58k     1.78k   49.06k    89.08%
  Latency Distribution
     50%    5.18ms
     75%    7.97ms
     90%    9.91ms
     99%    0.00us
  19797786 requests in 30.10s, 2.91GB read
Requests/sec: 657753.53
Transfer/sec:     99.11MB

zero-copy - 64 pipelined GET requests
[ec2-user@ip-172-31-5-244 wrk]$ ./wrk -c 100 -t 100 -d 30s -s pipelined_get.lua --latency http://<IP_ADDRESS>:8000 -- 64
Running 30s test @ http://<IP_ADDRESS>:8000
  100 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     5.17ms    2.98ms  43.78ms   57.06%
    Req/Sec     6.59k     1.92k   53.16k    89.55%
  Latency Distribution
     50%    5.19ms
     75%    8.02ms
     90%    9.91ms
     99%    0.00us
  19786001 requests in 30.10s, 2.91GB read
Requests/sec: 657374.07
Transfer/sec:     99.05MB

master - 64 pipelined GET requests with 3 different headers of different sizes
[ec2-user@ip-172-31-5-244 wrk]$ ./wrk -c 100 -t 100 -d 30s -s pipelined_get_headers.lua --latency http://<IP_ADDRESS>:8000 -- 64
Running 30s test @ http://<IP_ADDRESS>:8000
  100 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     7.17ms    4.11ms  40.97ms   58.43%
    Req/Sec     4.61k     1.00k   34.15k    82.33%
  Latency Distribution
     50%    7.21ms
     75%   10.80ms
     90%   13.59ms
     99%    0.00us
  13860640 requests in 30.10s, 2.04GB read
Requests/sec: 460489.61
Transfer/sec:     69.39MB

zero-copy - 64 pipelined GET requests with 3 different headers of different sizes
[ec2-user@ip-172-31-5-244 wrk]$ ./wrk -c 100 -t 100 -d 30s -s pipelined_get_headers.lua --latency http://<IP_ADDRESS>:8000 -- 64
Running 30s test @ http://<IP_ADDRESS>:8000
  100 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     7.22ms    4.66ms 223.02ms   65.19%
    Req/Sec     4.61k     1.04k   28.37k    82.95%
  Latency Distribution
     50%    7.20ms
     75%   10.82ms
     90%   13.62ms
     99%    0.00us
  13914210 requests in 30.10s, 2.05GB read
Requests/sec: 462266.56
Transfer/sec:     69.65MB

master - 64 pipelined POST with 4 different headers of different sizes and a body with about 3k chars
[ec2-user@ip-172-31-5-244 wrk]$ ./wrk -c 100 -t 100 -d 30s -s post.lua --latency http://<IP_ADDRESS>:8000 -- 64
Running 30s test @ http://<IP_ADDRESS>:8000
  100 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     3.30ms    0.92ms   7.17ms   82.59%
    Req/Sec   304.02    128.34     2.41k    92.97%
  Latency Distribution
     50%    3.74ms
     75%    3.75ms
     90%    3.76ms
     99%    3.87ms
  909553 requests in 30.10s, 136.97MB read
Requests/sec:  30217.80
Transfer/sec:      4.55MB

zero-copy - 64 pipelined POST with 4 different headers of different sizes and a body with about 3k chars
[ec2-user@ip-172-31-5-244 wrk]$ ./wrk -c 100 -t 100 -d 30s -s post.lua --latency http://<IP_ADDRESS>:8000 -- 64
Running 30s test @ http://<IP_ADDRESS>:8000
  100 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     3.30ms    0.92ms   7.59ms   82.60%
    Req/Sec   304.01    126.91     1.87k    92.95%
  Latency Distribution
     50%    3.68ms
     75%    3.76ms
     90%    3.87ms
     99%    3.91ms
  909649 requests in 30.10s, 137.07MB read
Requests/sec:  30220.89
Transfer/sec:      4.55MB

And the lua files for your reference:

pipeline_get_headers.lua

arguments = {}

init = function(args)
    arguments = args
    wrk.headers["X-Small"] = "Small value"
    wrk.headers["X-Medium"] = "Some header with a medium value"
    wrk.headers["X-Large"] = "Some header with a reasonably large value that will take a bit more memory, just like most user agent strings"
end

request = function()
    pipeline_length = tonumber(arguments[1]) or 1
    local r = {}

    for i=1,pipeline_length do
        r[i] = wrk.format("GET", "/")
    end

    req = table.concat(r)

    return req
end

post.lua

arguments = {}

init = function(args)
    arguments = args
    wrk.headers["X-Small"] = "Small value"
    wrk.headers["X-Medium"] = "Some header with a medium value"
    wrk.headers["X-Large"] = "Some header with a reasonably large value that will take a bit more memory, just like most user agent strings"

    wrk.method = "POST"
    wrk.body   = "Integer sit amet mi blandit, feugiat massa efficitur, pellentesque diam. Pellentesque nec eros orci. Donec ac semper dolor. Donec aliquet euismod nulla, eu mollis lectus vestibulum at. Mauris orci odio, fermentum ac eleifend a, facilisis ut tortor. Proin diam leo, hendrerit at ipsum non, dapibus bibendum sapien. Maecenas ac rhoncus velit. Sed elit dolor, blandit nec dapibus vitae, posuere nec turpis. Donec pretium pretium ipsum vel imperdiet. Phasellus commodo lacinia vehicula. Donec vehicula gravida tempor. Duis sit amet purus vel leo tempor malesuada. Quisque nec odio efficitur, volutpat libero sit amet, egestas purus. Integer sit amet mi blandit, feugiat massa efficitur, pellentesque diam. Pellentesque nec eros orci. Donec ac semper dolor. Donec aliquet euismod nulla, eu mollis lectus vestibulum at. Mauris orci odio, fermentum ac eleifend a, facilisis ut tortor. Proin diam leo, hendrerit at ipsum non, dapibus bibendum sapien. Maecenas ac rhoncus velit. Sed elit dolor, blandit nec dapibus vitae, posuere nec turpis. Donec pretium pretium ipsum vel imperdiet. Phasellus commodo lacinia vehicula. Donec vehicula gravida tempor. Duis sit amet purus vel leo tempor malesuada. Quisque nec odio efficitur, volutpat libero sit amet, egestas purus. Integer sit amet mi blandit, feugiat massa efficitur, pellentesque diam. Pellentesque nec eros orci. Donec ac semper dolor. Donec aliquet euismod nulla, eu mollis lectus vestibulum at. Mauris orci odio, fermentum ac eleifend a, facilisis ut tortor. Proin diam leo, hendrerit at ipsum non, dapibus bibendum sapien. Maecenas ac rhoncus velit. Sed elit dolor, blandit nec dapibus vitae, posuere nec turpis. Donec pretium pretium ipsum vel imperdiet. Phasellus commodo lacinia vehicula. Donec vehicula gravida tempor. Duis sit amet purus vel leo tempor malesuada. Quisque nec odio efficitur, volutpat libero sit amet, egestas purus. Integer sit amet mi blandit, feugiat massa efficitur, pellentesque diam. Pellentesque nec eros orci. Donec ac semper dolor. Donec aliquet euismod nulla, eu mollis lectus vestibulum at. Mauris orci odio, fermentum ac eleifend a, facilisis ut tortor. Proin diam leo, hendrerit at ipsum non, dapibus bibendum sapien. Maecenas ac rhoncus velit. Sed elit dolor, blandit nec dapibus vitae, posuere nec turpis. Donec pretium pretium ipsum vel imperdiet. Phasellus commodo lacinia vehicula. Donec vehicula gravida tempor. Duis sit amet purus vel leo tempor malesuada. Quisque nec odio efficitur, volutpat libero sit amet, egestas purus. Integer sit amet mi blandit, feugiat massa efficitur, pellentesque diam. Pellentesque nec eros orci. Donec ac semper dolor. Donec aliquet euismod nulla, eu mollis lectus vestibulum at. Mauris orci odio, fermentum ac eleifend a, facilisis ut tortor. Proin diam leo, hendrerit at ipsum non, dapibus bibendum sapien. Maecenas ac rhoncus velit. Sed elit dolor, blandit nec dapibus vitae, posuere nec turpis. Donec pretium pretium ipsum vel imperdiet. Phasellus commodo lacinia vehicula. Donec vehicula gravida tempor. Duis sit amet purus vel leo tempor malesuada. Quisque nec odio efficitur, volutpat libero sit amet, egestas purus."
    wrk.headers["Content-Type"] = "text/plain"
end

I ran this on the benchmark server and Haywire crashed. I ran it in valgrind and found the following.
I'm running Haywire with ./build/hello_world --threads 40
./bin/wrk/wrk --script ./pipelined_get_headers.lua --latency -d 10s -t 10 -c 10 http://server:8000 -- 64

==28252== Thread 32:
==28252== Invalid read of size 1
==28252==    at 0x408ED1: http_request_on_header_field (http_request.c:160)
==28252==    by 0x40DFF5: http_parser_execute (http_parser.c:1437)
==28252==    by 0x40A802: http_stream_on_read_http_parser (http_server.c:263)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==    by 0x4E3F6A9: start_thread (pthread_create.c:333)
==28252==  Address 0x56e5b72 is 8,674 bytes inside a block of size 65,536 free'd
==28252==    at 0x4C2CE10: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==    by 0x4E3F6A9: start_thread (pthread_create.c:333)
==28252==
==28252== Invalid write of size 1
==28252==    at 0x408ED9: http_request_on_header_field (http_request.c:160)
==28252==    by 0x40DFF5: http_parser_execute (http_parser.c:1437)
==28252==    by 0x40A802: http_stream_on_read_http_parser (http_server.c:263)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==    by 0x4E3F6A9: start_thread (pthread_create.c:333)
==28252==  Address 0x56e5b72 is 8,674 bytes inside a block of size 65,536 free'd
==28252==    at 0x4C2CE10: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==    by 0x4E3F6A9: start_thread (pthread_create.c:333)
==28252==
==28252== Invalid read of size 1
==28252==    at 0x4085B2: hw_string_hash_func (http_request.c:30)
==28252==    by 0x4085B2: kh_put_hw_string_hashmap (http_request.c:37)
==28252==    by 0x4085B2: set_header (http_request.c:89)
==28252==    by 0x408F11: http_request_on_header_field (http_request.c:163)
==28252==    by 0x40DFF5: http_parser_execute (http_parser.c:1437)
==28252==    by 0x40A802: http_stream_on_read_http_parser (http_server.c:263)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==    by 0x4E3F6A9: start_thread (pthread_create.c:333)
==28252==  Address 0x56e5b72 is 8,674 bytes inside a block of size 65,536 free'd
==28252==    at 0x4C2CE10: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==    by 0x4E3F6A9: start_thread (pthread_create.c:333)
==28252==
==28252== Invalid read of size 1
==28252==    at 0x4085D5: hw_string_hash_func (http_request.c:31)
==28252==    by 0x4085D5: kh_put_hw_string_hashmap (http_request.c:37)
==28252==    by 0x4085D5: set_header (http_request.c:89)
==28252==    by 0x408F11: http_request_on_header_field (http_request.c:163)
==28252==    by 0x40DFF5: http_parser_execute (http_parser.c:1437)
==28252==    by 0x40A802: http_stream_on_read_http_parser (http_server.c:263)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==    by 0x4E3F6A9: start_thread (pthread_create.c:333)
==28252==  Address 0x56e5b72 is 8,674 bytes inside a block of size 65,536 free'd
==28252==    at 0x4C2CE10: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==    by 0x4E3F6A9: start_thread (pthread_create.c:333)
==28252==
==28252== Invalid read of size 1
==28252==    at 0x408A1B: hw_string_hash_func (http_request.c:30)
==28252==    by 0x408A1B: kh_resize_hw_string_hashmap (http_request.c:37)
==28252==    by 0x408A1B: kh_put_hw_string_hashmap (http_request.c:37)
==28252==    by 0x408A1B: set_header (http_request.c:89)
==28252==    by 0x408FE1: http_request_on_headers_complete (http_request.c:203)
==28252==    by 0x40DF61: http_parser_execute (http_parser.c:1806)
==28252==    by 0x40A802: http_stream_on_read_http_parser (http_server.c:263)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==    by 0x4E3F6A9: start_thread (pthread_create.c:333)
==28252==  Address 0x56e5b72 is 8,674 bytes inside a block of size 65,536 free'd
==28252==    at 0x4C2CE10: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==    by 0x4E3F6A9: start_thread (pthread_create.c:333)
==28252==
==28252== Invalid read of size 1
==28252==    at 0x408A3D: hw_string_hash_func (http_request.c:31)
==28252==    by 0x408A3D: kh_resize_hw_string_hashmap (http_request.c:37)
==28252==    by 0x408A3D: kh_put_hw_string_hashmap (http_request.c:37)
==28252==    by 0x408A3D: set_header (http_request.c:89)
==28252==    by 0x408FE1: http_request_on_headers_complete (http_request.c:203)
==28252==    by 0x40DF61: http_parser_execute (http_parser.c:1806)
==28252==    by 0x40A802: http_stream_on_read_http_parser (http_server.c:263)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==    by 0x4E3F6A9: start_thread (pthread_create.c:333)
==28252==  Address 0x56e5b72 is 8,674 bytes inside a block of size 65,536 free'd
==28252==    at 0x4C2CE10: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==    by 0x4E3F6A9: start_thread (pthread_create.c:333)
==28252==
==28252== Invalid read of size 1
==28252==    at 0x4C2FB1F: strncasecmp (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28252==    by 0x40B925: hw_route_compare_method (route_compare_method.c:14)
==28252==    by 0x409299: get_route_callback (http_request.c:241)
==28252==    by 0x409299: http_request_on_message_complete (http_request.c:289)
==28252==    by 0x40EAC7: http_parser_execute (http_parser.c:1859)
==28252==    by 0x40A802: http_stream_on_read_http_parser (http_server.c:263)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==    by 0x4E3F6A9: start_thread (pthread_create.c:333)
==28252==  Address 0x56e5b66 is 8,662 bytes inside a block of size 65,536 free'd
==28252==    at 0x4C2CE10: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==    by 0x4E3F6A9: start_thread (pthread_create.c:333)
==28252==
==28252== Invalid read of size 1
==28252==    at 0x4C2FB3F: strncasecmp (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28252==    by 0x40B925: hw_route_compare_method (route_compare_method.c:14)
==28252==    by 0x409299: get_route_callback (http_request.c:241)
==28252==    by 0x409299: http_request_on_message_complete (http_request.c:289)
==28252==    by 0x40EAC7: http_parser_execute (http_parser.c:1859)
==28252==    by 0x40A802: http_stream_on_read_http_parser (http_server.c:263)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==    by 0x4E3F6A9: start_thread (pthread_create.c:333)
==28252==  Address 0x56e5b66 is 8,662 bytes inside a block of size 65,536 free'd
==28252==    at 0x4C2CE10: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==    by 0x4E3F6A9: start_thread (pthread_create.c:333)
==28252==
==28252== Invalid read of size 1
==28252==    at 0x4C2FB59: strncasecmp (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28252==    by 0x40B925: hw_route_compare_method (route_compare_method.c:14)
==28252==    by 0x409299: get_route_callback (http_request.c:241)
==28252==    by 0x409299: http_request_on_message_complete (http_request.c:289)
==28252==    by 0x40EAC7: http_parser_execute (http_parser.c:1859)
==28252==    by 0x40A802: http_stream_on_read_http_parser (http_server.c:263)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==    by 0x4E3F6A9: start_thread (pthread_create.c:333)
==28252==  Address 0x56e5b66 is 8,662 bytes inside a block of size 65,536 free'd
==28252==    at 0x4C2CE10: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==    by 0x4E3F6A9: start_thread (pthread_create.c:333)
==28252==
==28252== Thread 8:
==28252== Invalid read of size 1
==28252==    at 0x408333: hw_string_hash_func (http_request.c:30)
==28252==    by 0x408333: kh_get_hw_string_hashmap (http_request.c:37)
==28252==    by 0x408333: get_header (http_request.c:65)
==28252==    by 0x4083B0: set_header (http_request.c:84)
==28252==    by 0x408F11: http_request_on_header_field (http_request.c:163)
==28252==    by 0x40DFF5: http_parser_execute (http_parser.c:1437)
==28252==    by 0x40A802: http_stream_on_read_http_parser (http_server.c:263)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==    by 0x4E3F6A9: start_thread (pthread_create.c:333)
==28252==  Address 0x19eebdd9 is 10,025 bytes inside a block of size 65,536 free'd
==28252==    at 0x4C2CE10: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==    by 0x4E3F6A9: start_thread (pthread_create.c:333)
==28252==
==28252== Invalid read of size 1
==28252==    at 0x408355: hw_string_hash_func (http_request.c:31)
==28252==    by 0x408355: kh_get_hw_string_hashmap (http_request.c:37)
==28252==    by 0x408355: get_header (http_request.c:65)
==28252==    by 0x4083B0: set_header (http_request.c:84)
==28252==    by 0x408F11: http_request_on_header_field (http_request.c:163)
==28252==    by 0x40DFF5: http_parser_execute (http_parser.c:1437)
==28252==    by 0x40A802: http_stream_on_read_http_parser (http_server.c:263)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==    by 0x4E3F6A9: start_thread (pthread_create.c:333)
==28252==  Address 0x19eebdd9 is 10,025 bytes inside a block of size 65,536 free'd
==28252==    at 0x4C2CE10: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==    by 0x4E3F6A9: start_thread (pthread_create.c:333)
==28252==
==28252== Invalid read of size 1
==28252==    at 0x4C2F9B9: __strncmp_sse42 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28252==    by 0x408300: kh_get_hw_string_hashmap (http_request.c:37)
==28252==    by 0x408300: get_header (http_request.c:65)
==28252==    by 0x4083B0: set_header (http_request.c:84)
==28252==    by 0x408F11: http_request_on_header_field (http_request.c:163)
==28252==    by 0x40DFF5: http_parser_execute (http_parser.c:1437)
==28252==    by 0x40A802: http_stream_on_read_http_parser (http_server.c:263)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==  Address 0x19eebdd9 is 10,025 bytes inside a block of size 65,536 free'd
==28252==    at 0x4C2CE10: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==    by 0x4E3F6A9: start_thread (pthread_create.c:333)
==28252==
==28252== Invalid read of size 1
==28252==    at 0x4C2F9F2: __strncmp_sse42 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28252==    by 0x408300: kh_get_hw_string_hashmap (http_request.c:37)
==28252==    by 0x408300: get_header (http_request.c:65)
==28252==    by 0x4083B0: set_header (http_request.c:84)
==28252==    by 0x408F11: http_request_on_header_field (http_request.c:163)
==28252==    by 0x40DFF5: http_parser_execute (http_parser.c:1437)
==28252==    by 0x40A802: http_stream_on_read_http_parser (http_server.c:263)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==  Address 0x19eebdda is 10,026 bytes inside a block of size 65,536 free'd
==28252==    at 0x4C2CE10: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==    by 0x4E3F6A9: start_thread (pthread_create.c:333)
==28252==
==28252== Invalid read of size 1
==28252==    at 0x4C2F9B9: __strncmp_sse42 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28252==    by 0x408486: kh_put_hw_string_hashmap (http_request.c:37)
==28252==    by 0x408486: set_header (http_request.c:89)
==28252==    by 0x408F11: http_request_on_header_field (http_request.c:163)
==28252==    by 0x40DFF5: http_parser_execute (http_parser.c:1437)
==28252==    by 0x40A802: http_stream_on_read_http_parser (http_server.c:263)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==    by 0x4E3F6A9: start_thread (pthread_create.c:333)
==28252==  Address 0x19eebdd9 is 10,025 bytes inside a block of size 65,536 free'd
==28252==    at 0x4C2CE10: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==    by 0x4E3F6A9: start_thread (pthread_create.c:333)
==28252==
==28252== Invalid read of size 1
==28252==    at 0x4C2F9F2: __strncmp_sse42 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28252==    by 0x408486: kh_put_hw_string_hashmap (http_request.c:37)
==28252==    by 0x408486: set_header (http_request.c:89)
==28252==    by 0x408F11: http_request_on_header_field (http_request.c:163)
==28252==    by 0x40DFF5: http_parser_execute (http_parser.c:1437)
==28252==    by 0x40A802: http_stream_on_read_http_parser (http_server.c:263)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==    by 0x4E3F6A9: start_thread (pthread_create.c:333)
==28252==  Address 0x19eebdda is 10,026 bytes inside a block of size 65,536 free'd
==28252==    at 0x4C2CE10: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==    by 0x4E3F6A9: start_thread (pthread_create.c:333)
==28252==
==28252== Invalid read of size 1
==28252==    at 0x4C2F9B9: __strncmp_sse42 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28252==    by 0x408300: kh_get_hw_string_hashmap (http_request.c:37)
==28252==    by 0x408300: get_header (http_request.c:65)
==28252==    by 0x4083B0: set_header (http_request.c:84)
==28252==    by 0x408FE1: http_request_on_headers_complete (http_request.c:203)
==28252==    by 0x40DF61: http_parser_execute (http_parser.c:1806)
==28252==    by 0x40A802: http_stream_on_read_http_parser (http_server.c:263)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==  Address 0x19eebdd9 is 10,025 bytes inside a block of size 65,536 free'd
==28252==    at 0x4C2CE10: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==    by 0x4E3F6A9: start_thread (pthread_create.c:333)
==28252==
==28252== Invalid read of size 1
==28252==    at 0x4C2F9F2: __strncmp_sse42 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28252==    by 0x408300: kh_get_hw_string_hashmap (http_request.c:37)
==28252==    by 0x408300: get_header (http_request.c:65)
==28252==    by 0x4083B0: set_header (http_request.c:84)
==28252==    by 0x408FE1: http_request_on_headers_complete (http_request.c:203)
==28252==    by 0x40DF61: http_parser_execute (http_parser.c:1806)
==28252==    by 0x40A802: http_stream_on_read_http_parser (http_server.c:263)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==  Address 0x19eebdda is 10,026 bytes inside a block of size 65,536 free'd
==28252==    at 0x4C2CE10: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28252==    by 0x41646F: uv__read (stream.c:1183)
==28252==    by 0x416BEB: uv__stream_io (stream.c:1250)
==28252==    by 0x41B129: uv__io_poll (linux-core.c:345)
==28252==    by 0x411B97: uv_run (core.c:351)
==28252==    by 0x40C12D: connection_consumer_start (connection_consumer.c:125)
==28252==    by 0x418566: uv__thread_start (thread.c:50)
==28252==    by 0x4E3F6A9: start_thread (pthread_create.c:333)

Moved freeing of request back to its original place until I figure out why this crashed.

@kellabyte I actually think the current approach is flawed. libuv calls the http_stream_on_alloc callback to have Haywire allocate memory for a new buffer. Then it uses that buffer to read data into and when that's done, it calls the http_stream_on_read_http_parser callback. If the buffer is bigger than what's required for the entire HTTP request, it's all good (in theory). However, if the buffer is not big enough, then we'll have some headers and potentially part of the body pointing to a memory block that is freed up as soon as http_stream_on_read_http_parser.
I don't see how we can avoid memory copies unfortunately, if we aim to support big enough requests that may not fit in single buffer chunk.
I'd be inclined to close this PR, given that the performance improvement is not significant and creates more problems than it solves.

@kellabyte as discussed on IRC, I've reverted the change so that the URL isn't zero-copied for now. This is now ready to merge, I think.
I'll take a stab at fixing #88 soon.


Add new Audit Loggers

Need the following events to be logged in the audit log file.

Feature
Event

Login
LoggedIn

Login
Failed Login Attempt

Login
Success Login after failure

Forgot Username
Username recovery

Forgot Password
Password recovery by email

Forgot Password
Password recovery by sms

Forgot Password
Password recovery by security questions

Edit Profile
Change password

Edit Profile
Security Questions - Insert

Edit Profile
Security Questions - Edit

Edit Profile
Preference

Edit Profile
Email Change

Edit Profile
Email change > confirm email

Edit Profile
Phone change

Edit Profile
Phone change -> confirm phone?

Edit Profile
Address change

Signup
Account signup

Signup
Account activation

Also the application name (SP name) should be logged along with the events, as appropriate. For example, login event should log SP name as well.

We have some new requirements, improvements that are needed to be done.

Unlock
New requirement : Missing audit log
-

Password reset
- Missing userstore domain of the user- Data JSON object is invalid, has extra parenthesis- User agent value is wrong. It has to be the browser.
TID: [-1234] [2020-08-21 02:33:34,698] [6bc35b40-be2a-4e79-a28c-7e3ed0fb6711]  INFO {AUDIT_LOG} - Initiator<EMAIL_ADDRESS>| Action : Password reset | Target : john | Data : { {"RemoteAddress":"<IP_ADDRESS>","User Agent":"Java/1.8.0_252"} } | Result : Success

Failed login
- Missing remote IP and user agent (are we expected to get it with context identifier?)- Missing userstore domain of the user
TID: [-1234] [2020-08-21 01:32:43,261] [df27cc3f-dec5-4599-b49b-130fe15388f1]  INFO {AUDIT_LOG} - Initiator : somapala | Action : Login | Target : ApplicationAuthenticationFramework | Data : { "ContextIdentifier" : "885d2aca-bd59-4165-8811-b01f0dd30510","ServiceProviderName" : "test-oauth","RequestType" : "oidc","RelyingParty" : "YooxECZR_PcgJk34xgptnie1eHoa","StepNo" : "1" } | Result : Failed

Locked
New requirement : Missing audit log
-

Success Login
- Missing remote IP and user agent- what is context identifier in the log?- Missing userstore domain of the user
Initiator : somapala | Action : Login | Target : ApplicationAuthenticationFramework | Data : { "ContextIdentifier" : "75832458-787c-422e-bf78-71e6c5c4436e","AuthenticatedUser" : "somapala","AuthenticatedUserTenantDomain" : "carbon.super","ServiceProviderName" : "test-oauth","RequestType" : "oidc","RelyingParty" : "YooxECZR_PcgJk34xgptnie1eHoa","AuthenticatedIdPs" : "eyJ0eXAiOiJKV1QiLCAiYWxnIjoiSFMyNTYifQ==.eyJpc3MiOiJ3c28yIiwiZXhwIjoxNTk3OTQ1MjQ0Nzg2MzAwMCwiaWF0IjoxNTk3OTQ1MjQ0Nzg2LCJpZHBzIjpbeyJpZHAiOiJMT0NBTCIsImF1dGhlbnRpY2F0b3IiOiJTSFJTU0ZpcnN0VGltZUF1dGhlbnRpY2F0b3IifV19.itgyxUPfUrmRVYmEEt+38LATQF8=" } | Result : Success

Account_Password_Reset_Request
- Missing userstore domain of the user- Data JSON object is invalid, has extra parenthesis- User agent value is wrong. It has to be the browser.Why cant we get service provider name/client id here?
TID: [-1234] [2020-08-25 03:05:16,851] [50a1474d-d793-497f-8150-af73eea3fb72]  INFO {AUDIT_LOG} - Initiator<EMAIL_ADDRESS>| Action : Password recovery | Target : asanka | Data : { {"RemoteAddress":"<IP_ADDRESS>","User Agent":"Java/1.8.0_252","Notification Channel":"EMAIL"} } | Result : Success

Account_Forgot_Username
Missing promised log
-


Search input in Extensions view and Settings is broken

Also they cannot be editable.

Fixed after recompiling.


Make edx-lint commands work with both python2 and python3

@nedbat, @clintonb: I had to make these changes to make it so that the IDA cookiecutter could run in both python2 and python3 virtualenvs.

:+1:

:+1: once the type names are changed in the docstring.


feat: cli arg to disable minification

Introduces a CLI arg to let people choose to disable minification (e.g. for debugging purposes).
Only applies to the cache handler at the moment as that's the only part being minified currently.

Thanks a lot for updating the code @james-elicx.
Sorry to bother you with nit-picks but I think it's goos to start to improve things little by little.

Sorry to bother you with nit-picks

It's no worries at all, I don't mind it


fix(providerService): Decode tokens using UTF-8

Added the jwt-decode package to ensure auth token is decoded with UTF-8 support.
Fixes: https://github.com/fabric8io/fabric8-ui/issues/1285

@dlabrecq snapshot fabric8-ui is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-1300-fabric8-ui.int.rdu2c.fabric8.io

@dlabrecq I cannot login on https://fabric8-ui-fabric8-ui-pr-1300-fabric8-ui.int.rdu2c.fabric8.io

The snapshot appears to use a prod-preview environment. Perhaps you're authorized for prod only?

@dlabrecq I managed to open the link and link my Github account but I'm not 100% sure that my name in my account is still set to the same string (with Slovak characters)

@ppitonak your profile doesn't have any Slovak characters anymore. I updated it before the issue was fixed.

@alexeykazakov is there a way for me to re-set it to contain Slovak characters again? I also probably need to unlink my Github account to verify this PR.

@ppitonak see PM in Mattermost

@dlabrecq snapshot fabric8-ui is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-1300-fabric8-ui.int.rdu2c.fabric8.io


Bot did not respond to valid command

See https://github.com/callstack/react-native-paper/pull/863#issuecomment-466451254

Could not reproduce. Have better monitoring in place now


MINOR: Ensure heartbeat last poll time always updated

We need to ensure that the last poll time is always updated when the user call poll(Duration). This patch fixes a bug in the new KIP-266 timeout behavior which would cause this to be skipped if the coordinator could not be found while the consumer was in an active group.
Note that I've also fixed some type inconsistencies for various timeouts.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Cherry-picked to 2.0 as well.


[MINOR] Add caveat for multiwriter usage

Brief change log
Adding caveat for multiwriter
Committer checklist

[ ] Has a corresponding JIRA in PR title & commit

[ ] Commit message is descriptive of the change

[ ] CI is green

[ ] Necessary doc changes done or have another open PR

[ ] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

@nsivabalan Can you review this ?


[Monitor]Fix 10348: bump sdk version and support mutiple scopes

Fix #10348
This checklist is used to make sure that common guidelines for a pull request are followed.

[ ] The PR has modified HISTORY.rst describing any customer-facing, functional changes. Note that this does not include changes only to help content. (see Modifying change log).

[ ] I adhere to the Command Guidelines.

some tests failed, please check.

@fengzhou-msft Yes. I will close this PR later. This is used for a meeting and share the code with others.


Changing header for PPP

As of now, the header for Platform & PPP is the same. We need to change the header for PPP.

Thanks @prashantuniyal02. Is this one the change of the logo in the navbar?

No, this is regrading the 'home button' on every page.

Changed


watchcat is not work on 21.02

SyntaxError
Failed to set the 'innerHTML' property on 'Element': The provided markup is invalid XML, and therefore cannot be inserted into an XML document.

Can you please provide a screenshot of this?  I am unable to reproduce it on 21.02.1.

Can you please provide a screenshot of this?  I am unable to reproduce it on 21.02.1.


Dash R 1.0 release

This PR merges in the changes from dev to master and updates the package, including the DESCRIPTION and CHANGELOG, in preparation for the Dash R 1.0 release to Github and CRAN.

[x]  Update CHANGELOG with updates based on commit history.
[x] Run checks and update package for CRAN submission.

@daattali

Hey @alexcjohnson @daattali
I've updated the Dash R package and made the last few adjustments based on the checks that should prepare it for the CRAN re-submission and release.
If there's anything else that stands out or anything else we want to add prior to that feel free to let me know.
@daattali it might be a good idea to maybe install and run it in your local environment with the manual test apps, just to check for any inconsistencies that might exist between our development envs and R libraries.

[ ] Don't namespace dash:: inside the dash package - it's redundant and confusing (I saw a few such cases in /tests/manual/ and in documentation, there might be others)
[ ] I would prefer to combine all the HTML components (htmlDiv, htmlBr, etc) into one file, and similarly all the interactive components (dcc*) into another file. This way will dramatically reduc ethe number of source files clutter
[ ] I suggest updating the DESCRIPTION to use testthat version >3.0.0 , and then removing all context() calls from the test files (it's deprecated)
[ ] The tests/circleci/fixup_metadata.R file should either be removed or moved to an appropriate folder
[ ] In the dashCoreComponents package, the second argument of many components was value. Now the arguments are alphabetical and value has been moved to the last. This is a breaking change, and I strongly believe it should be fixed because having value as the second argument makes sense so that you don't have to always explicitly name it. @alexcjohnson @jackparmer this is now an issue with this package but this package is affected - where should I open an issue for this?
[ ] The check that all states come after all inputs can be removed using the new flexible callback syntax https://github.com/plotly/dashR/blob/5c80285b90c24cf15375e6763b56425e9dc530ce/R/utils.R#L378-L381
[ ] This is perhaps not directly related to this PR, but should be fixed: using input() instead of output() inside callbacks works. It shouldn't. There should be a check that anything supplied to the callback outputs is actually of class "output"

Let me know when the package is ready for re-testing

Don't namespace dash:: inside the dash package - it's redundant and confusing (I saw a few such cases in /tests/manual/ and in documentation, there might be others)

Fixed in d419517 and  3aa7abd.

I would prefer to combine all the HTML components (htmlDiv, htmlBr, etc) into one file, and similarly all the interactive components (dcc*) into another file. This way will dramatically reduce the number of source files clutter

Concatenated components into package R scripts in cb93cdb. Note, this change requires the merge of https://github.com/plotly/dash/pull/1798 to make this a streamlined process, and also address the NAMESPACE generation with devtools::document().

I suggest updating the DESCRIPTION to use testthat version >3.0.0 , and then removing all context() calls from the test files (it's deprecated)

Updated in aff9b99.

The tests/circleci/fixup_metadata.R file should either be removed or moved to an appropriate folder

Removed in 0ad3b24.

In the dashCoreComponents package, the second argument of many components was value. Now the arguments are alphabetical and value has been moved to the last. This is a breaking change, and I strongly believe it should be fixed because having value as the second argument makes sense so that you don't have to always explicitly name it. @alexcjohnson @jackparmer this is now an issue with this package but this package is affected - where should I open an issue for this?

I think the most appropriate repo for this issue would be in dash, with a label for dashCoreComponents.

The check that all states come after all inputs can be removed using the new flexible callback syntax

Removed in 68427b3.

This is perhaps not directly related to this PR, but should be fixed: using input() instead of output() inside callbacks works. It shouldn't. There should be a check that anything supplied to the callback outputs is actually of class "output"

Fixed with 68427b3.

Awesome!
Do the CI checks run the unit tests, and that's why they failed previously? It looks like there's a build step in CircleCI , I assume that part of that includes running the tests, but I'm not able to see it since I don't have access to that account.
I think this PR is ready except for the breaking change of the order of parameters to dcc components changed. I think we should wait until we decide what to do about that, whether we'll fix it directly at the R level or higher up the chain

@daattali I've reverted the prop order to the original order for the time being. We can talk about that more in detail next week, but if everything else looks good I think this should be ready to merge at this point.


[Feature]

Description

Currently, in the typing speed calculator, the given string does not automatically change after the user correctly types it and the typing speed is calculated. This enhancement proposes an improvement where, once the string is correctly typed and the speed is calculated, the string automatically changes to a new one from a predefined list and the input box is also cleared.

Benefits

Improved User Experience: Users can continuously practice typing without manual intervention to change the string.
Seamless Transition: Provides a smooth transition between typing tests, making the application more efficient and user-friendly.

I would like to request to be assigned to this issue under the GSSOC '24 contribution.
Screenshots

Checklist

[X] I have checked the existing issues.
[X] I follow Contributing Guidelines of this project.
[x] I am a GSSOC'24 contributor.
[ ] I am a IWOC'24 contributor.
[ ] I am a JWOC'24 contributor.
[ ] I am a SWOC'24 contributor.

Code of Conduct

[X] I agree to follow this project's "Code of Conduct".

Go ahead @Anurag-Gour


change scanpy language to python for consistency

Thanks, @ckmah, for the first contribution and good eye. Keep them coming.


hhs cadence&latency documentation is imprecise, outdated; hhs acquisition might be late

Actual Behavior:
Documentation states

HHS issues updates to this timeseries once a week, and occasionally more often. We check for updates daily. Lag varies from 0 to 6 days.

There was a reporting cadence change around the beginning of July 2023 that impacts this statement, and I don't think this precisely describes either the pre- or post- cadence-change state.
Prior to cadence change:

Lag 0 should be impossible.  Since we are not reporting previous_day_* measurements but instead shifting them to the relevant days, we won't have a measurement about admissions/etc. that happen today, reported today.
In practice, updates seemed to occur more than weekly very regularly, and lag was 2 days most places&versions, with extremes of 1 day and 16 days.

Post cadence change:
The expected cadence appears to be sort of weekly, technically twice a week:

Preliminary data pertaining to Sat--Fri is published the following Fri.  (Upstream, this appears as Sun--Sat previous_day_* data.)
Revisions to these measurements are published on Monday, but initial measurements for later days aren't added.

The encountered lag in our hhs endpoint is 8 to 14 days, plus some versions that were staler due to transient issues (up to 18 days of lag, or 26 for American Samoa).  That's 1 day higher than expected.
Expected behavior

Documentation should note the cadence change, and somewhat accurately describe the current cadence, and maybe the prior cadence as well.
The typical lag range encountered should be 7 to 13, not 8 to 14.  (I think I might have seen this already in an Issue or Slack thread about the acquisition being performed at the end of the day, but I can't seem to relocate it.  It might have referenced covid_hosp rather than hhs.)

Context

I spotted this while reading the documentation for other purposes.  However, I do have some plots of lag by location & version generated by this Rmd for the influenza admissions signal.  Swapping for the covid signal seemed to give similar/identical results regarding lag.

The time of day at which reporting occurs may also have shifted.  So if things are shifted back to the day they are published, we can't use the originally planned timing.  See here.

Update: HHS reporting cadence has changed to Wed + Fri.  The acquisition pipeline has been updated to ensure we will get Wed data into the API on Wed moving forward, but Fri updates to hhs data source may still be recorded on Sat.


Adding Spark's JDBC sink to write Raw data and other enhancements

Ability to run on AWS EMR
Performance improvements
Introducing JDBC V2 sink. This based on Spark's JDBC sink to write Raw data.
Making some parameters configurable
Code clean up and applying code-styles

Hi @sushil-thasale
We have configured CDA client and able to get all CSVs to Azure fileshare, but we dont see batchmatrics.json for those tables. Could you please help us on how to get this file updating the CDA-client code, as we are not able to reconcile without this file.
Thanks you


Add download link for Skype for Business, SDN Interface 3.0

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

Skype/SDN/articles/installing-sdn-interface.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Not sure if this is the best link to use, but I think there should be some indication of where to get the latest SDN Interface. Depending on what search terms you use, you may not find the latest version. For example, searching for "skype sdn interface download" on Google or Bing returns links for version 2.2 or 2.4.1.


async function response turns log store into an async call persisted store

problem
When you create and call a sync function you'll get the response immediately.
However, if you'd turn that function into an async one, whatever function will write back to stdout will end up in logs.
steps to reproduce

create a function:

fn init --runtime go && fn deploy

call function:

fn call <app> <path>

Make it async:

fn routes update <app> <path> --type async

call function:

fn call <app> <path> --display-call-id

check call logs:

fn calls get <app> <call-id>

You'll see that depending on the protocol call log will include a response frame.
question
Is there any reason to intentionally make the log store to become a persisted store for async results?

yes, you would lose headers, for one.
this is pretty straightforward once we have cloud events.

I mean, why should we store the response of the async function? It makes Fn's log store a result storage.

not sure it's worth discussing, async is gonna get killed.

okay.


Allow nested directories while still keeping the flat collection / blob hierarchy

Please add a test adding and retrieving a nested directory.

@flub one thing this changes it that it enforces that a collection has only one item per name. I assume that is fine, but just want to make sure this does not cause any trouble in the deltachat use case.

@flub one thing this changes it that it enforces that a collection has only one item per name. I assume that is fine, but just want to make sure this does not cause any trouble in the deltachat use case.

yes, that's fine.  all blob names come from file names in a flat directory in deltachat.  I do prefix all names with blob/ however, so file names are blob/foo, blob/bar etc.  all this canonicalisation is on the application side of things and not the lib right?

@flub one thing this changes it that it enforces that a collection has only one item per name. I assume that is fine, but just want to make sure this does not cause any trouble in the deltachat use case.

yes, that's fine. all blob names come from file names in a flat directory in deltachat. I do prefix all names with blob/ however, so file names are blob/foo, blob/bar etc. all this canonicalisation is on the application side of things and not the lib right?

Yes. The only place where / is interpreted as a directory separator is in main. We might want to add this to the lib in the future, since the way it is now the lib does not help you in creating a directory tree. But for now this is completely separate.