No longer scrobbling after one entry

On very first script run, works with one entry then stops working. Cannot fix until restart PC (Windows 7) and rerun script.
logs start printing this only and nothing is being reported to tvshowtime.
[DEBUG] Possible log file rotation, resetting file handle (st_mtime=Thu Jul 16 12:01:36 2015)
More example..
2015-07-16 08:52:57,138 [5096] [main <module>] [DEBUG] config : mediaserver_log_location -> C:\Users\Fabrizio\AppData\Local\Plex Media Server/Logs/Plex Media Server.log
2015-07-16 08:52:57,138 [5096] [main <module>] [DEBUG] config : session -> G:\logs\plex_tvst_scrobbler_session_key
2015-07-16 08:52:57,138 [5096] [main <module>] [DEBUG] config : config file location -> C:\Users\Fabrizio/.config/plex-tvst-scrobbler/plex_tvst_scrobbler.conf
2015-07-16 08:52:57,138 [5096] [main <module>] [DEBUG] config : log_file -> temp\
2015-07-16 08:52:57,138 [5096] [main <module>] [DEBUG] config : mediaserver_url -> http://localhost:32400
2015-07-16 08:52:57,138 [5096] [main <module>] [DEBUG] using tvshowtime.com session key=G:\logs\plex_tvst_scrobbler_session_key , st_mtime=Wed Jul 15 21:16:00 2015
2015-07-16 08:52:57,138 [5096] [main main] [INFO] starting log monitor thread.
2015-07-16 08:54:27,019 [5096] [plex_tvst_scrobbler.plex_monitor monitor_log] [DEBUG] Possible log file rotation, resetting file handle (st_mtime=Thu Jul 16 08:53:27 2015)
2015-07-16 08:54:47,381 [5096] [plex_tvst_scrobbler.plex_monitor monitor_log] [DEBUG] Possible log file rotation, resetting file handle (st_mtime=Thu Jul 16 08:54:47 2015)
2015-07-16 09:08:51,023 [5096] [plex_tvst_scrobbler.plex_monitor monitor_log] [DEBUG] Possible log file rotation, resetting file handle (st_mtime=Thu Jul 16 09:07:51 2015)
2015-07-16 09:14:43,019 [5096] [plex_tvst_scrobbler.plex_monitor monitor_log] [DEBUG] Possible log file rotation, resetting file handle (st_mtime=Thu Jul 16 09:13:43 2015)
2015-07-16 09:54:59,019 [5096] [plex_tvst_scrobbler.plex_monitor monitor_log] [DEBUG] Possible log file rotation, resetting file handle (st_mtime=Thu Jul 16 09:53:59 2015)
2015-07-16 09:55:01,365 [5096] [plex_tvst_scrobbler.plex_monitor monitor_log] [DEBUG] Possible log file rotation, resetting file handle (st_mtime=Thu Jul 16 09:55:01 2015)
2015-07-16 09:56:39,009 [5096] [plex_tvst_scrobbler.plex_monitor monitor_log] [DEBUG] Possible log file rotation, resetting file handle (st_mtime=Thu Jul 16 09:55:39 2015)
2015-07-16 10:01:49,025 [5096] [plex_tvst_scrobbler.plex_monitor monitor_log] [DEBUG] Possible log file rotation, resetting file handle (st_mtime=Thu Jul 16 10:00:49 2015)
2015-07-16 10:02:53,006 [5096] [plex_tvst_scrobbler.plex_monitor monitor_log] [DEBUG] Possible log file rotation, resetting file handle (st_mtime=Thu Jul 16 10:01:53 2015)
2015-07-16 10:07:13,023 [5096] [plex_tvst_scrobbler.plex_monitor monitor_log] [DEBUG] Possible log file rotation, resetting file handle (st_mtime=Thu Jul 16 10:06:13 2015)
2015-07-16 10:39:35,016 [5096] [plex_tvst_scrobbler.plex_monitor monitor_log] [DEBUG] Possible log file rotation, resetting file handle (st_mtime=Thu Jul 16 10:38:35 2015)
2015-07-16 10:43:43,025 [5096] [plex_tvst_scrobbler.plex_monitor monitor_log] [DEBUG] Possible log file rotation, resetting file handle (st_mtime=Thu Jul 16 10:42:43 2015)
2015-07-16 11:29:15,025 [5096] [plex_tvst_scrobbler.plex_monitor monitor_log] [DEBUG] Possible log file rotation, resetting file handle (st_mtime=Thu Jul 16 11:28:15 2015)
2015-07-16 11:30:33,005 [5096] [plex_tvst_scrobbler.plex_monitor monitor_log] [DEBUG] Possible log file rotation, resetting file handle (st_mtime=Thu Jul 16 11:29:33 2015)
2015-07-16 12:02:36,019 [5096] [plex_tvst_scrobbler.plex_monitor monitor_log] [DEBUG] Possible log file rotation, resetting file handle (st_mtime=Thu Jul 16 12:01:36 2015)
My BAT
set root=C:\Python26\
CD /D %root%
python Scripts\plex-tvst-scrobbler.py
cmd /k

Hmm could be related to python version, now using very latest and 5 entries in still working.
Sorry could be a non issue.

