{"push_id":1417720971,"size":28,"distinct_size":0,"ref":"refs/heads/master","head":"d5afe7c8c486a899caee4139886bd422e81dcc8d","before":"884c51c15330db89c388583ae4e7f17af3aa7aaa","commits":[{"sha":"17d7611209596b8915f15af57e976cc552b5be57","author":{"name":"Moses Nakamura","email":"027e942e2a8d9c3b29816dfa40893330d419351a@twitter.com"},"message":"source: Upgrade jackson to 2.8.3\n\nProblem\n\nWe're beginning to start thinking about 2.12.x, now that 2.12.0-RC1 is a thing.\njackson-module-scala has been published for 2.12.0-RC1, but not in the version\nthat we're on today.\n\nSolution\n\nLet's move source to 2.8.3!\n\nResult\n\nWe can pull in an ostrich PR that starts cross-publishing for scala 2.12.0-RC1.\n\nRB_ID=878518","distinct":false,"url":"https://api.github.com/repos/twitter/util/commits/17d7611209596b8915f15af57e976cc552b5be57"},{"sha":"23242ea4d3a3c76773726126418a69685e44cabd","author":{"name":"Moses Nakamura","email":"027e942e2a8d9c3b29816dfa40893330d419351a@twitter.com"},"message":"util-logging: Clean up global state in logging tests\n\nProblem\n\nAppTest was failing when run in combination with other tests\n\nSolution\n\nClean up the global state\n\nResult\n\nRunning all of the logging tests at once is nice\n\nRB_ID=880272","distinct":false,"url":"https://api.github.com/repos/twitter/util/commits/23242ea4d3a3c76773726126418a69685e44cabd"},{"sha":"bdc7809beb76e7d9e78e1f1df29daaae8fef2326","author":{"name":"Vivek Malik","email":"671fa1b2e04cea6d3ea2f24a72e9e497a528d0b5@lookout.com"},"message":"util-logging: Pick up log file size\n\nProblem\n\nFileHandler sets 'bytesWrittenToFile' as 0 in 'openLog()'.\nThis forces log file size to 0 every-time application is restarted, even\nif it exists.\n\nSolution\n\nSet 'bytesWrittenToFile' as file size in openStream(), if log file\nexists.\nElse set it to 0. Remove 'bytesWrittenToFile' from 'openLog()'\n\nResult\n\nAs a result of this merge, the FileHandler will rotate log files with\nlog policy based on Max file size when the limit is reached and prevent\nthe files from growing too large.\n\nISSUE: #176\n\nSigned-off-by: Moses Nakamura <mnakamura@twitter.com>\n\nRB_ID=880537","distinct":false,"url":"https://api.github.com/repos/twitter/util/commits/bdc7809beb76e7d9e78e1f1df29daaae8fef2326"},{"sha":"740542e9526e06571947b7a6ea57428fed2de7fc","author":{"name":"Fabian Gruber","email":"ad1eaa432ff54f9db3e732649e37ad6cb0fd851f@eslgaming.com"},"message":"util-logging: Make asyncFlag and asyncMaxSizeFlag protected fields so they can accessed by a trait thats mixed in.\n\nProblem\n\nWith the fields being marked as private it was not possible to properly\noverride the \"handlers\" method as you could not initialize the QueuingHandler.\nhttps://github.com/twitter/twitter-server/issues/46\n\nSolution\n\nSet the flags to protected like the other flags.\n\nSigned-off-by: Moses Nakamura <mnakamura@twitter.com>\n\nRB_ID=880535","distinct":false,"url":"https://api.github.com/repos/twitter/util/commits/740542e9526e06571947b7a6ea57428fed2de7fc"},{"sha":"1fa401a6fb121c4e470d73340063850b785d3bbf","author":{"name":"ity","email":"be1e173eca3d3e2b7f13102a49f4d8c963af5c21@twitter.com"},"message":"known-to-fail: Test target disabled: util/util-logging/src/test/scala:scala\n\nProblem:\n\nThe test target \"util/util-logging/src/test/scala:scala\" is failing too often in master in CI.\n\nLogs available here: https://ton.smf1.twitter.com/ci/build_logs/source_ci/2016-10-13_05-38-56.html\n\nKnown to fail ticket: [CSL-3418](https://jira.twitter.biz/browse/CSL-3418)\n\nSolution:\n\nIt has been marked \"known_to_fail\" in the BUILD file\n\nResult:\n\nThis will cause it to be skipped in future builds, and its failures ignored in submit queue. This implies that code changes that further break this test will not be prevented from being submitted to the master branch, until the problem is fixed and the test is no longer marked known-to-fail.\n\nRB_ID=880843\nTBR=true","distinct":false,"url":"https://api.github.com/repos/twitter/util/commits/1fa401a6fb121c4e470d73340063850b785d3bbf"},{"sha":"fc2148069797d1519078d8f7af8a1bc538dfaf44","author":{"name":"Kevin Oliver","email":"42f0c465f9d28c5edb4e65e73bb0815be7cdcaf5@twitter.com"},"message":"util,finagle-core: Improve toStrings\n\nProblem / Solution\n\nThere are a variety of commonly used classes and defaults that end up\nin the runtime registry which do not have a good `toString`\nimplementation.\n\nRB_ID=880664","distinct":false,"url":"https://api.github.com/repos/twitter/util/commits/fc2148069797d1519078d8f7af8a1bc538dfaf44"},{"sha":"3bbf6c936b04fe8b8f930137cf929c38b6618aa5","author":{"name":"Moses Nakamura","email":"027e942e2a8d9c3b29816dfa40893330d419351a@twitter.com"},"message":"util-logging: Ensure ScribeHandler initialization is deterministic\n\nProblem\n\nThe ScribeHandler object was sometimes initialized before, and sometimes\ninitialized during AppTest, which meant that the Loggers that Logger had cached\ncould sometimes be different.\n\nSolution\n\nEnsure that the ScribeHandler object is initialized before AppTest.\n\nResult\n\nAppTest is no longer flaky.\n\nRB_ID=881172","distinct":false,"url":"https://api.github.com/repos/twitter/util/commits/3bbf6c936b04fe8b8f930137cf929c38b6618aa5"},{"sha":"871ea3b0c890d7891ef368913fc33993032288ce","author":{"name":"Kevin Oliver","email":"42f0c465f9d28c5edb4e65e73bb0815be7cdcaf5@twitter.com"},"message":"util-core: Remove an allocation from Future.lowerFromTry\n\nProblem / Solution\n\n`c.t.util.Future.lowerFromTry` uses a private constant function to do\nits work. This function uses `Future.value`. This patch removes the\nunnecessary unboxing and creation of the `Try` by using\n`Future.const`.\n\nAlso, snuck in an improvement to `Future.join` to avoid an unecessary\n`Throw` creation.\n\nRB_ID=884273","distinct":false,"url":"https://api.github.com/repos/twitter/util/commits/871ea3b0c890d7891ef368913fc33993032288ce"},{"sha":"177dab9399bb05ac16345d152212b826f6604bc1","author":{"name":"Kevin Oliver","email":"42f0c465f9d28c5edb4e65e73bb0815be7cdcaf5@twitter.com"},"message":"util-core: Document why ConstFuture uses the Scheduler\n\nProblem\n\nIt is not obvious when reading the code for `c.t.util.ConstFuture` why\nit uses the `Scheduler`.\n\nSolution\n\nExplain the rationale for this.\n\nRB_ID=885066","distinct":false,"url":"https://api.github.com/repos/twitter/util/commits/177dab9399bb05ac16345d152212b826f6604bc1"},{"sha":"f065df0f5944ba8e8f3375bf7f7ca0ddfb4320f5","author":{"name":"Kevin Oliver","email":"42f0c465f9d28c5edb4e65e73bb0815be7cdcaf5@twitter.com"},"message":"Bump version of Caffeine to 2.3.3\n\nProblem\n\nThe caffeine library we are using is not the latest.\n\nSolution\n\nUpgrade to 2.3.3 from 2.3.0.\n\nRB_ID=885896","distinct":false,"url":"https://api.github.com/repos/twitter/util/commits/f065df0f5944ba8e8f3375bf7f7ca0ddfb4320f5"},{"sha":"da989506abb9c42aceeac0d56d225b8bf5d6c7ea","author":{"name":"Daniel Schobel","email":"67662df2ffee7debcd16f68b05f1a09e938277a6@gmail.com"},"message":"3rdparty / csl: bump jmh to latest\n\nProblem\n\nOur version of jmh is ~15 months out of date.\n\nSolution\n\nBump 3rdparty dep to 1.15 and sbt-plugin to 0.2.16 (jmh 1.14.1)\n\nRB_ID=886570","distinct":false,"url":"https://api.github.com/repos/twitter/util/commits/da989506abb9c42aceeac0d56d225b8bf5d6c7ea"},{"sha":"12dc4d3b5c363a6bfb0a6662c056a4e0c039d3a5","author":{"name":"Kevin Oliver","email":"42f0c465f9d28c5edb4e65e73bb0815be7cdcaf5@twitter.com"},"message":"util-core: Fix flaky ReaderTest\n\nProblem\n\nThe \"ReaderTest.Reader.fromStream closes resources on EOF read\" is flaky\nas reported here [1] because the close happens asynchronously.\n\nSolution\n\nDo the check using `eventually`.\n\n[1] https://github.com/twitter/util/issues/181\n\nRB_ID=886724","distinct":false,"url":"https://api.github.com/repos/twitter/util/commits/12dc4d3b5c363a6bfb0a6662c056a4e0c039d3a5"},{"sha":"1aae5cd04e54b30f381863b7740d676e15f7deec","author":{"name":"Bryce Anderson","email":"8c3473ac7364c5ba1a6fb9c24a1c89be7f35042e@twitter.com"},"message":"finagle-*: use libthrift from central repository\n\nProblem\n\nWe now have a libthrift artifact published under the com.twitter\norganization in Central Repository, but we don't use it.\n\nSolution\n\nUse it.\n\nRB_ID=885879","distinct":false,"url":"https://api.github.com/repos/twitter/util/commits/1aae5cd04e54b30f381863b7740d676e15f7deec"},{"sha":"5fe34b920f281cd9ae421fe4caa86f8a7b68aef0","author":{"name":"Kevin Oliver","email":"42f0c465f9d28c5edb4e65e73bb0815be7cdcaf5@twitter.com"},"message":"Bump version of Caffeine to 2.3.4\n\nProblem\n\nRecently we upgraded Caffeine to 2.3.3 just missing the release of\nversion 2.3.4 [1].\n\nSolution\n\nUpgrade to version 2.3.4.\n\n[1] https://github.com/twitter/finagle/commit/e321b8efb6df955e495a968e1a766ff61630fe4c#commitcomment-19640764\n\nRB_ID=886770","distinct":false,"url":"https://api.github.com/repos/twitter/util/commits/5fe34b920f281cd9ae421fe4caa86f8a7b68aef0"},{"sha":"66029846008186435dbeea40a89309580f8cdac2","author":{"name":"Kevin Oliver","email":"42f0c465f9d28c5edb4e65e73bb0815be7cdcaf5@twitter.com"},"message":"util-stats: Reduce allocations in Stat.timeFuture\n\nProblem\n\n`c.t.f.stats.Stat.timeFuture` can allocate less than it currently does.\n\nSolution\n\n* Use `Future.respond` to avoid the closure created by `ensure`.\n* Use `Stopwatch.timeNanos` instead of `Stopwatch.start`.\n\nResult\n\nSimilar latency profile with 25% less bytes allocated per call.\n\nJMH results:\n\n[info] Benchmark                                              Mode  Cnt    Score    Error   Units\n[info] StatBenchmark.timeFutureBaseline                       avgt   10  155.528 ±  5.025   ns/op\n[info] StatBenchmark.timeFutureBaseline:·gc.alloc.rate.norm   avgt   10  128.000 ±  0.001    B/op\n[info] StatBenchmark.timeFutureTimeNanos                      avgt   15  148.558 ±  2.834   ns/op\n[info] StatBenchmark.timeFutureTimeNanos:·gc.alloc.rate.norm  avgt   15   96.000 ±  0.001    B/op\n\nRB_ID=886684","distinct":false,"url":"https://api.github.com/repos/twitter/util/commits/66029846008186435dbeea40a89309580f8cdac2"},{"sha":"82abe3ef9b1f9a624475fcefbb311831b4321457","author":{"name":"Kevin Oliver","email":"42f0c465f9d28c5edb4e65e73bb0815be7cdcaf5@twitter.com"},"message":"util-stats: Improve concurrency of CumulativeGauge\n\nProblem\n\nFor services that have many instances of a single gauge and also\ncreate instances at a decent rate, the existing implementation of\n`c.t.f.stats.CumulativeGauge` does not offer enough concurrency.\n\nSolution\n\nSwitch to a concurrent data structure, a `Caffeine` based cache with\nweak keys.\n\nResult\n\nSingle threaded performance is roughly the same, but with improved\nvariance and fewer allocations.\n\nMultithreaded performance for `addGauge` is improved and also exhibits\nless variance.\n\nJMH results:\n\nBaseline, 1 thread\n[info] Benchmark                          (num)  Mode  Cnt       Score        Error   Units\n[info] CumulativeGaugeBenchmark.getValue      1  avgt   10      37.966 ±      1.263   ns/op\n[info] CumulativeGaugeBenchmark.getValue     10  avgt   10      91.807 ±      1.960   ns/op\n[info] CumulativeGaugeBenchmark.getValue    100  avgt   10     649.807 ±     23.930   ns/op\n[info] CumulativeGaugeBenchmark.getValue   1000  avgt   10    8091.154 ±    197.326   ns/op\n[info] CumulativeGaugeBenchmark.getValue  10000  avgt   10  255921.283 ± 101201.177   ns/op\n[info] CumulativeGaugeBenchmark.addGauge      1    ss  500     231.872 ±     34.837   us/op\n[info] CumulativeGaugeBenchmark.addGauge     10    ss  500     210.518 ±     29.679   us/op\n[info] CumulativeGaugeBenchmark.addGauge    100    ss  500     184.764 ±     41.403   us/op\n[info] CumulativeGaugeBenchmark.addGauge   1000    ss  500     305.243 ±     65.614   us/op\n[info] CumulativeGaugeBenchmark.addGauge  10000    ss  500    1842.600 ±    181.803   us/op\n\nCaffeine, 1 thread\n[info] Benchmark                          (num)  Mode  Cnt       Score       Error  Units\n[info] CumulativeGaugeBenchmark.getValue      1  avgt   10      28.950 ±     0.741  ns/op\n[info] CumulativeGaugeBenchmark.getValue     10  avgt   10     109.054 ±     3.609  ns/op\n[info] CumulativeGaugeBenchmark.getValue    100  avgt   10    1160.975 ±    28.884  ns/op\n[info] CumulativeGaugeBenchmark.getValue   1000  avgt   10   13105.077 ±   630.811  ns/op\n[info] CumulativeGaugeBenchmark.getValue  10000  avgt   10  309212.511 ± 30748.487  ns/op\n[info] CumulativeGaugeBenchmark.addGauge      1    ss  500     301.126 ±    96.240  us/op\n[info] CumulativeGaugeBenchmark.addGauge     10    ss  500     256.668 ±    76.608  us/op\n[info] CumulativeGaugeBenchmark.addGauge    100    ss  500     223.851 ±    89.035  us/op\n[info] CumulativeGaugeBenchmark.addGauge   1000    ss  500      73.080 ±    38.592  us/op\n[info] CumulativeGaugeBenchmark.addGauge  10000    ss  500      84.580 ±    22.061  us/op\n\nBaseline allocations, 1 thread\n[info] Benchmark                                             (num)  Mode  Cnt          Score        Error   Units\n[info] CumulativeGaugeBenchmark.getValue:·gc.alloc.rate.norm     1  avgt   10         81.280 ±      0.006    B/op\n[info] CumulativeGaugeBenchmark.getValue:·gc.alloc.rate.norm    10  avgt   10         97.282 ±      0.006    B/op\n[info] CumulativeGaugeBenchmark.getValue:·gc.alloc.rate.norm   100  avgt   10        466.769 ±      0.156    B/op\n[info] CumulativeGaugeBenchmark.getValue:·gc.alloc.rate.norm  1000  avgt   10       4145.553 ±      3.655    B/op\n[info] CumulativeGaugeBenchmark.getValue:·gc.alloc.rate.norm 10000  avgt   10     125581.765 ±  27424.283    B/op\n[info] CumulativeGaugeBenchmark.addGauge:·gc.alloc.rate.norm     1    ss  500      40681.568 ±   1517.551    B/op\n[info] CumulativeGaugeBenchmark.addGauge:·gc.alloc.rate.norm    10    ss  500      45952.064 ±   1722.397    B/op\n[info] CumulativeGaugeBenchmark.addGauge:·gc.alloc.rate.norm   100    ss  500     135399.424 ±   5457.466    B/op\n[info] CumulativeGaugeBenchmark.addGauge:·gc.alloc.rate.norm  1000    ss  500    3694193.872 ±  15415.259    B/op\n[info] CumulativeGaugeBenchmark.addGauge:·gc.alloc.rate.norm 10000    ss  500  312415708.768 ± 108408.777    B/op\n\nCaffiene allocations, 1 thread\n[info] CumulativeGaugeBenchmark.getValue:·gc.alloc.rate.norm     1  avgt   10       56.000 ±       0.001    B/op\n[info] CumulativeGaugeBenchmark.getValue:·gc.alloc.rate.norm    10  avgt   10       56.001 ±       0.001    B/op\n[info] CumulativeGaugeBenchmark.getValue:·gc.alloc.rate.norm   100  avgt   10       56.031 ±       0.008    B/op\n[info] CumulativeGaugeBenchmark.getValue:·gc.alloc.rate.norm  1000  avgt   10       58.870 ±       0.094    B/op\n[info] CumulativeGaugeBenchmark.getValue:·gc.alloc.rate.norm 10000  avgt   10      678.190 ±      46.169    B/op\n[info] CumulativeGaugeBenchmark.addGauge:·gc.alloc.rate.norm     1    ss  500    22186.128 ±     191.917    B/op\n[info] CumulativeGaugeBenchmark.addGauge:·gc.alloc.rate.norm    10    ss  500    24616.064 ±     257.272    B/op\n[info] CumulativeGaugeBenchmark.addGauge:·gc.alloc.rate.norm   100    ss  500    43640.768 ±     379.145    B/op\n[info] CumulativeGaugeBenchmark.addGauge:·gc.alloc.rate.norm  1000    ss  500   243520.912 ±    2113.730    B/op\n[info] CumulativeGaugeBenchmark.addGauge:·gc.alloc.rate.norm 10000    ss  500  2060851.408 ±   17038.389    B/op\n\nBaseline, 4 threads:\n[info] Benchmark                          (num)  Mode  Cnt       Score        Error  Units\n[info] CumulativeGaugeBenchmark.addGauge      1    ss  500     273.319 ±     57.173  us/op\n[info] CumulativeGaugeBenchmark.addGauge     10    ss  500     256.069 ±     66.874  us/op\n[info] CumulativeGaugeBenchmark.addGauge    100    ss  500     215.339 ±     60.386  us/op\n[info] CumulativeGaugeBenchmark.addGauge   1000    ss  500    1184.117 ±    202.674  us/op\n[info] CumulativeGaugeBenchmark.addGauge  10000    ss  500    5309.283 ±    333.736  us/op\n\nCaffeine, 4 threads:\n[info] Benchmark                          (num)  Mode  Cnt       Score       Error  Units\n[info] CumulativeGaugeBenchmark.addGauge      1    ss  500     221.278 ±    49.255  us/op\n[info] CumulativeGaugeBenchmark.addGauge     10    ss  500     196.825 ±    40.440  us/op\n[info] CumulativeGaugeBenchmark.addGauge    100    ss  500     170.842 ±    54.009  us/op\n[info] CumulativeGaugeBenchmark.addGauge   1000    ss  500      98.332 ±    52.656  us/op\n[info] CumulativeGaugeBenchmark.addGauge  10000    ss  500     104.673 ±    31.980  us/op\n\nRB_ID=885833","distinct":false,"url":"https://api.github.com/repos/twitter/util/commits/82abe3ef9b1f9a624475fcefbb311831b4321457"},{"sha":"653925dbb7ef4cf054fd23c2f94ef3693e0d40d3","author":{"name":"Christopher Coco","email":"73f81dcde656bf14f3aba707425184e601614d53@twitter.com"},"message":"finagle,finatra,scrooge,twitter-server,util: Update site scripts\n\nProblem/Solution\n\nA lot of times site generation fails due to a scaladoc issue\nbut we dev/null the output making it hard to debug and fix.\n\nLet's stop sending the site and scaladoc output to dev/null.\n\nRB_ID=887173","distinct":false,"url":"https://api.github.com/repos/twitter/util/commits/653925dbb7ef4cf054fd23c2f94ef3693e0d40d3"},{"sha":"42dea8869c3dd1db4a19cb030a0496d0b982b606","author":{"name":"Bryce Anderson","email":"8c3473ac7364c5ba1a6fb9c24a1c89be7f35042e@twitter.com"},"message":"finagle: Fix sbt build failure due to transient libthrift dependencies\n\nProblem\n\nTransient dependencies are looking for 'org.apache.thrift' libthrift and\ncan't find it because we've removed the resolver for maven.twttr.com.\n\nSolution\n\nAdd a couple of exclusion rules.\n\nRB_ID=887263","distinct":false,"url":"https://api.github.com/repos/twitter/util/commits/42dea8869c3dd1db4a19cb030a0496d0b982b606"},{"sha":"5ebef05c62b6018cd3ca46654f02cd0db1c49131","author":{"name":"Daniel Schobel","email":"67662df2ffee7debcd16f68b05f1a09e938277a6@twitter.com"},"message":"[finagle|util]-benchmark: fixup sbt invocation docs for jmh\n\nProblem / Solution\n\nfix sbt invocation docs for jmh benchmarks.\n\nRB_ID=887525","distinct":false,"url":"https://api.github.com/repos/twitter/util/commits/5ebef05c62b6018cd3ca46654f02cd0db1c49131"},{"sha":"ebdb58e732aaaa81eeac3451e5df4cfb715821ee","author":{"name":"Moses Nakamura","email":"027e942e2a8d9c3b29816dfa40893330d419351a@twitter.com"},"message":"util-stats: Fixed a race condition in CumulativeGauge\n\nProblem\n\nCumulativeGauge had a problem where we could lose gauges when they flapped\nbetween 0 gauges for a name and 1 gauge for a name.\n\nSolution\n\nJava 8 introduces ConcurrentHashMap#computeIfAbsent which simplifies some of the\nupdating code.  Java 7 introduces Phaser, which allows us to tear down the\ngauge permanently after every gauge has declared it wants to be torn down.  Once\nwe've torn down the gauge, we return a null, signalling to the caller that it\nmust make a new CumulativeGauge.\n\nResult\n\nCumulativeGauge is now threadsafe, and registration and deregistration are now\nasynchronous.\n\nRB_ID=887484","distinct":false,"url":"https://api.github.com/repos/twitter/util/commits/ebdb58e732aaaa81eeac3451e5df4cfb715821ee"}]}
{"actor":{"display_login":"finaglehelper"}}