It has started to happen again
2015-07-16 23:25:39,865 [2972] [main <module>] [DEBUG] config : mediaserver_log_location -> C:\Users\Fabrizio\AppData\Local\Plex Media Server/Logs/Plex Media Server.log
2015-07-16 23:25:39,865 [2972] [main <module>] [DEBUG] config : session -> G:\logs\plex_tvst_scrobbler_session_key
2015-07-16 23:25:39,865 [2972] [main <module>] [DEBUG] config : mediaserver_url -> http://localhost:32400
2015-07-16 23:25:39,865 [2972] [main <module>] [DEBUG] config : config file location -> C:\Users\Fabrizio/.config/plex-tvst-scrobble/plex_tvst_scrobbler.conf
2015-07-16 23:25:39,865 [2972] [main <module>] [DEBUG] config : log_file -> logs.txt
2015-07-16 23:25:39,865 [2972] [main <module>] [DEBUG] using tvshowtime.com session key=G:\logs\plex_tvst_scrobbler_session_key , st_mtime=Wed Jul 15 21:16:00 2015
2015-07-16 23:25:39,865 [2972] [main main] [INFO] starting log monitor thread.
2015-07-16 23:26:39,743 [2972] [plex_tvst_scrobbler.plex_monitor parse_line] [INFO] Found played TV show and extracted library id '3791' from plex log
2015-07-16 23:26:39,743 [2972] [plex_tvst_scrobbler.plex_monitor fetch_metadata] [INFO] Fetching library metadata from http://localhost:32400/library/metadata/3791
2015-07-16 23:26:41,154 [2972] [plex_tvst_scrobbler.plex_monitor fetch_metadata] [INFO] Matched TV show Peppa Pig S04E39
2015-07-16 23:26:41,157 [2972] [plex_tvst_scrobbler.tvst scrobble] [INFO] submitting 79222 - S04E39 to tvshowtime.com.
2015-07-16 23:26:49,642 [2972] [plex_tvst_scrobbler.plex_monitor parse_line] [INFO] Found played TV show and extracted library id '3791' from plex log
2015-07-16 23:26:49,642 [2972] [plex_tvst_scrobbler.plex_monitor monitor_log] [WARNING] Dupe detection : 3791, not submitting
2015-07-16 23:27:33,237 [2972] [plex_tvst_scrobbler.plex_monitor parse_line] [INFO] Found played TV show and extracted library id '1152' from plex log
2015-07-16 23:27:33,237 [2972] [plex_tvst_scrobbler.plex_monitor fetch_metadata] [INFO] Fetching library metadata from http://localhost:32400/library/metadata/1152
2015-07-16 23:27:34,292 [2972] [plex_tvst_scrobbler.plex_monitor fetch_metadata] [INFO] Matched TV show Seinfeld S01E01
2015-07-16 23:27:34,292 [2972] [plex_tvst_scrobbler.tvst scrobble] [INFO] submitting 79169 - S01E01 to tvshowtime.com.
2015-07-16 23:27:43,108 [2972] [plex_tvst_scrobbler.plex_monitor parse_line] [INFO] Found played TV show and extracted library id '1152' from plex log
2015-07-16 23:27:43,108 [2972] [plex_tvst_scrobbler.plex_monitor monitor_log] [WARNING] Dupe detection : 1152, not submitting
2015-07-16 23:27:53,104 [2972] [plex_tvst_scrobbler.plex_monitor parse_line] [INFO] Found played TV show and extracted library id '1152' from plex log
2015-07-16 23:27:53,104 [2972] [plex_tvst_scrobbler.plex_monitor monitor_log] [WARNING] Dupe detection : 1152, not submitting
2015-07-16 23:28:03,095 [2972] [plex_tvst_scrobbler.plex_monitor parse_line] [INFO] Found played TV show and extracted library id '1152' from plex log
2015-07-16 23:28:03,095 [2972] [plex_tvst_scrobbler.plex_monitor monitor_log] [WARNING] Dupe detection : 1152, not submitting
2015-07-16 23:28:14,194 [2972] [plex_tvst_scrobbler.plex_monitor parse_line] [INFO] Found played TV show and extracted library id '1152' from plex log
2015-07-16 23:28:14,194 [2972] [plex_tvst_scrobbler.plex_monitor monitor_log] [WARNING] Dupe detection : 1152, not submitting
2015-07-17 00:09:48,002 [2972] [plex_tvst_scrobbler.plex_monitor monitor_log] [DEBUG] Possible log file rotation, resetting file handle (st_mtime=Fri Jul 17 00:08:48 2015)
2015-07-17 00:24:50,003 [2972] [plex_tvst_scrobbler.plex_monitor monitor_log] [DEBUG] Possible log file rotation, resetting file handle (st_mtime=Fri Jul 17 00:23:50 2015)
2015-07-17 00:30:00,016 [2972] [plex_tvst_scrobbler.plex_monitor monitor_log] [DEBUG] Possible log file rotation, resetting file handle (st_mtime=Fri Jul 17 00:29:00 2015)
2015-07-17 01:00:36,029 [2972] [plex_tvst_scrobbler.plex_monitor monitor_log] [DEBUG] Possible log file rotation, resetting file handle (st_mtime=Fri Jul 17 00:59:36 2015)
2015-07-17 02:29:21,019 [2972] [plex_tvst_scrobbler.plex_monitor monitor_log] [DEBUG] Possible log file rotation, resetting file handle (st_mtime=Fri Jul 17 02:28:21 2015)
2015-07-17 04:30:03,023 [2972] [plex_tvst_scrobbler.plex_monitor monitor_log] [DEBUG] Possible log file rotation, resetting file handle (st_mtime=Fri Jul 17 04:29:03 2015)
2015-07-17 06:29:18,010 [2972] [plex_tvst_scrobbler.plex_monitor monitor_log] [DEBUG] Possible log file rotation, resetting file handle (st_mtime=Fri Jul 17 06:28:18 2015)
2015-07-17 07:37:14,398 [2972] [plex_tvst_scrobbler.plex_monitor parse_line] [INFO] Found played TV show and extracted library id '1153' from plex log
2015-07-17 07:37:14,398 [2972] [plex_tvst_scrobbler.plex_monitor fetch_metadata] [INFO] Fetching library metadata from http://localhost:32400/library/metadata/1153
2015-07-17 07:37:15,430 [2972] [plex_tvst_scrobbler.plex_monitor fetch_metadata] [INFO] Matched TV show Seinfeld S01E02
2015-07-17 07:37:15,438 [2972] [plex_tvst_scrobbler.tvst scrobble] [INFO] submitting 79169 - S01E02 to tvshowtime.com.
2015-07-17 07:37:24,427 [2972] [plex_tvst_scrobbler.plex_monitor parse_line] [INFO] Found played TV show and extracted library id '1153' from plex log
2015-07-17 07:37:24,427 [2972] [plex_tvst_scrobbler.plex_monitor monitor_log] [WARNING] Dupe detection : 1153, not submitting
2015-07-17 07:37:34,418 [2972] [plex_tvst_scrobbler.plex_monitor parse_line] [INFO] Found played TV show and extracted library id '1153' from plex log
2015-07-17 07:37:34,418 [2972] [plex_tvst_scrobbler.plex_monitor monitor_log] [WARNING] Dupe detection : 1153, not submitting
2015-07-17 07:37:44,530 [2972] [plex_tvst_scrobbler.plex_monitor parse_line] [INFO] Found played TV show and extracted library id '1153' from plex log
2015-07-17 07:37:44,530 [2972] [plex_tvst_scrobbler.plex_monitor monitor_log] [WARNING] Dupe detection : 1153, not submitting
2015-07-17 07:37:46,061 [2972] [plex_tvst_scrobbler.plex_monitor parse_line] [INFO] Found played TV show and extracted library id '1153' from plex log
2015-07-17 07:37:46,061 [2972] [plex_tvst_scrobbler.plex_monitor monitor_log] [WARNING] Dupe detection : 1153, not submitting
2015-07-17 07:39:12,473 [2972] [plex_tvst_scrobbler.plex_monitor parse_line] [INFO] Found played TV show and extracted library id '3713' from plex log
2015-07-17 07:39:12,473 [2972] [plex_tvst_scrobbler.plex_monitor fetch_metadata] [INFO] Fetching library metadata from http://localhost:32400/library/metadata/3713
2015-07-17 07:39:13,500 [2972] [plex_tvst_scrobbler.plex_monitor fetch_metadata] [INFO] Matched TV show Peppa Pig S03E14
2015-07-17 07:39:13,502 [2972] [plex_tvst_scrobbler.tvst scrobble] [INFO] submitting 79222 - S03E14 to tvshowtime.com.
2015-07-17 07:40:19,661 [2972] [plex_tvst_scrobbler.plex_monitor parse_line] [INFO] Found played TV show and extracted library id '3713' from plex log
2015-07-17 07:40:19,661 [2972] [plex_tvst_scrobbler.plex_monitor monitor_log] [WARNING] Dupe detection : 3713, not submitting
2015-07-17 07:40:30,221 [2972] [plex_tvst_scrobbler.plex_monitor parse_line] [INFO] Found played TV show and extracted library id '3713' from plex log
2015-07-17 07:40:30,221 [2972] [plex_tvst_scrobbler.plex_monitor monitor_log] [WARNING] Dupe detection : 3713, not submitting
2015-07-17 07:41:12,134 [2972] [plex_tvst_scrobbler.plex_monitor parse_line] [INFO] Found played TV show and extracted library id '1154' from plex log
2015-07-17 07:41:12,134 [2972] [plex_tvst_scrobbler.plex_monitor fetch_metadata] [INFO] Fetching library metadata from http://localhost:32400/library/metadata/1154
2015-07-17 07:41:13,164 [2972] [plex_tvst_scrobbler.plex_monitor fetch_metadata] [INFO] Matched TV show Seinfeld S01E03
2015-07-17 07:41:13,165 [2972] [plex_tvst_scrobbler.tvst scrobble] [INFO] submitting 79169 - S01E03 to tvshowtime.com.
2015-07-17 07:41:22,506 [2972] [plex_tvst_scrobbler.plex_monitor parse_line] [INFO] Found played TV show and extracted library id '1154' from plex log
2015-07-17 07:41:22,506 [2972] [plex_tvst_scrobbler.plex_monitor monitor_log] [WARNING] Dupe detection : 1154, not submitting
2015-07-17 07:41:32,017 [2972] [plex_tvst_scrobbler.plex_monitor parse_line] [INFO] Found played TV show and extracted library id '1154' from plex log
2015-07-17 07:41:32,017 [2972] [plex_tvst_scrobbler.plex_monitor monitor_log] [WARNING] Dupe detection : 1154, not submitting
2015-07-17 07:41:36,997 [2972] [plex_tvst_scrobbler.plex_monitor parse_line] [INFO] Found played TV show and extracted library id '1154' from plex log
2015-07-17 07:41:36,997 [2972] [plex_tvst_scrobbler.plex_monitor monitor_log] [WARNING] Dupe detection : 1154, not submitting
2015-07-17 08:29:50,013 [2972] [plex_tvst_scrobbler.plex_monitor monitor_log] [DEBUG] Possible log file rotation, resetting file handle (st_mtime=Fri Jul 17 08:28:50 2015)
2015-07-17 10:30:14,000 [2972] [plex_tvst_scrobbler.plex_monitor monitor_log] [DEBUG] Possible log file rotation, resetting file handle (st_mtime=Fri Jul 17 10:29:14 2015)
2015-07-17 12:29:53,502 [2972] [plex_tvst_scrobbler.plex_monitor monitor_log] [DEBUG] Possible log file rotation, resetting file handle (st_mtime=Fri Jul 17 12:28:53 2015)
2015-07-17 12:29:57,667 [2972] [plex_tvst_scrobbler.plex_monitor monitor_log] [DEBUG] Possible log file rotation, resetting file handle (st_mtime=Fri Jul 17 12:29:57 2015)
2015-07-17 12:31:09,017 [2972] [plex_tvst_scrobbler.plex_monitor monitor_log] [DEBUG] Possible log file rotation, resetting file handle (st_mtime=Fri Jul 17 12:30:09 2015)
2015-07-17 13:31:21,022 [2972] [plex_tvst_scrobbler.plex_monitor monitor_log] [DEBUG] Possible log file rotation, resetting file handle (st_mtime=Fri Jul 17 13:30:21 2015)

It stopped working again, I haven't touched anything since.

Having the exact same problem. No matter what I do, after a day or so it fails to scrobble and give the log rotation message.
Would love to get this working properly :(

fabrizio5680 any chance you might help me intall this on windows?


Swaggerfox 2.5.0 supports the custom request-body and treated it as body type. But the latest version 2.9.2 is not supporting.

Please take the time to search the repository, if your question has already been asked or answered.

[ ] What version of the library are you using? Is it the latest version? The latest released version is

What kind of issue is this?

[ ] Question. Is this a question about how to do a certain thing?

[ ] Bug report. If you’ve found a bug, spend the time to write a failing test. Bugs with tests or
steps to reproduce get fixed faster. Here’s an example: https://gist.github.com/swankjesse/6608b4713ad80988cdc9

[ ] spring xml/java config that is relevant
[ ] springfox specific configuration if it makes sense
[ ] include any output you've received; logs, json snippets etc.; and what the expected output should be
[ ] if you have a repo that demonstrates the issue for bonus points! See this example

[ ] Feature Request. Start by telling us what problem you’re trying to solve. Often a solution
already exists! Don’t send pull requests to implement new features without first getting our
support. Sometimes we leave features out on purpose to keep the project small.

Please do consider starring this repository if you do like this project and find it useful.

@NarendhiranBala if you need it to behave like a request body then you need to annotate it as @RequestBody

@dilipkrish In spring hibernate, we found that the best way for updating entity partially by introducing a custom request parameter for RequestBody. We tried this suggestion ( https://stackoverflow.com/questions/18226629/hibernate-update-object-partially ) too, but not helpful with Swagger.
APIs are working as expected with body data when we hit this APIs using "Postman" tool, we faced issues only swagger API docs generator. I tried with ModelAttributes for header and body but they are rendered as query parameters instead of header and body (version 2.8.0 and 2.9.1).
Currently, we have managed with  ignoredParameterTypes(PatchRequestBody.class)  and @ApiImplicitParams(..., paramType = "body") for swagger API.


Add testnet configuration for released app

In case the app is released it should point to the testnet maker, etc. instead of regtest.

it seems it should be enough to swap the maker_pk() to hard-coded testnet key in the release mode?

it might be enough to swap the maker_pk() to hard-coded testnet key in the release mode?

Not just the public key, but also the endpoint and the network. - network is currently provided through flutter though. For consistency this should probably also be configured in wallet.rs (still not a fan of managing configuration in code 🙈 )


fix: correctly locate projectId from auth library

Fixes https://github.com/googleapis/nodejs-bigquery/issues/936
Previously, the user's project ID was checked against a private property from google-auth-library: _cachedProjectId. This is not always set, including when a keyFilename argument is passed. I found a method from the auth library, getProjectId(), which will first search for, then return the most correct project ID.

@stephenplusplus, excited to get this PR merged! Would you mind taking a look at some of our comments, excited to look over and merge soon.

What's remaining on this PR?

I think we just need a @sofisl review.


WIP: Wholesale conversion to a Swift package

Futzin' around after watching the WWDC videos on SPM
Currently, this builds + tests just fine. However, it doesn't have Carthage/CocoaPods support.

Most of this is moves, right? s/Source/Sources?

fwiw, I think it's really early to be dropping CocoaPods/Carthage support. That being said, I think we can/should absolutely push our SwiftPM support forward as being the preferred method going forward. Once Xcode 10.11 fully launches I think I'd be 👍 on making the move final (especially since you can always get to the older releases on GitHub/Trunk)

@gfontenot –
Yeah it's mostly just moves + a swiftformat pass. (I should commit the .swiftformat, probably!) I totally agree that it is too early to drop CocoaPods/Carthage support, I just ignored them while getting the package set up for now – I intend to add them back in before merging.

I can't for the life of me get the tests building/passing on CI. I think that's the last thing we need before we can merge this.

I can't for the life of me get the tests building/passing on CI

Something about deps, right? Have you ran bin/setup && bin/test in a clean repo? I wonder if you have some old artifacts from previous builds kicking around.


what's the logic on project admin-build using yarn instead of npm?

Question
I had trouble running shopware-cli project admin-build because one of the store-plugins installed with composer contained a yarn.lock file.
looks like admin-build uses yarn inside the plugin directory if a yarn.lock file is found?
is there a way to force npm? or at least fall back to npm if yarn fails? afaik yarn is not a requirement for shopware
in my case: using bin/build-administration.sh works
issue1: if yarn is not installed admin-build failes
issue2: that yarn.lock was malformed - so even if installing yarn the build failes - and because the yarn.lock file is from an external dependency the fix delting the yarn.lock file is not the best option

Is yarn not installed or does it really yarn fail?
The problem with running npm is that the yarn.lock does nothing and maybe newer packages will be installed

yarn was not installed - in this case admin-build stopped with an error that yarn is missing
after installing it I had an issue with the yarn file in that plugin
error SyntaxError: Invalid value type 1283:0 in ...src/Resources/app/administration/yarn.lock
looks like an error in the plugin - or version mismatch with yarn (i'm not really a node expert)
btw. that plugin has a package-lock.json and a yarn.lock included
main question: the "normal" way using bin/build-administration.sh only uses npm afaik - so for consistency it should be better using the same logic in shopware-cli? if the plugin manufacturer is using yarn only that wouldn't work in the default way?


DOCS: User Guide - Administration Section Updates

💡 Summary
Please hide the Administration section as a whole due to the fact this site will be used for a standard user as of now
Motivation and context
Standard users can not perform Administration tasks
Implementation notes
Please hide or delete the Administration section as a whole
Acceptance criteria
How do we know when this work is done?

When all updates have been made to the User Guide Quickstart section and have been confirmed with either Nicole Q, Jennifer T, Mina S, or Jonathan H

The request to remove this section is not impacted by the rebranding of the Crossfeed Platform to the CyHy Dashboard. This issue can be implemented as requested.

This is OBE. Scope has changed and no requirements were derived for the initial portion of this task.


Remove old search.html template

This seems to be un-used, so remove as a bit of a cleanup.

Based on the text, I would think it gets used on https://matplotlib.org/stable/search.html and https://matplotlib.org/mpl-third-party/search.html, but we have a copy downstream at https://github.com/matplotlib/matplotlib/blob/main/doc/_templates/search.html without one in mpl-third-party. And that additional text really seems to only make sense on the main repo, not mpl-third-party, so it's good to remove it here.


Disable panning on mobile

This PR disables panning on mobile by directly overwriting the move method of the WWTControl to be a no-op function. Additionally, we do the same for rolling in general - we were already disabling rolling via a watcher, but this is smoother.

Merged into #126


move vue and vue-calendar-heatmap to webpack

unvendor vue and vue-calendar-heatmap
remove unused moment.js leftover from previous heatmap version
ensure webpack loads the full version of vue
fix vue devmode warning related to 'searchLimit' type

I wanted to name the chunk heatmap.js but adblockers don't like that filename [1].
[1] https://github.com/easylist/easylist/blob/3899d5dff33216c0bc64f09ff15d376f346d3e33/easyprivacy/easyprivacy_general.txt#L2095

There are more Vue warnings visible when webpack builds in development mode. I want to eventually enable us to use that mode, but right now I can not get bindata-less builds to work at all for some reason which is a requirement for that.

Codecov Report

Merging #10188 into master will increase coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #10188      +/-   ##
==========================================
+ Coverage   43.42%   43.42%   +<.01%
==========================================
  Files         576      576
  Lines       79642    79642
==========================================
+ Hits        34582    34585       +3
+ Misses      40786    40782       -4
- Partials     4274     4275       +1

Impacted Files
Coverage Δ

services/pull/pull.go
32.43% <0%> (-1.51%)
:arrow_down:

modules/queue/unique_queue_disk_channel.go
54.48% <0%> (+1.92%)
:arrow_up:

models/unit.go
39.5% <0%> (+2.46%)
:arrow_up:

modules/process/manager.go
78.31% <0%> (+3.61%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 11789ae...9b3a311. Read the comment docs.

The heatmap should probably be moved to a .vue file at some point and loaded via vue-loader but I don't have the motivation to do that as I'm not that much of a Vue fan 😉.

@lafriks any feedback? If you like, I can try porting heatmap to a .vue file but would prefer if you do it because vue is black magic to me. I think we can probably streamline the vue initialization parts to a shared vue rendering function.

Looks good, it can be converted to Vue in other pr

Rebased. This is good to go from my perspective.

The heatmap should probably be moved to a .vue file at some point and loaded via vue-loader but I don't have the motivation to do that as I'm not that much of a Vue fan wink.

Okay, I can do that part. Added to todo.

@gary-kim I'd prefer if we create a single vue rendering function to be used by all the vue components. I think the current code initializes vue in 2 or 3 different places, which seems like useless code duplication to me. Maybe create src/vue.js and export that rendering function there.

I like that idea. Make a single rendering function that imports all the Vue components and calls $mount on them.

Rebased

Any more reviews here?

Rebased once more, good to go.


The credit number is not updated.

I sent 100tnt for making credits, setup nodes normally at many times ago,
https://a.chainpoint.org/nodes/0xE7f31C38a0D47C03127714FD14e2373DEaeB061f
and its correctly sended already:
https://etherscan.io/tx/0x24e5009bd02cf0459f1943e88b44aa0126ea3b864f8dc15db47afc93fd7cd47a
But in a.chainpoint.org(b,c whatever), displayed as:
credits: "0"
minimum_credits_test: "false"
And all other list are displayed as "true".
I set up another 4 nodes, tnt sended for creating to credit, without any other problems.
I put same tnt tokens(100) to the core address through the specific node eth addresses.
Each eth address is held at more than 2500 tnt.
I have also tried node update(git pull command), but they are all the same symptoms.
I do not know what else to solve this problem..
(add more problem) Block height stuck issue    ---this issue has been solved
_After upgrading the node (using make down -> git pull -> make up
// source: https://github.com/chainpoint/chainpoint-node/wiki/Frequently-Asked-Questions)
Block height stopped at 15234. (displayed both "http://[ip4_address]/config" and "logs file")
What's wrong with this?_

This issue should be resolved in the latest version of the Node software. Please upgrade as described in the FAQ page of the Wiki in this repo.
We have temporarily disabled the need to submit TNT for credits and your account has been topped up with the maximum credits needed to operate a Node on a daily basis. Please see the update in the README for more info.

@grempe I know that you are struggling to solve problems after the software launch.
I am very impressed with the efforts of you and dev team.
Unlike other ico, there are very few tokens already launched to the main net, and I have very high expectations for TNT.
As I operate my nodes, I will keep watching the development of TNT.


feat(security): secured admin api with loopback

PR Checklist
Please check if your PR fulfills the following requirements:

[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

If your build fails due to your commit message not passing the build checks, please review the guidelines here: https://github.com/edgexfoundry/developer-scripts/blob/master/.github/Contributing.md.
What is the current behavior?
Kong admin API is exposed to everyone and can be executed w/o an authorization header.
Issue Number:
It's over in edgex-go - so this can't be merged until I create a PR there and that one gets merged.
What is the new behavior?
Kong admin API ports are no longer exposed in the add-security.yml compose file (adder), and through the use of an environment variable, a service/route combo is now setup in a loopback that will expose access to the admin API under the "/admin-api" route under the locked down requests to ports 8000/8443.
Does this PR introduce a breaking change?

[ ] Yes
[X] No

Specific Instructions
Are there any specific instructions or things that should be known prior to reviewing?
N/A
Other information

No longer needed


Bug: Follow feature in search page

Follow feature in search page redirect the user to an empty page and should be fixed.

Follow feature in search page is temporarily disabled

To be re-activated later on.

https://github.com/SWE-574-GROUP-1/SWE574-GROUP-1/commit/7ebd75408c8a499f7b723c7fed9b8d059ca74046


Port to system.commandline.dragonfruit

Description
Resolves #121
Type of change
Please delete options that are not relevant.

[X] New feature (non-breaking change which adds functionality)
[X] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[X] This change requires a documentation update

Checklist

[X] My code follows the style guidelines of this project
[X] I have performed a self-review of my own code
[X] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[X] My changes generate no new warnings

This PR is on hold until the package system.commandline.dragonfruit goes into stable release.


rather than requiring JSON object FM script params, nest the param in a data property of the param

Say you wish to send {"message": "hello"}. Currently that gets changed to {"message": "hello", "callbackID": 1}.
But maybe it should get changed to this instead:
{
  "callbackID": 1,
  "data": {"message": "hello"}
}

I changed it to that.


Undo

In the first version it is probably enough to support the same thing as in the old GameController, i.e. rolling back all actions up to a certain action. But later it should also be possible to undo only single previous actions, as long as the actions after that remain legal in the new timeline.

The is potential for future improvement, but for GORE it's enough.


code refactored: formatting and naming improved

Code Refactored: Formatting and naming conventions improved
The code from many files have been refactored, naming conventions have been improved and code has been formatted for more user readability.
Fixes # none
Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue) -> duplicate and misleading file names resolved
[x] New feature (non-breaking change which adds functionality) -> code readability improved

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generates no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules

@YashSaxena9 would you be interested in solving issue #108 along with this as these changes will be major and I don't want to do it in two step

@YashSaxena9 I request you to make a new PR as a lot of changes have been made in workflows

@kaustubhgupta I'll make a new PR, closing this one. :D


⚠ Unifi Controller has degraded performance

In f760a03, Unifi Controller (https://unifi.vflits.com/) experienced degraded performance:

HTTP code: 200
Response time: 6398 ms

Resolved: Unifi Controller performance has improved in 3c7c99a after 12 minutes.


Generate IMPL files from SCI case studies

What: We need examples of real IMPLs for things we want to measure.
Why: So we can have some real values to calculate emissions for.
SoW:

Generate a sample IMPL file for each case study listed here https://sci-guide.greensoftware.foundation/CaseStudies
Each IMPL (once all required models are also implemented) if computed should result in the same value being automatically calculated as was manually calculated in the case studies.
Deliverable is a set of yaml files in a folder called /impls in this repo, one for each of the case studies.

Average CPU utilization was used to calculate Energy values.
Server utilization = 18.3922%
Number of hours = 1
Number of cores = 2
TDP = 205W (got by doing an approximation of the server used in managed service 2nd Generation Intel® Xeon® Platinum 8272CL (Cascade Lake)= 205 W ( https://ark.intel.com/content/www/us/en/ark/products/192482/intel-xeon-platinum-8270-processor-35-75m-cache-2-70-ghz.html)
TDP Coefficient = 0.32 ( this value was derived using the energy proportionality principle and reference data is got from here https://docs.google.com/spreadsheets/d/1Viv94rMKH-fJrfD9Nn9_qkiAg1PDfIfJUAHRX9slG7A/edit#gid=526989613

FYI @jawache @gnanakeethan

Thanks @srini1978, I think after we agree (hopefully) the IMPL spec that we create an IMPL file to represent this use case and add that to the catalogue of use cases we need to code against.

We agreed on the call to make an IMPL to define this case study.
The model is a very generic model that uses the Teads data, perhaps we can make the model so the params and power curve are part of the IMPL.

The carbonQL project aims to build an automated way  for us to easily measure carbon emissions from software of all types - web based, desktop, mobile app etc. We plan to do this  by tapping into publicly available models (CCF, Boavista) as well as privately owned datasets.
The project calculate these carbon emissions values based on SCI.
We understand that many case studies were done for calculating SCI values for many types of software applications. Towards that, we would like to understand the parameters that were used for these case studies. Examples of parameters would be : CPU utilization, vCPU hours used, machine type and processor used (e.g Intel cascade lake processor, Skylake processor etc). These parameters would have been used to get the usage values of E, I and/or M.m
This is a call  to owners and developers of those case studies to share these parameters or "telemetry" as we call it in carbonQL project.

@jmcook1186 assigned this to you for the next IEF meeting can you prepare a pull request with initial IMPLs to represent each of the case studies.
I'm expecting lots of questions :) feel free to fire away or we can schedule a call to explain them once you've dug into the case studies a little.


move crd into templates to ensure it's installed with chart

currently the crd is out of the templates directory, so by default it's not installed.
kaili operator can't even work without the CRD.
maybe we could put the crd into templates directory?
Signed-off-by: lwabish<EMAIL_ADDRESS>

Incorrect. This is the completely wrong way to install CRDs using Helm. Please read the helm developer documentation when dealing with CRDs.
Before submitting PRs, please submit a github discussion or issue and ask how something can be or should be done in Kiali. It will help avoid you wasting time creating PRs that are incorrect or will not be accepted.

Thanks for the link, didn't know about helm chart crd directory.
But I did run into a situation that the chart is installed but the CRD is not installed.
I opened a discussion here and will do some more digging into this : #5398


⚠ Spryr has degraded performance

In e7aee06, Spryr (https://spryr.com) experienced degraded performance:

HTTP code: 200
Response time: 28536 ms

Resolved: Spryr performance has improved in 5b5da47 after 15 minutes.


Rename SetPreSignatureDecoder and usage to GPv2Decoder

Summary
We will need to debug more methods on the GPv2Settlement contract for #1650 and therefore create relevant decoders for. Currently, we have a SetPreSignatureDecoder which specifically interacts with this contract.
This renames it and usage of it to GPv2Decoder, which also matches the style across the project for other decoders.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

9 of 13 (69.23%)  changed or added relevant lines in 6 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 49.406%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/routes/transactions/helpers/swap-order.helper.ts
2
3
66.67%

src/routes/transactions/mappers/common/swap-order.mapper.ts
2
3
66.67%

src/routes/transactions/transactions-view.service.ts
1
3
33.33%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
3971

Relevant Lines:
6464

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

9 of 13 (69.23%)  changed or added relevant lines in 6 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.05%) to 49.451%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/routes/transactions/helpers/swap-order.helper.ts
2
3
66.67%

src/routes/transactions/mappers/common/swap-order.mapper.ts
2
3
66.67%

src/routes/transactions/transactions-view.service.ts
1
3
33.33%

Totals

Change from base Build<PHONE_NUMBER>:
0.05%

Covered Lines:
3973

Relevant Lines:
6464

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

9 of 13 (69.23%)  changed or added relevant lines in 6 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 49.274%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/routes/transactions/helpers/swap-order.helper.ts
2
3
66.67%

src/routes/transactions/mappers/common/swap-order.mapper.ts
2
3
66.67%

src/routes/transactions/transactions-view.service.ts
1
3
33.33%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
4068

Relevant Lines:
6658

💛  - Coveralls


read distribution from a file

this enables branding for kubic and caasp
feature#branding
Signed-off-by: Maximilian Meister<EMAIL_ADDRESS>still depends on the availability of the velum-branding package in the product should be in the devel image now
needs to be merged with
https://github.com/kubic-project/caasp-container-manifests/pull/183

I was wondering if a file with a single info there enough... Some places we use CaaS Platform and others
SUSE CaaS Platform. In the footer of the login page we use the ® symbol. Initially I thought about an yaml file to have more flexibility since we don't know exactly what our needs are gonna be.

I was wondering if a file with a single info there enough... Some places we use CaaS Platform and others
SUSE CaaS Platform. In the footer of the login page we use the ® symbol. Initially I thought about an yaml file to have more flexibility since we don't know exactly what our needs are gonna be.

good point, i think for now it's fine from my point of view. but this is easy to adapt once we have a different requirement
for the symbol i opened https://github.com/kubic-project/velum-branding/pull/1

There still some #{Rails.root.join("PRODUCT")} around.

thanks, it was wrong anyways, and so my sed regex didnt catch it :-( fixed now

just tested it in combination with https://github.com/kubic-project/caasp-container-manifests/pull/183 and it looks good now that we have the branding in the devel images installed by default


Trigger scalatest plugin in the integration-test phase

@ash211 @cvpatel @ssuchter
What changes were proposed in this pull request?
Currently, the kubernetes integration test runs in the maven test phase and fails because the test jobs and other jars are missing in the target dir. (See #74)  Those jars are supposed to be copied in the pre-integration-test phase, which is after the test phase.
This change fixes the issue by triggering the scalatest plugin in the integration-test phase. The target directory now has the needed jars.
How was this patch tested?
Ran the integration test build command and saw it passed the previous failing point.
$ build/mvn -B clean integration-test -Pkubernetes -Pkubernetes-integration-tests -pl resource-managers/kubernetes/integration-tests -am -Dtest=none -DwildcardSuites=org.apache.spark.deploy.kubernetes.integrationtest.KubernetesSuite

@kimoonkim I ran the build command you listed on a fresh checkout of the k8s-support-alternate-incremental branch (without this change) and didn't see any failures.
The exact command was: build/mvn clean; build/mvn -B integration-test -Pkubernetes -Pkubernetes-integration-tests -pl resource-managers/kubernetes/integration-tests -am -Dtest=none -DwildcardSuites=org.apache.spark.deploy.kubernetes.integrationtest.KubernetesSuite
and the output included
KubernetesSuite:
- Run a simple example
- Run using spark-submit
- Run using spark-submit with the examples jar on the docker image
- Run with custom labels
- Enable SSL on the driver submit server
- Added files should exist on the driver.
Run completed in 10 minutes, 48 seconds.
Total number of tests run: 6
Suites: completed 2, aborted 0
Tests: succeeded 6, failed 0, canceled 0, ignored 0, pending 0

Do you have any ideas why that might be?  Am I not cleaning intermediate testing artifacts properly?
I'd expect this command to fail before your patch and succeed afterwards but what I'm observing is that it's actually succeeding before.

@ash211 Ah, thanks for trying out the commands. (I am also going to do that myself to verify :-)).
I noticed your first $ mvn clean command did not specify -Pkubernees-integration-tests, which means it won't remove resource-managers/kubernetes/integration-tests/target dir if the dir exists already. Any chance the target dir was pre-populated? If yes, I think that would explain why it succeeds.
Can you also try doing clean and integration-test in a single command. i.e.
$ build/mvn -B clean integration-test -Pkubernetes -Pkubernetes-integration-tests -pl resource-managers/kubernetes/integration-tests -am -Dtest=none -DwildcardSuites=org.apache.spark.deploy.kubernetes.integrationtest.KubernetesSuite

FYI, I did try the single $ mvn clean integration-test command above on a fresh clone and reproduced the failure.

Reproduced the failure also with the two commands above issued on another fresh clone.
Please let me know if I should upload the full log.

I found a tool that can display maven build plan. To use the tool, one just needs to add a few lines in ~/.m2/settings:
  <pluginGroups>
    <pluginGroup>fr.jcgay.maven.plugins</pluginGroup>
  </pluginGroups>

Then, issue $ mvn buildplan:list -Pkubernetes -Pkubernetes-integration-tests, which will show build plan in the time order.
Before this change, the intergration-tests project shows the following. Notice scalatest-maven-plugin runs in the test phase, which is before maven-dependency-plugin doing copy-test-spark-jobs in the pre-integration-test phase:
[INFO] --- buildplan-maven-plugin:1.2:list (default-cli) @ spark-kubernetes-integration-tests_2.11 ---
[INFO] -----------------------------------------------------------------------------------------------------------
PLUGIN                        | PHASE                   | ID                            | GOAL
-----------------------------------------------------------------------------------------------------------
maven-enforcer-plugin         | validate                | enforce-versions              | enforce
scala-maven-plugin            | initialize              | eclipse-add-source            | add-source
maven-dependency-plugin       | generate-sources        | default-cli                   | build-classpath
maven-remote-resources-plugin | generate-resources      | default                       | process
maven-resources-plugin        | process-resources       | default-resources             | resources
scala-maven-plugin            | process-resources       | scala-compile-first           | compile
maven-compiler-plugin         | compile                 | default-compile               | compile
maven-antrun-plugin           | generate-test-resources | create-tmp-dir                | run
maven-resources-plugin        | process-test-resources  | default-testResources         | testResources
scala-maven-plugin            | process-test-resources  | scala-test-compile-first      | testCompile
maven-compiler-plugin         | test-compile            | default-testCompile           | testCompile
maven-dependency-plugin       | test-compile            | generate-test-classpath       | build-classpath
maven-surefire-plugin         | test                    | default-test                  | test
maven-surefire-plugin         | test                    | test                          | test
scalatest-maven-plugin        | test                    | test                          | test
maven-jar-plugin              | prepare-package         | prepare-test-jar              | test-jar
maven-jar-plugin              | package                 | default-jar                   | jar
maven-site-plugin             | package                 | attach-descriptor             | attach-descriptor
maven-shade-plugin            | package                 | default                       | shade
maven-source-plugin           | package                 | create-source-jar             | jar-no-fork
maven-source-plugin           | package                 | create-source-jar             | test-jar-no-fork
maven-dependency-plugin       | pre-integration-test    | copy-test-spark-jobs          | copy
maven-dependency-plugin       | pre-integration-test    | unpack-docker-driver-bundle   | unpack
maven-dependency-plugin       | pre-integration-test    | unpack-docker-executor-bundle | unpack
download-maven-plugin         | pre-integration-test    | download-minikube-linux       | wget
download-maven-plugin         | pre-integration-test    | download-minikube-darwin      | wget
scala-maven-plugin            | verify                  | attach-scaladocs              | doc-jar
scalastyle-maven-plugin       | verify                  | default                       | check
maven-checkstyle-plugin       | verify                  | default                       | check
maven-install-plugin          | install                 | default-install               | install
maven-deploy-plugin           | deploy                  | default-deploy                | deploy

Here is the build plan after this change. Notice there is one more run of scalatest-maven-plugin that triggers in the integration-test phase, which is after the copy-test-spark-jobs. With this change, that's where the KubernetesSuite will run:
[INFO] --- buildplan-maven-plugin:1.2:list (default-cli) @ spark-kubernetes-integration-tests_2.11 ---
[INFO] -----------------------------------------------------------------------------------------------------------
PLUGIN                        | PHASE                   | ID                            | GOAL
-----------------------------------------------------------------------------------------------------------
maven-enforcer-plugin         | validate                | enforce-versions              | enforce
scala-maven-plugin            | initialize              | eclipse-add-source            | add-source
maven-dependency-plugin       | generate-sources        | default-cli                   | build-classpath
maven-remote-resources-plugin | generate-resources      | default                       | process
maven-resources-plugin        | process-resources       | default-resources             | resources
scala-maven-plugin            | process-resources       | scala-compile-first           | compile
maven-compiler-plugin         | compile                 | default-compile               | compile
maven-antrun-plugin           | generate-test-resources | create-tmp-dir                | run
maven-resources-plugin        | process-test-resources  | default-testResources         | testResources
scala-maven-plugin            | process-test-resources  | scala-test-compile-first      | testCompile
maven-compiler-plugin         | test-compile            | default-testCompile           | testCompile
maven-dependency-plugin       | test-compile            | generate-test-classpath       | build-classpath
maven-surefire-plugin         | test                    | default-test                  | test
maven-surefire-plugin         | test                    | test                          | test
scalatest-maven-plugin        | test                    | test                          | test
maven-jar-plugin              | prepare-package         | prepare-test-jar              | test-jar
maven-jar-plugin              | package                 | default-jar                   | jar
maven-site-plugin             | package                 | attach-descriptor             | attach-descriptor
maven-shade-plugin            | package                 | default                       | shade
maven-source-plugin           | package                 | create-source-jar             | jar-no-fork
maven-source-plugin           | package                 | create-source-jar             | test-jar-no-fork
maven-dependency-plugin       | pre-integration-test    | copy-test-spark-jobs          | copy
maven-dependency-plugin       | pre-integration-test    | unpack-docker-driver-bundle   | unpack
maven-dependency-plugin       | pre-integration-test    | unpack-docker-executor-bundle | unpack
download-maven-plugin         | pre-integration-test    | download-minikube-linux       | wget
download-maven-plugin         | pre-integration-test    | download-minikube-darwin      | wget
scalatest-maven-plugin        | integration-test        | integration-test              | test
scala-maven-plugin            | verify                  | attach-scaladocs              | doc-jar
scalastyle-maven-plugin       | verify                  | default                       | check
maven-checkstyle-plugin       | verify                  | default                       | check
maven-install-plugin          | install                 | default-install               | install
maven-deploy-plugin           | deploy                  | default-deploy                | deploy

@kimoonkim good to know the buildplan plugin, very nice tool!

This does seem to make the tests run successfully now though being newer to Maven I'm not fully following why.
@mccheah can you please take a look?

@lins05 Thanks for taking a look. Addressed your comments in the new patch.

@ash211 @mccheah Thanks for taking a look. I am also relatively new to Maven myself and I must say Maven is quite complicated.
Let me try to explain what I think is happening before this change. Suppose we issue a command like below (which will fail):
$ build/mvn -B clean integration-test -Pkubernetes -Pkubernetes-integration-tests  \
   -pl resource-managers/kubernetes/integration-tests -am -Dtest=none  \
   -DwildcardSuites=org.apache.spark.deploy.kubernetes.integrationtest.KubernetesSuite

Maven does three high level things:

It activates the specified profiles, namely Pkubernetes Pkubernetes-integration-tests. This enables kubernetes maven modules such as resource-managers/kubernetes/core, resource-managers/kubernetes/integration-tests, resource-managers/kubernetes/integration-tests-spark-jobs, etc.
Then, maven sorts and builds these modules in the dependency order, where resource-managers/kubernetes/integration-tests-spark-jobs builds earlier than resource-managers/kubernetes/integration-tests. The latter needs a test jobs jar from the former. Note maven will build one module at a time. So integration-tests-spark-jobs will be complete before integration-tests starts. This is why the test jobs jar will be available when integration-tests starts.
For each module, maven goes through build phases in a pre-defined order.

For (3), you can find the full list on the linked page, but here are some that are relevant to us:
compile	compile the source code of the project.
test-compile	compile the test source code into the test destination directory
test	run tests using a suitable unit testing framework. These tests should not require the code be packaged or deployed.
packaging. This often results in an unpacked, processed version of the package. (Maven 2.1 and above)
package
pre-integration-test	perform actions required before integration tests are executed. This may involve things such as setting up the required environment.
integration-test	process and deploy the package if necessary into an environment where integration tests can be run.

Notice the test -> pre-integration-test -> integration-test ordering.
Now, let's see what the resource-managers/kubernetes/integration-tests module's pom.xml does. The pom.xml specifies a few plugins to download and copy a number of tarballs and jars. Here's one example. Notice it specifies the pre-integration-test phase:
     <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-dependency-plugin</artifactId>
        <executions>
          <execution>
            <id>copy-test-spark-jobs</id>
            <phase>pre-integration-test</phase>
            <goals>
              <goal>copy</goal>
            </goals>
            <configuration>
              <artifactItems>
                <artifactItem>
                  <groupId>org.apache.spark</groupId>
                  <artifactId>spark-kubernetes-integration-tests-spark-jobs_${scala.binary.version}</artifactId>
                  <version>${project.version}</version>
                  <type>jar</type>
                  <outputDirectory>${project.build.directory}/integration-tests-spark-jobs</outputDirectory>
                </artifactItem>

As shown above, those tarballs and jars will be unpacked to the project.build.directory, which will be resource-managers/kubernetes/integration-tests/target dir.
These are required inputs to KubernetsSuite. The test jobs jar is referred to by the KubernetesSuite code line 48 - 51 below:
 46 private[spark] class KubernetesSuite extends SparkFunSuite with BeforeAndAfter {
 47
 48   private val EXAMPLES_JAR = Paths.get("target", "integration-tests-spark-jobs")
 49     .toFile
 50     .listFiles()(0)
 51     .getAbsolutePath

The problem is that the scalatest plugin, which will execute KubernetsSuite, triggers only in the test phase by default. (The pom.xml of the resource-managers/kubernetes/integration-tests currently does not specify anything about scalatest plugin. The setting is inherited from the top project pom.xml.)
This plugin ordering is displayed well by the build plan plugin in a previous comment. Copying the relevant part here again:
scalatest-maven-plugin	test	test	test
...
maven-dependency-plugin	pre-integration-test	copy-test-spark-jobs	copy
maven-dependency-plugin	pre-integration-test	unpack-docker-driver-bundle	unpack
maven-dependency-plugin	pre-integration-test	unpack-docker-executor-bundle	unpack
download-maven-plugin	pre-integration-test	download-minikube-linux	wget
download-maven-plugin	pre-integration-test	download-minikube-darwin

So the above KubernetesSuite code will find the target directory missing, leading to the following exception which is raised because the line 50 above referrs to the first item in an empty list causing a NPE:
  java.lang.RuntimeException: Unable to load a Suite class that was discovered in the runpath: org.apache.spark.deploy.kubernetes.integrationtest.KubernetesSuite
  at org.scalatest.tools.DiscoverySuite$.getSuiteInstance(DiscoverySuite.scala:84)
  at org.scalatest.tools.DiscoverySuite$$anonfun$1.apply(DiscoverySuite.scala:38)
  at org.scalatest.tools.DiscoverySuite$$anonfun$1.apply(DiscoverySuite.scala:37)
  at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:234)
  at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:234)
  at scala.collection.Iterator$class.foreach(Iterator.scala:893)
  at scala.collection.AbstractIterator.foreach(Iterator.scala:1336)
  at scala.collection.IterableLike$class.foreach(IterableLike.scala:72)
  at scala.collection.AbstractIterable.foreach(Iterable.scala:54)
  at scala.collection.TraversableLike$class.map(TraversableLike.scala:234)
  ...
  Cause: java.lang.NullPointerException:
  at org.apache.spark.deploy.kubernetes.integrationtest.KubernetesSuite.<init>(KubernetesSuite.scala:50)
  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
  at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
  at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
  at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
  at java.lang.Class.newInstance(Class.java:442)
  at org.scalatest.tools.DiscoverySuite$.getSuiteInstance(DiscoverySuite.scala:69)
  at org.scalatest.tools.DiscoverySuite$$anonfun$1.apply(DiscoverySuite.scala:38)
  at org.scalatest.tools.DiscoverySuite$$anonfun$1.apply(DiscoverySuite.scala:37)
  at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:234)
  ...

Now, some of us did not encounter this exception before. How is this possible? Here's one sequence of commands that will hide this problem (I have tried this sequence on my local checkout and it does hide the problem).

Issue a maven build command targeting pre-integration-test while specifying -DskipTests. This will allow the test jobs jar to be copied in place while skipping KubernetseSuite.
$ build/mvn clean pre-integration-test -DskipTests -Pkubernetes -Pkubernetes-integration-tests -pl resource-managers/kubernetes/integration-tests -am
Then, issue another maven command specifying the integration-test target, but without the clean goal specified. This time, maven will run KubernetseSuite (again in the test phase), but the exception won't happen because the test job jar was pre-populated the command above.
$ build/mvn -B integration-test -Pkubernetes -Pkubernetes-integration-tests -pl resource-managers/kubernetes/integration-tests -am -Dtest=none -DwildcardSuites=org.apache.spark.deploy.kubernetes.integrationtest.KubernetesSuite

One more related command that can add to the confusion is doing mvn clean  in between (1) and (2), without specifying the two kubernetes profiles. i.e. $ build/mvn clean. This will disable kubernete maven modules and thus won't wipe out the target dirs like resource-managers/kubernetes/integration-tests/target. So doing (2) after this way of cleaning will still hide the problem.

+1 this makes sense - the Maven pom was originally created under the assumption that the build process would execute both the test phase and the integration-test phase, but it looks like they just invoke the Scalatest plugin and that doesn't trigger integration-test by default. Should we not just change our tests to target the test phase and not the integration-test phase? Thus instead of putting the build preparation steps in the pre-integration-test phase, is there some equivalent like a pre-test phase?

@mccheah Yes, targeting the test phase is one possible solution. There are phases like generate-test-resources or process-test-resources that run before the test phase. So we could use them.
From the same maven phase list web page above:
generate-test-resources	create resources for testing.
process-test-resources	copy and process the resources into the test destination directory.
test-compile	compile the test source code into the test destination directory
process-test-classes	post-process the generated files from test compilation, for example to do bytecode enhancement on Java classes. For Maven 2.0.5 and above.
test	run tests using a suitable unit testing framework. These tests should not require the code be packaged or deployed.
...
package	take the compiled code and package it in its distributable format, such as a JAR.
pre-integration-test	perform actions required before integration tests are executed. This may involve things such as setting up the required environment.
integration-test

The downside is that there is a subtle usage issue with this approach. If a user issues a maven command with the test target, then the other modules like resource-managers/kubernetes/integration-tests-spark-jobs might not produce the jars that resource-managers/kubernetes/integration-tests needs. Imagine the following command:
$ build/mvn -B clean test -Pkubernetes -Pkubernetes-integration-tests  \
   -pl resource-managers/kubernetes/integration-tests -am -Dtest=none  \
   -DwildcardSuites=org.apache.spark.deploy.kubernetes.integrationtest.KubernetesSuite

With this command, the resource-managers/kubernetes/integration-tests-spark-jobs module only runs until the test phase. The test jobs jar is produced at the package phase that comes after the test phase.
So when the resource-managers/kubernetes/integration-tests module starts, the test jobs jar will be missing. The copy-test-spark-jobs (now say at the process-test-resources phase) will fail as the result.
The failure can be avoided if one issues a maven command specifying the package or any subsequent target like below. But this is a bit counter-intuitive. People may try the above command first and do unnecessary trouble-shooting before they reach here:
$ build/mvn -B clean package -Pkubernetes -Pkubernetes-integration-tests  \
   -pl resource-managers/kubernetes/integration-tests -am -Dtest=none  \
   -DwildcardSuites=org.apache.spark.deploy.kubernetes.integrationtest.KubernetesSuite

Please let me know what you guys think.

I thought copy-test-spark-jobs depends on the artifact from the integration-tests-spark-jobs module in a way such that it requires the equivalent phase of integration-tests-spark-jobs to be executed first?
Alternatively, we can try to take a compile-time dependency on integration-tests-spark-jobs and depend on that jar in a way that doesn't require a separate copy. For example, is it the case that in a multi-module build, if module B depends on module A, then does a.jar exist somewhere in module B's subtree in a location that we could easily reference from the integration test code? Maybe under target/?

@mccheah How exactly maven reactor handles multi-module dependencies is a bit mysterious to me. I found this blog saying below:

As part of all the refactoring in Maven 3, a dependency resolution has been reworked to consistently check the reactor output. Apparently, the reactor output depends on the lifecycle phases that a project has completed. So if you invoke mvn compile or mvn test on a multi-module project, the loose class files from target/classes and target/test-classes, respectively, are used to create the required class path. As soon as the actual artifact has been assembled which usually happens during the package phase, dependency resolution will use this file.

I think we still need to do mvn package to use the jar. Can integration-tests-spark-jobs directly use the target/classes? Probably not, given spark-submit needs the jar?

Right - the test expects to ship the jar over as the application dependency of the tests.

I also wanted to propose moving the copy-test-spark-jobs action to some phase like generate-test-resources that happens before the test, which could effectively solve the problem this PR tries to address, but just found it seems pretty hard to get the spark-integration-test-jobs jar without running the package phase.
What if in the spark-integration-test-jobs's pom, we try to attach the jar:jar goal to the generate-test-resources phase?

@lins05 Creating jars at the generate-test-resources phase sounds promising. The only concern is whether the maven reactor component will recognize the jars from non-package phases. I think we can try and see. Also note this approach will lead to a slightly large change since we are going to touch other modules. @mccheah what do you think of this suggestion? If yes, I can write a new sister PR so we can compare with this PR.
Also, what do we think the upside of using the test phase? I like the overall build time can be shorter. Anything else? I am just curious.

Also note this approach will lead to a slightly large change since we are going to touch other modules

Emm, what other modules? IIUC the affected modules would only be the integration-tests, integration-tests-spark-jobs, and integration-tests-spark-jobs-helpers/ modules.

They are what I meant. Add docker-minimal-bundle there too?

I see, then that's ok.

docker-minimal-bundle there too?

Right.

I think docker-minimal-bundle may be a show-stopper. The tarballs from the module has jars from all other spark modules (and their dependencies). These spark module jars need mvn package.
$ tar tvfz docker-minimal-bundle/target/spark-docker-minimal-bundle_2.11-2.2.0-SNAPSHOT-driver-docker-dist.tar.gz | grep spark-.*.jar | head
-rw-r--r-- kimoonkim/staff 12015040 2017-02-13 09:30 jars/spark-core_2.11-2.2.0-SNAPSHOT.jar
-rw-r--r-- kimoonkim/staff    66585 2017-02-13 09:27 jars/spark-launcher_2.11-2.2.0-SNAPSHOT.jar
-rw-r--r-- kimoonkim/staff    15490 2017-02-13 09:26 jars/spark-tags_2.11-2.2.0-SNAPSHOT.jar
-rw-r--r-- kimoonkim/staff  2367947 2017-02-13 09:26 jars/spark-network-common_2.11-2.2.0-SNAPSHOT.jar
-rw-r--r-- kimoonkim/staff    61878 2017-02-13 09:26 jars/spark-network-shuffle_2.11-2.2.0-SNAPSHOT.jar
-rw-r--r-- kimoonkim/staff    44552 2017-02-13 09:26 jars/spark-unsafe_2.11-2.2.0-SNAPSHOT.jar
-rw-r--r-- kimoonkim/staff  6195220 2017-02-13 09:39 jars/spark-mllib_2.11-2.2.0-SNAPSHOT.jar
-rw-r--r-- kimoonkim/staff  2175666 2017-02-13 09:31 jars/spark-streaming_2.11-2.2.0-SNAPSHOT.jar
-rw-r--r-- kimoonkim/staff  6847170 2017-02-13 09:37 jars/spark-sql_2.11-2.2.0-SNAPSHOT.jar
-rw-r--r-- kimoonkim/staff    30029 2017-02-13 09:26 jars/spark-sketch_2.11-2.2.0-SNAPSHOT.jar
$ tar tvfz docker-minimal-bundle/target/spark-docker-minimal-bundle_2.11-2.2.0-SNAPSHOT-driver-docker-dist.tar.gz | grep .jar | wc -l
163

@lins05 Looked at docker-minimal-bundle. It is using maven-assembly-plugin to put all spark jars in the tarballs. The driver-assembly.xml, puts all the jars it depends on except a few:
<dependencySets>
    <dependencySet>
      <outputDirectory>jars</outputDirectory>
      <useTransitiveDependencies>true</useTransitiveDependencies>
      <unpack>false</unpack>
      <scope>runtime</scope>
      <useProjectArtifact>false</useProjectArtifact>
      <excludes>
        <exclude>org.apache.spark:spark-assembly_${scala.binary.version}:pom</exclude>
        <exclude>org.spark-project.spark:unused</exclude>
        <exclude>org.apache.spark:spark-examples_${scala.binary.version}</exclude>
      </excludes>
    </dependencySet>

And the pom.xml specifies spark-assembly as its main dependency, from which all other spark module jars are pulled from.
   <dependency>
      <groupId>org.apache.spark</groupId>
      <artifactId>spark-assembly_${scala.binary.version}</artifactId>
      <version>${project.version}</version>
      <type>pom</type>
    </dependency>

I can't imagine we build all these jars in non-package phase. That's just too many pom.xml's to touch.
If we only make docker-minimal-bundle run maven-assembly-plugin in the generate-test-resources phase, I think it'll try to put target/classes of all other spark modules into the tarball. I don't know if that will even succeed, but even if it does, it doesn't sound like what we want to have inside a docker image for testing.
I am afraid this does look like a show-stopper. Thoughts?

Hm, yeah I suppose our findings are showing that the integration-test phase is the right one to use, and resource preparation should be in pre-integration-test, and Scalatest should just invoke our integration-test phase.

@mccheah SGTM. Then this PR is ready for merge?

@lins05 @mccheah Thanks for discussions so far. Do we have any more questions or feedbacks?
Given our findings so far, I believe this PR is useful as is. FYI, the patch is updated earlier to address @lins05's comments. Can you guys please give one more look?

@kimoonkim an enormous thank you for all your work on this PR!  Clearly you've put a lot of effort and research into getting this right.
I can't say I'm familiar enough with Maven to say this is right, but I think whether it's perfect or not it's certainly a step in the right direction.  Let's merge and move closer to running integration tests in Travis (one of the goals coming out of this week's weekly meeting).
Thanks again for the well-researched contribution!

@ash211 I am not a big fan of Maven either, but it was a great learning experience for me :-) Thank you, @mccheah and @lins05 for asking right questions and having discussions together.


Instruction on how to use this in browser

This my be considered an issue from perspective of someone who is not nodejs ninja and don't have intentions on using this polyfill in non-browser environment .
What should one do to have browser code built from this?
From what I can see&understand this is for node use.
I have cloned this version locally, and run npm install - which gave me performance-now.
But still I don't get this.
I do care specifically about this polyfill since it is only one I could find that implements callback queueing - fantastic job.

Run it through browserify. http://wzrd.in may help you transition to a build process.

@ljharb Thanks for the response.
But I can confirm that:
<EMAIL_ADDRESS>https://wzrd.in/standalone/raf@latest
does not produce code that polyfills requestAnimationFrame.

@milosdjakonovic indeed, the module doesn't polyfill by default. What you want is require('raf/polyfill'), and to have that go through your browserify/webpack build process.

When loading the library via a <script> tag API is available on window.raf. To automatically polyfill window.requestAnimationFrame and window.cancelAnimationFrame you can invoke window.raf.polyfill(). This is documented here.

@ljharb @CMTegner
Worked, thanks.

I added these instructions to the README. Thanks for bringing this up @milosdjakonovic!


502 error on Migrate

Hello Geta Team,
We have latest version of BVN and Geta nuget packages.
Geta.404Handler.1.2.1
BVN.404Handler.11.4.0
It work fine on local dev and our development server. But fails to run on Test and UAT.
We get the following error when we try to run migrate in Admin tool.
Only difference that we see on both environments are Test and UAT are on load balancing environment.
Please see the screen shot of the error we get.

Please suggest!
Thank you in advance!
Regards,
Ranjit

Please check your logs on the server to see what exactly failed.

Please check your logs on the server to see what exactly failed.

@marisks we do not see anything in episerver log file in regard to this error. Also now we experiencing tool not loading in dashboard.
Please see the screen shot:

This is from test server.
Kindly advise.
Thank you!
Ranjit

@marisks we do not see anything in episerver log file in regard to this error. Also now we experiencing tool not loading in dashboard.
Please see the screen shot:

This is from test server.
Kindly advise.
Thank you!
Ranjit

According to the exception, you have an old version of 404 handler. Please verify that you have deployed the right version.

According to the exception, you have an old version of 404 handler. Please verify that you have deployed the right version.

Hi @marisks
We verified the deployed versions and latest version are in place. Now we are getting  server error 502 as previous screen shot.
also verified the logs but nothing found in regard to this exception. I understand we are using epi ILogger in the tool but still nothing in the log.
Please suggest!
Thanks,
Ranjit

Hi @marisks
We verified the deployed versions and latest version are in place. Now we are getting  server error 502 as previous screen shot.
also verified the logs but nothing found in regard to this exception. I understand we are using epi ILogger in the tool but still nothing in the log.
Please suggest!
Thanks,
Ranjit

Sorry, but without more details, I am not able to help. You could try configuring Episerver log to include exceptions from 404 handler.
Another option - use an older version of your application and the production DB to export redirects and then import in the new version.

Sorry, but without more details, I am not able to help. You could try configuring Episerver log to include exceptions from 404 handler.
Another option - use an older version of your application and the production DB to export redirects and then import in the new version.

As per your suggestion, I tried adding appender to EPiServerLog.config. log4net created a file but did add logs to it.
I have checked sourecode, you do not use any logger name while instantiating ILogger instance.
Is something I am missing?
Thanks,
Ranjit

As per your suggestion, I tried adding appender to EPiServerLog.config. log4net created a file but did add logs to it.
I have checked sourecode, you do not use any logger name while instantiating ILogger instance.
Is something I am missing?
Thanks,
Ranjit

Hi @marisks
We have noticed logging has already been working for 404 handler, as we have seen an entry when we added a new redirect. So ideally in case of exception that should also be logged-in if I am not wrong. Also to mentioned we have set log level debug.
Thanks,
Ranjit

Hi @marisks
We have noticed logging has already been working for 404 handler, as we have seen an entry when we added a new redirect. So ideally in case of exception that should also be logged-in if I am not wrong. Also to mentioned we have set log level debug.
Thanks,
Ranjit

Hello @marisks
As per your suggestion, we replaced the database that did not run the migration before and added following entry to EPiServerlog.config:
<logger name="BVNetwork.NotFound"
            additivity="false">
    <level value="All" />
    <appender-ref ref="debugLogAppender"/>
</logger>

After we ran the migration. We are still getting this error screen shot:

Also there are not entries in the EPiServerErrors.log
Please see, if you can point us to resolve this.
Thank you!
Regards,
Ranjit

Hello @marisks
As per your suggestion, we replaced the database that did not run the migration before and added following entry to EPiServerlog.config:
<logger name="BVNetwork.NotFound"
            additivity="false">
    <level value="All" />
    <appender-ref ref="debugLogAppender"/>
</logger>

After we ran the migration. We are still getting this error screen shot:

Also there are not entries in the EPiServerErrors.log
Please see, if you can point us to resolve this.
Thank you!
Regards,
Ranjit

Hi @marisks
After lot of investigation, we came to a point were thinking about some incorrect round saved in the db might be failing the tool to load the list.
We attempt to truncate the table "BVN.NotFoundRequests" and tool started working. We also looked at the source code in brief but just wanted to be 100% sure about the impact before we do this on main servers.
Please advise!
Thanks,
Ranjit

Hi @marisks
After lot of investigation, we came to a point were thinking about some incorrect round saved in the db might be failing the tool to load the list.
We attempt to truncate the table "BVN.NotFoundRequests" and tool started working. We also looked at the source code in brief but just wanted to be 100% sure about the impact before we do this on main servers.
Please advise!
Thanks,
Ranjit

The data in that table is historic 404 requests, which are used to display the top not found urls. For a system that has lived for a long time, it might get big. How many rows do you have in that table?
You can safely delete the content, but it you'll lose the suggestions for new 404 redirects. Old log entries have less value, so you might want to delete entries from the table that are older than a few months for an example.

The data in that table is historic 404 requests, which are used to display the top not found urls. For a system that has lived for a long time, it might get big. How many rows do you have in that table?
You can safely delete the content, but it you'll lose the suggestions for new 404 redirects. Old log entries have less value, so you might want to delete entries from the table that are older than a few months for an example.

Hi @evest
We have almost: 805623 rows in this table.
As I understand we can safely delete entries that are older and 6 months, right?
Thanks,
Ranjit

Hi @evest
We have almost: 805623 rows in this table.
As I understand we can safely delete entries that are older and 6 months, right?
Thanks,
Ranjit

That is correct, you can safely delete old entries from that table.
For context, if you're moving things around, or migrate from some other system to Episerver, you'll see an uptick in the logging to this table, as old non-working urls are being logged as 404s. These are important to add redirects for to ensure your SEO rating isn't impacted too much (some is to be expected if you move to another system).
After some time, you'll see less new entries in this log, and mostly junk as Bots keep requesting old ones and automatic checks for Wordpress login and admin pages.
In fact; from time to time; you could clear the the table completely, as junk entries tend to rise to the top over time if you're not marking them as ignored. This will ensure that new fresh 404s that you care about is handled correctly.

That is correct, you can safely delete old entries from that table.
For context, if you're moving things around, or migrate from some other system to Episerver, you'll see an uptick in the logging to this table, as old non-working urls are being logged as 404s. These are important to add redirects for to ensure your SEO rating isn't impacted too much (some is to be expected if you move to another system).
After some time, you'll see less new entries in this log, and mostly junk as Bots keep requesting old ones and automatic checks for Wordpress login and admin pages.
In fact; from time to time; you could clear the the table completely, as junk entries tend to rise to the top over time if you're not marking them as ignored. This will ensure that new fresh 404s that you care about is handled correctly.

Hello @evest, @marisks,
We have performed the truncate table activity on servers on 'BVN.NotFoundRequests' table and later tool worked fine. We were getting 502 error as mentioned in the screenshot due to heavy data in this table for around 12+ million records.
Possibly, If you could let us know what would you suggest for below question..

What is it we can do to handle this and stop breaking the tool in near future. Is truncate only the option?
If we have a old and new urls in the tool already for sometime. By when we can be sure that this particular entries will not be used anymore and are good for clean-up?

Kindly suggest!
Thank you for all your help on this. :)
Regards,
Ranjit

Hello @evest, @marisks,
We have performed the truncate table activity on servers on 'BVN.NotFoundRequests' table and later tool worked fine. We were getting 502 error as mentioned in the screenshot due to heavy data in this table for around 12+ million records.
Possibly, If you could let us know what would you suggest for below question..

What is it we can do to handle this and stop breaking the tool in near future. Is truncate only the option?
If we have a old and new urls in the tool already for sometime. By when we can be sure that this particular entries will not be used anymore and are good for clean-up?

Kindly suggest!
Thank you for all your help on this. :)
Regards,
Ranjit


Fix #2880: Use our own definition of Sys_error.

In https://github.com/scala/scala/pull/5830, the definition of Sys_error was removed from Definitions.scala. This commit reintroduces it in our own codebase, as a quickfix to #2880.
This will need to be revisited as part of #2876 not use sys.error at all, but that is less urgent.

I locally verified that this passes:
> set resolvers in Global += "scala-integration" at "https://scala-ci.typesafe.com/artifactory/scala-integration/"
> ++2.13.0-pre-87c8eb7
> testSuite/test

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/3863/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/5103/
Test FAILed.

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/3864/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/5104/
Test PASSed.


Fixed incompatible pointer warnings

Fixed a couple of warnings where pointer to unsigned int is used but pointer to size_t is expected.

Thanks for the PR @bjornwah! Sorry but I'm not merging this change, I tried to avoid using size_t in all raylib... In any case, glad to see you managed to send it perfectly!

@raysan5 tinyobj_parse_obj doesn't care though. It will write a size_t anyway regardless of the pointer you pass in and if size_t is bigger than unsigned int, like on x86_64, it will corrupt the stack.
This needs to be fixed, either by patching tinyobj_parse_obj to use unsigned int, or by using the standard size_t type where appropriate.

Following tinyobj_loader comment:
@todo { Remove stddef dependency. size_t? }

Replaced size_t by unsigned int in commit https://github.com/raysan5/raylib/commit/802afe8fe533bc66a6ebd2810090b08d1f635991.


/var/lib/cilium/bpf/init.sh failing and making pods not scheduling

Bug report

General Information

Cilium version (run cilium version) 1.5.3
Kernel version (run uname -a) 4.12.14-197.18.1
Orchestration system version in use (e.g. kubectl version, Mesos, ...) Kubernetes 1.15.2

It might be specific to SUSE CaaSP...
How to reproduce the issue

Deploy Kubernetes cluster by https://github.com/SUSE/skuba
There is a chance that some pod trying to contact Cilium through UNIX socket will fail.

Failures were observed during cilium-operator pod creation:
Warning  FailedCreatePodSandBox  62s                 kubelet, kiubit-4-dev-worker-1  Failed create pod sandbox: rpc error: code = Unknown desc = failed to create pod network sandbox k8s_cilium-operator-7d6ddddbf5-4bq6b_kube-system_e99f61c8-ffd4-43e5-952f-d4528da1b7ba_0(b2e63c859ca9bf7c3e93f740ecad8e1a1cc4382e910980b52593666163543783): unable to connect to Cilium daemon: failed to create cilium agent client after 30.000000 seconds timeout: Get http://%!F(MISSING)var%!F(MISSING)run%!F(MISSING)cilium%!F(MISSING)cilium.sock/v1/config: dial unix /var/run/cilium/cilium.sock: connect: no such file or directory

On the same environment, there was the following error of cilium-agent:
level=error msg="Command execution failed" cmd="[/var/lib/cilium/bpf/init.sh /var/lib/cilium/bpf /var/run/cilium/state <IP_ADDRESS> fc00::10ca:1 vxlan    1450 false false ]" error="exit status 2" subsys=daemon

But on the other environment, it was observed during kured pod creation, with the same error:
  Warning  FailedCreatePodSandBox  19m                 kubelet, master03  Failed create pod sandbox: rpc error: code = Unknown desc = failed to create pod network sandbox k8s_kured-9zwk6_kube-system_7646f3d8-3b7c-4106-a3d6-e3ba0cd965f4_0(a21b39295d3c5fc8a16d244d2bc548d75b2356092984cf97c2b2756005e3167c): Unable to create endpoint: Put http:///var/run/cilium/cilium.sock/v1/endpoint/cilium-local:0: context deadline exceeded

Are there any cilium-agent logs? bpf/init.sh has set -x, so there should be exact cmd, which failed, in the logs.
Also, v1.5.3 is quite ancient (v1.5.8 is the latest release from v1.5).

I can't reproduce anymore on newer versions, closing.


Memory leak related to camera processing

Memory leak crash on Galaxy S4.
This may have been related to a really bad network configuration, but still should not crash like this.
Worth noting that this was about 1 minute into connection.
v0.4 has had about 3 to 4 hours on a Samsung Galaxy S4 and 3 to 4 hours on a Motorola Moto Z, and did not crash then when the network was fast
Solution could either be to fix it, or if the solution cannot be found, auto restart the robot activity and run any time it crashes.
11-14 20:01:59.682 6087-14655/? E/AndroidRuntime: FATAL EXCEPTION: pool-1-thread-2
    Process: com.runmyrobot.android_robot_for_phone, PID: 6087
    java.lang.RuntimeException: An error occured while executing doInBackground()
        at android.os.AsyncTask$3.done(AsyncTask.java:300)
        at java.util.concurrent.FutureTask.finishCompletion(FutureTask.java:355)
        at java.util.concurrent.FutureTask.setException(FutureTask.java:222)
        at java.util.concurrent.FutureTask.run(FutureTask.java:242)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
        at java.lang.Thread.run(Thread.java:818)
     Caused by: java.lang.OutOfMemoryError: Failed to allocate a 16476 byte allocation with 9316 free bytes and 9KB until OOM
        at java.lang.AbstractStringBuilder.enlargeBuffer(AbstractStringBuilder.java:95)
        at java.lang.AbstractStringBuilder.append0(AbstractStringBuilder.java:146)
        at java.lang.StringBuilder.append(StringBuilder.java:216)
        at com.github.hiteshsondhi88.libffmpeg.FFmpegExecuteAsyncTask.checkAndUpdateProcess(FFmpegExecuteAsyncTask.java:110)
        at com.github.hiteshsondhi88.libffmpeg.FFmpegExecuteAsyncTask.doInBackground(FFmpegExecuteAsyncTask.java:46)
        at com.github.hiteshsondhi88.libffmpeg.FFmpegExecuteAsyncTask.doInBackground(FFmpegExecuteAsyncTask.java:10)
        at android.os.AsyncTask$2.call(AsyncTask.java:288)
        at java.util.concurrent.FutureTask.run(FutureTask.java:237)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
        at java.lang.Thread.run(Thread.java:818)

Starting to investigate

Moto Z Profiling data

332bcd5 only fixes leaking issues with camera2. The main leak still exists

How this happened:
Frames are sent to an android handler. If the phone cannot process data fast enough or the network is too slow for given bitrate, objects will start to pool up. each time a frame is processed, the pool is eliminated, but if it goes too long without sending a frame, it builds up to the point where the app crashes.
This now will not queue data to the handler unless the handler has no data at all

Moto Z profiling. 1920x1080 at 10Mbps, which was really laggy. Saw no bad memory spikes


Added minor improvements for Plugin initialization.

When _setAddPluginModal is called it was previously creating Modal
instances that weren't likely to be used until later, so now we
instantiate them on demand. This saves about 1-2 ms per plugin,
which doesn't seem like much, but makes a big difference on a page
with 450 plugins, there initialization went down by ~400ms.
Also caching some jQuery variables, and getting rid of unnecessary
loops helps to improve the speed as well.

LGTM

Coverage increased (+0.6%) to 89.508% when pulling 3bd13836ff3bf97aa093d3c9db20b1b6a681f51f on vxsx:feature/minor-plugin-initialisation-speedup into 407a63dbce1222dc1203ce771607337e7d23d83d on divio:release/3.3.x.