otlptranslator: fix up import paths

Fix up inline import paths. These get ignored most of the time by the Go module based tooling, but GOPATH based tooling expects it to match the real import path.

This is intentional actually, as the files are COPIED AS-IS as mentioned in the header and we want the imports to use that path. See https://go.dev/doc/go1.4#canonicalimports and https://github.com/prometheus/prometheus/tree/main/storage/remote/otlptranslator#copying-from-opentelemetryopentelemetry-collector-contrib
What's exactly does your tooling complain about?

I don't think that it is intentional, there is shell script that adjusts the import paths for this bit of code https://github.com/prometheus/prometheus/blob/main/storage/remote/otlptranslator/update-copy.sh among other things.
For the record just go test/build running in GOPATH mode not liking it.
otlptranslator/prometheusremotewrite/helper.go:27:2: code in directory /builddir/build/BUILD/prometheus-2.50.1/_build/src/github.com/prometheus/prometheus/storage/remote/otlptranslator/prometheus expects import "github.com/open-telemetry/opentelemetry-collector-contrib/pkg/translator/prometheus"
It seems as possible regression since the last bump to this, I haven't bisected it.

Maybe I understood it backwards, but the sed in that file is only for the ./prometheusremotewrite/*.go which doesn't cover the 3 files you changed https://github.com/prometheus/prometheus/blob/f1e9ec29f8f7d8c273e8980494be6aca18e1ef6f/storage/remote/otlptranslator/update-copy.sh#L26. Plus the README doesn't seem to be up to date anymore (after https://github.com/prometheus/prometheus/tree/main/storage/remote/otlptranslator, we copy /.prometheus as well now)
I'll cc @gouthamve to get a confirmation and the script and the README need to be adapter.
(That would fix the imports)

Maybe I understood it backwards, but the sed in that file is only for the ./prometheusremotewrite/*.go which doesn't cover the 3 files you changed

I suspect that update-copy.sh should also fix the import paths in the prometheus/ directory.

Yup! I agreee with @machine424 and @aknuds1 , we probably need to update the script to update all the import paths and dont leave any files behind, maybe those files were introduced later and hence the issue.
The reason why we do this with the import paths is that the code from the otel contrib repo still is the source of truth. We cant just import it because there is a cycilical dependency so what we do is try to keep prometheus updated with it. This is not the best scenario but until prometheus becomes the source of truth for that code its what we've got.
@jcajka maybe you'd like to update the script to sed all the imports properly instead?

I believe that this is the case that the package should be used just under one import path(the canonical one) per the https://go.dev/doc/go1.4#canonicalimports.
Ack, I will fix up the script and I guess the README too, along with the import paths.

Done. Tested by running the script, creates no changes to the tree for me locally.

Thanks for your contributions @jcajka!

Thank you all for quick review and feedback


Bump SafeMath to latest OZ

update SafeMath to latest OpenZeppelin implementation w/ dev notes: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/math/SafeMath.sol

closed cuz mostly irrelevant


Eureka Server Instance, peer1 shut down when running peer2

I tried to create two instances, peer1 and peer2, running peer1 is fine, but when running peer2, peer1 is shut down but peer2 is running.
application.yaml
server:
  servlet:
    context-path: /
eureka:
  server:
    enable-self-preservation: false
    renewal-threshold-update-interval-ms: 300000
  instance:
    statusPageUrlPath: ${server.servlet.context-path}/info
    healthCheckUrlPath: ${server.servlet.context-path}/health
    homePageUrl: ${server.servlet.context-path}/
spring:
  profiles:
    active: peer1 #peer2

application-peer1.yaml
spring:
  application:
    name: eureka-server
server:
  port: 8762
eureka:
  instance:
    hostname: my-eureka-server.com
    appName: eureka-instance
  client:
    registerWithEureka: false
    fetchRegistry: false
    serviceUrl:
      defaultZone: http://my-eureka-server-1.com:8763/eureka/

application-peer2.yaml
spring:
  application:
    name: eureka-server
server:
  port: 8763
eureka:
  instance:
    hostname: my-eureka-server-1.com
    appName: eureka-instance
  client:
    registerWithEureka: false
    fetchRegistry: false
    serviceUrl:
      defaultZone: http://my-eureka-server.com:8762/eureka/

log peer1.
2024-12-26T20:14:28.995+07:00  INFO 2032 --- [eureka-server] [  restartedMain] i.mvi.lb.LoadBalancerServiceApplication  : Starting LoadBalancerServiceApplication using Java 17.0.12 with PID 2032 (/Users/widiyanto./Documents/Work/Microservices/eureka-discovery-service/build/classes/java/main started by widiyanto. in /Users/widiyanto./Documents/Work/Microservices/main-service)
2024-12-26T20:14:28.997+07:00  INFO 2032 --- [eureka-server] [  restartedMain] i.mvi.lb.LoadBalancerServiceApplication  : The following 1 profile is active: "peer1"
2024-12-26T20:14:29.028+07:00  INFO 2032 --- [eureka-server] [  restartedMain] .e.DevToolsPropertyDefaultsPostProcessor : Devtools property defaults active! Set 'spring.devtools.add-properties' to 'false' to disable
2024-12-26T20:14:29.028+07:00  INFO 2032 --- [eureka-server] [  restartedMain] .e.DevToolsPropertyDefaultsPostProcessor : For additional web related logging consider setting the 'logging.level.web' property to 'DEBUG'
2024-12-26T20:14:29.643+07:00  INFO 2032 --- [eureka-server] [  restartedMain] o.s.cloud.context.scope.GenericScope     : BeanFactory id=fe1e9c0c-65d8-3a60-9dcf-0b96a7515b22
2024-12-26T20:14:29.673+07:00  WARN 2032 --- [eureka-server] [  restartedMain] trationDelegate$BeanPostProcessorChecker : Bean 'org.springframework.cloud.client.loadbalancer.LoadBalancerAutoConfiguration$DeferringLoadBalancerInterceptorConfig' of type [org.springframework.cloud.client.loadbalancer.LoadBalancerAutoConfiguration$DeferringLoadBalancerInterceptorConfig] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying). The currently created BeanPostProcessor [lbRestClientPostProcessor] is declared through a non-static factory method on that class; consider declaring it as static instead.
2024-12-26T20:14:29.675+07:00  WARN 2032 --- [eureka-server] [  restartedMain] trationDelegate$BeanPostProcessorChecker : Bean 'deferringLoadBalancerInterceptor' of type [org.springframework.cloud.client.loadbalancer.DeferringLoadBalancerInterceptor] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying). Is this bean getting eagerly injected/applied to a currently created BeanPostProcessor [lbRestClientPostProcessor]? Check the corresponding BeanPostProcessor declaration and its dependencies/advisors. If this bean does not have to be post-processed, declare it with ROLE_INFRASTRUCTURE.
2024-12-26T20:14:29.957+07:00  INFO 2032 --- [eureka-server] [  restartedMain] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat initialized with port 8762 (http)
2024-12-26T20:14:29.967+07:00  INFO 2032 --- [eureka-server] [  restartedMain] o.apache.catalina.core.StandardService   : Starting service [Tomcat]
2024-12-26T20:14:29.967+07:00  INFO 2032 --- [eureka-server] [  restartedMain] o.apache.catalina.core.StandardEngine    : Starting Servlet engine: [Apache Tomcat/10.1.33]
2024-12-26T20:14:30.003+07:00  INFO 2032 --- [eureka-server] [  restartedMain] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring embedded WebApplicationContext
2024-12-26T20:14:30.003+07:00  INFO 2032 --- [eureka-server] [  restartedMain] w.s.c.ServletWebServerApplicationContext : Root WebApplicationContext: initialization completed in 974 ms
2024-12-26T20:14:30.490+07:00  INFO 2032 --- [eureka-server] [  restartedMain] c.n.d.provider.DiscoveryJerseyProvider   : Using JSON encoding codec LegacyJacksonJson
2024-12-26T20:14:30.491+07:00  INFO 2032 --- [eureka-server] [  restartedMain] c.n.d.provider.DiscoveryJerseyProvider   : Using JSON decoding codec LegacyJacksonJson
2024-12-26T20:14:30.634+07:00  INFO 2032 --- [eureka-server] [  restartedMain] c.n.d.provider.DiscoveryJerseyProvider   : Using XML encoding codec XStreamXml
2024-12-26T20:14:30.634+07:00  INFO 2032 --- [eureka-server] [  restartedMain] c.n.d.provider.DiscoveryJerseyProvider   : Using XML decoding codec XStreamXml
2024-12-26T20:14:31.073+07:00  INFO 2032 --- [eureka-server] [  restartedMain] o.s.b.d.a.OptionalLiveReloadServer       : LiveReload server is running on port 35729
2024-12-26T20:14:31.114+07:00  WARN 2032 --- [eureka-server] [  restartedMain] iguration$LoadBalancerCaffeineWarnLogger : Spring Cloud LoadBalancer is currently working with the default cache. While this cache implementation is useful for development and tests, it's recommended to use Caffeine cache in production.You can switch to using Caffeine cache, by adding it and org.springframework.cache.caffeine.CaffeineCacheManager to the classpath.
2024-12-26T20:14:31.123+07:00  INFO 2032 --- [eureka-server] [  restartedMain] o.s.c.n.eureka.InstanceInfoFactory       : Setting initial instance status as: STARTING
2024-12-26T20:14:31.135+07:00  INFO 2032 --- [eureka-server] [  restartedMain] com.netflix.discovery.DiscoveryClient    : Initializing Eureka in region us-east-1
2024-12-26T20:14:31.135+07:00  INFO 2032 --- [eureka-server] [  restartedMain] com.netflix.discovery.DiscoveryClient    : Client configured to neither register nor query for data.
2024-12-26T20:14:31.136+07:00  INFO 2032 --- [eureka-server] [  restartedMain] com.netflix.discovery.DiscoveryClient    : Discovery Client initialized at timestamp<PHONE_NUMBER>135 with initial instances count: 0
2024-12-26T20:14:31.158+07:00  INFO 2032 --- [eureka-server] [  restartedMain] c.n.eureka.DefaultEurekaServerContext    : Initializing ...
2024-12-26T20:14:31.159+07:00  INFO 2032 --- [eureka-server] [  restartedMain] c.n.eureka.cluster.PeerEurekaNodes       : Adding new peer nodes [http://my-eureka-server-1.com:8763/eureka/]
2024-12-26T20:14:31.260+07:00  INFO 2032 --- [eureka-server] [  restartedMain] c.n.d.provider.DiscoveryJerseyProvider   : Using JSON encoding codec LegacyJacksonJson
2024-12-26T20:14:31.260+07:00  INFO 2032 --- [eureka-server] [  restartedMain] c.n.d.provider.DiscoveryJerseyProvider   : Using JSON decoding codec LegacyJacksonJson
2024-12-26T20:14:31.260+07:00  INFO 2032 --- [eureka-server] [  restartedMain] c.n.d.provider.DiscoveryJerseyProvider   : Using XML encoding codec XStreamXml
2024-12-26T20:14:31.260+07:00  INFO 2032 --- [eureka-server] [  restartedMain] c.n.d.provider.DiscoveryJerseyProvider   : Using XML decoding codec XStreamXml
2024-12-26T20:14:31.283+07:00  INFO 2032 --- [eureka-server] [  restartedMain] c.n.eureka.cluster.PeerEurekaNodes       : Replica node URL:  http://my-eureka-server-1.com:8763/eureka/
2024-12-26T20:14:31.289+07:00  INFO 2032 --- [eureka-server] [  restartedMain] c.n.e.registry.AbstractInstanceRegistry  : Finished initializing remote region registries. All known remote regions: []
2024-12-26T20:14:31.289+07:00  INFO 2032 --- [eureka-server] [  restartedMain] c.n.eureka.DefaultEurekaServerContext    : Initialized
2024-12-26T20:14:31.295+07:00  INFO 2032 --- [eureka-server] [  restartedMain] o.s.b.a.e.web.EndpointLinksResolver      : Exposing 1 endpoint beneath base path '/actuator'
2024-12-26T20:14:31.333+07:00  INFO 2032 --- [eureka-server] [  restartedMain] o.s.c.n.e.s.EurekaServiceRegistry        : Registering application EUREKA-INSTANCE with eureka with status UP
2024-12-26T20:14:31.341+07:00  INFO 2032 --- [eureka-server] [      Thread-15] o.s.c.n.e.server.EurekaServerBootstrap   : isAws returned false
2024-12-26T20:14:31.341+07:00  INFO 2032 --- [eureka-server] [      Thread-15] o.s.c.n.e.server.EurekaServerBootstrap   : Initialized server context
2024-12-26T20:14:31.341+07:00  INFO 2032 --- [eureka-server] [      Thread-15] c.n.e.r.PeerAwareInstanceRegistryImpl    : Got 1 instances from neighboring DS node
2024-12-26T20:14:31.341+07:00  INFO 2032 --- [eureka-server] [      Thread-15] c.n.e.r.PeerAwareInstanceRegistryImpl    : Renew threshold is: 1
2024-12-26T20:14:31.341+07:00  INFO 2032 --- [eureka-server] [      Thread-15] c.n.e.r.PeerAwareInstanceRegistryImpl    : Changing status to UP
2024-12-26T20:14:31.342+07:00  INFO 2032 --- [eureka-server] [      Thread-15] e.s.EurekaServerInitializerConfiguration : Started Eureka Server
2024-12-26T20:14:31.347+07:00  INFO 2032 --- [eureka-server] [  restartedMain] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port 8762 (http) with context path '/'
2024-12-26T20:14:31.348+07:00  INFO 2032 --- [eureka-server] [  restartedMain] .s.c.n.e.s.EurekaAutoServiceRegistration : Updating port to 8762
2024-12-26T20:14:31.374+07:00  INFO 2032 --- [eureka-server] [  restartedMain] i.mvi.lb.LoadBalancerServiceApplication  : Started LoadBalancerServiceApplication in 2.65 seconds (process running for 3.021)
2024-12-26T20:15:08.978+07:00  INFO 2032 --- [eureka-server] [nio-8762-exec-1] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring DispatcherServlet 'dispatcherServlet'
2024-12-26T20:15:08.979+07:00  INFO 2032 --- [eureka-server] [nio-8762-exec-1] o.s.web.servlet.DispatcherServlet        : Initializing Servlet 'dispatcherServlet'
2024-12-26T20:15:08.981+07:00  INFO 2032 --- [eureka-server] [nio-8762-exec-1] o.s.web.servlet.DispatcherServlet        : Completed initialization in 2 ms
2024-12-26T20:15:31.345+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 0ms
2024-12-26T20:16:00.221+07:00  INFO 2032 --- [eureka-server] [   File Watcher] rtingClassPathChangeChangedEventListener : Restarting due to 9 class path changes (0 additions, 0 deletions, 9 modifications)
2024-12-26T20:16:00.222+07:00  INFO 2032 --- [eureka-server] [       Thread-7] o.s.c.n.e.s.EurekaServiceRegistry        : Unregistering application EUREKA-INSTANCE with eureka with status DOWN
2024-12-26T20:16:00.227+07:00  INFO 2032 --- [eureka-server] [       Thread-7] o.s.c.n.e.server.EurekaServerBootstrap   : Shutting down Eureka Server..
2024-12-26T20:16:00.227+07:00  INFO 2032 --- [eureka-server] [       Thread-7] c.n.eureka.DefaultEurekaServerContext    : Shutting down ...
2024-12-26T20:16:00.228+07:00  INFO 2032 --- [eureka-server] [       Thread-7] c.n.eureka.DefaultEurekaServerContext    : Shut down
2024-12-26T20:16:00.228+07:00  INFO 2032 --- [eureka-server] [       Thread-7] o.s.c.n.e.server.EurekaServerBootstrap   : Eureka Service is now shutdown...
2024-12-26T20:16:00.228+07:00  INFO 2032 --- [eureka-server] [       Thread-7] c.n.eureka.DefaultEurekaServerContext    : Shutting down ...
2024-12-26T20:16:00.228+07:00  INFO 2032 --- [eureka-server] [       Thread-7] c.n.eureka.DefaultEurekaServerContext    : Shut down
2024-12-26T20:16:00.233+07:00  INFO 2032 --- [eureka-server] [       Thread-7] com.netflix.discovery.DiscoveryClient    : Shutting down DiscoveryClient ...
2024-12-26T20:16:00.233+07:00  INFO 2032 --- [eureka-server] [       Thread-7] com.netflix.discovery.DiscoveryClient    : Completed shut down of DiscoveryClient
  _____                         __ ______         __
 |_   _|                       |  ]_   _ \       [  |
   | |      .--.   ,--.    .--.| |  | |_) | ,--.  | | ,--.  _ .--.   .---. .---.  _ .--.
   | |   _/ .'`\ \`'_\ : / /'`\' |  |  __'.`'_\ : | |`'_\ :[ `.-. | / /'`\] /__\\[ `/'`\]
  _| |__/ | \__. |// | |,| \__/  | _| |__) // | |,| |// | |,| | | | | \__.| \__., | |
 |________|'.__.' \'-;__/ '.__.;__]_______/\'-;__[___]'-;__[___||__]'.___.''.__.'[___]

Powered by Spring Boot 3.3.6
2024-12-26T20:16:00.303+07:00  INFO 2032 --- [eureka-server] [  restartedMain] i.mvi.lb.LoadBalancerServiceApplication  : Starting LoadBalancerServiceApplication using Java 17.0.12 with PID 2032 (/Users/widiyanto./Documents/Work/Microservices/eureka-discovery-service/build/classes/java/main started by widiyanto. in /Users/widiyanto./Documents/Work/Microservices/main-service)
2024-12-26T20:16:00.303+07:00  INFO 2032 --- [eureka-server] [  restartedMain] i.mvi.lb.LoadBalancerServiceApplication  : The following 1 profile is active: "peer2"
2024-12-26T20:16:00.477+07:00  INFO 2032 --- [eureka-server] [  restartedMain] o.s.cloud.context.scope.GenericScope     : BeanFactory id=fe1e9c0c-65d8-3a60-9dcf-0b96a7515b22
2024-12-26T20:16:00.483+07:00  WARN 2032 --- [eureka-server] [  restartedMain] trationDelegate$BeanPostProcessorChecker : Bean 'org.springframework.cloud.client.loadbalancer.LoadBalancerAutoConfiguration$DeferringLoadBalancerInterceptorConfig' of type [org.springframework.cloud.client.loadbalancer.LoadBalancerAutoConfiguration$DeferringLoadBalancerInterceptorConfig] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying). The currently created BeanPostProcessor [lbRestClientPostProcessor] is declared through a non-static factory method on that class; consider declaring it as static instead.
2024-12-26T20:16:00.484+07:00  WARN 2032 --- [eureka-server] [  restartedMain] trationDelegate$BeanPostProcessorChecker : Bean 'deferringLoadBalancerInterceptor' of type [org.springframework.cloud.client.loadbalancer.DeferringLoadBalancerInterceptor] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying). Is this bean getting eagerly injected/applied to a currently created BeanPostProcessor [lbRestClientPostProcessor]? Check the corresponding BeanPostProcessor declaration and its dependencies/advisors. If this bean does not have to be post-processed, declare it with ROLE_INFRASTRUCTURE.
2024-12-26T20:16:00.517+07:00  INFO 2032 --- [eureka-server] [  restartedMain] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat initialized with port 8763 (http)
2024-12-26T20:16:00.518+07:00  INFO 2032 --- [eureka-server] [  restartedMain] o.apache.catalina.core.StandardService   : Starting service [Tomcat]
2024-12-26T20:16:00.518+07:00  INFO 2032 --- [eureka-server] [  restartedMain] o.apache.catalina.core.StandardEngine    : Starting Servlet engine: [Apache Tomcat/10.1.33]
2024-12-26T20:16:00.535+07:00  INFO 2032 --- [eureka-server] [  restartedMain] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring embedded WebApplicationContext
2024-12-26T20:16:00.535+07:00  INFO 2032 --- [eureka-server] [  restartedMain] w.s.c.ServletWebServerApplicationContext : Root WebApplicationContext: initialization completed in 231 ms
2024-12-26T20:16:00.718+07:00  INFO 2032 --- [eureka-server] [  restartedMain] c.n.d.provider.DiscoveryJerseyProvider   : Using JSON encoding codec LegacyJacksonJson
2024-12-26T20:16:00.718+07:00  INFO 2032 --- [eureka-server] [  restartedMain] c.n.d.provider.DiscoveryJerseyProvider   : Using JSON decoding codec LegacyJacksonJson
2024-12-26T20:16:00.718+07:00  INFO 2032 --- [eureka-server] [  restartedMain] c.n.d.provider.DiscoveryJerseyProvider   : Using XML encoding codec XStreamXml
2024-12-26T20:16:00.719+07:00  INFO 2032 --- [eureka-server] [  restartedMain] c.n.d.provider.DiscoveryJerseyProvider   : Using XML decoding codec XStreamXml
2024-12-26T20:16:00.898+07:00  INFO 2032 --- [eureka-server] [  restartedMain] o.s.b.d.a.OptionalLiveReloadServer       : LiveReload server is running on port 35729
2024-12-26T20:16:00.926+07:00  WARN 2032 --- [eureka-server] [  restartedMain] iguration$LoadBalancerCaffeineWarnLogger : Spring Cloud LoadBalancer is currently working with the default cache. While this cache implementation is useful for development and tests, it's recommended to use Caffeine cache in production.You can switch to using Caffeine cache, by adding it and org.springframework.cache.caffeine.CaffeineCacheManager to the classpath.
2024-12-26T20:16:00.930+07:00  INFO 2032 --- [eureka-server] [  restartedMain] o.s.c.n.eureka.InstanceInfoFactory       : Setting initial instance status as: STARTING
2024-12-26T20:16:00.931+07:00  INFO 2032 --- [eureka-server] [  restartedMain] com.netflix.discovery.DiscoveryClient    : Initializing Eureka in region us-east-1
2024-12-26T20:16:00.931+07:00  INFO 2032 --- [eureka-server] [  restartedMain] com.netflix.discovery.DiscoveryClient    : Client configured to neither register nor query for data.
2024-12-26T20:16:00.931+07:00  INFO 2032 --- [eureka-server] [  restartedMain] com.netflix.discovery.DiscoveryClient    : Discovery Client initialized at timestamp<PHONE_NUMBER>931 with initial instances count: 0
2024-12-26T20:16:00.946+07:00  INFO 2032 --- [eureka-server] [  restartedMain] c.n.eureka.DefaultEurekaServerContext    : Initializing ...
2024-12-26T20:16:00.946+07:00  INFO 2032 --- [eureka-server] [  restartedMain] c.n.eureka.cluster.PeerEurekaNodes       : Adding new peer nodes [http://my-eureka-server.com:8762/eureka/]
2024-12-26T20:16:00.953+07:00  INFO 2032 --- [eureka-server] [  restartedMain] c.n.d.provider.DiscoveryJerseyProvider   : Using JSON encoding codec LegacyJacksonJson
2024-12-26T20:16:00.954+07:00  INFO 2032 --- [eureka-server] [  restartedMain] c.n.d.provider.DiscoveryJerseyProvider   : Using JSON decoding codec LegacyJacksonJson
2024-12-26T20:16:00.954+07:00  INFO 2032 --- [eureka-server] [  restartedMain] c.n.d.provider.DiscoveryJerseyProvider   : Using XML encoding codec XStreamXml
2024-12-26T20:16:00.954+07:00  INFO 2032 --- [eureka-server] [  restartedMain] c.n.d.provider.DiscoveryJerseyProvider   : Using XML decoding codec XStreamXml
2024-12-26T20:16:00.993+07:00  INFO 2032 --- [eureka-server] [  restartedMain] c.n.eureka.cluster.PeerEurekaNodes       : Replica node URL:  http://my-eureka-server.com:8762/eureka/
2024-12-26T20:16:00.994+07:00  INFO 2032 --- [eureka-server] [  restartedMain] c.n.e.registry.AbstractInstanceRegistry  : Finished initializing remote region registries. All known remote regions: []
2024-12-26T20:16:00.994+07:00  INFO 2032 --- [eureka-server] [  restartedMain] c.n.eureka.DefaultEurekaServerContext    : Initialized
2024-12-26T20:16:01.001+07:00  INFO 2032 --- [eureka-server] [  restartedMain] o.s.b.a.e.web.EndpointLinksResolver      : Exposing 1 endpoint beneath base path '/actuator'
2024-12-26T20:16:01.020+07:00  INFO 2032 --- [eureka-server] [  restartedMain] o.s.c.n.e.s.EurekaServiceRegistry        : Registering application EUREKA-INSTANCE with eureka with status UP
2024-12-26T20:16:01.022+07:00  INFO 2032 --- [eureka-server] [      Thread-28] o.s.c.n.e.server.EurekaServerBootstrap   : isAws returned false
2024-12-26T20:16:01.022+07:00  INFO 2032 --- [eureka-server] [      Thread-28] o.s.c.n.e.server.EurekaServerBootstrap   : Initialized server context
2024-12-26T20:16:01.022+07:00  INFO 2032 --- [eureka-server] [      Thread-28] c.n.e.r.PeerAwareInstanceRegistryImpl    : Got 1 instances from neighboring DS node
2024-12-26T20:16:01.022+07:00  INFO 2032 --- [eureka-server] [      Thread-28] c.n.e.r.PeerAwareInstanceRegistryImpl    : Renew threshold is: 1
2024-12-26T20:16:01.022+07:00  INFO 2032 --- [eureka-server] [      Thread-28] c.n.e.r.PeerAwareInstanceRegistryImpl    : Changing status to UP
2024-12-26T20:16:01.022+07:00  INFO 2032 --- [eureka-server] [      Thread-28] e.s.EurekaServerInitializerConfiguration : Started Eureka Server
2024-12-26T20:16:01.025+07:00  INFO 2032 --- [eureka-server] [  restartedMain] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port 8763 (http) with context path '/'
2024-12-26T20:16:01.026+07:00  INFO 2032 --- [eureka-server] [  restartedMain] .s.c.n.e.s.EurekaAutoServiceRegistration : Updating port to 8763
2024-12-26T20:16:01.057+07:00  INFO 2032 --- [eureka-server] [  restartedMain] i.mvi.lb.LoadBalancerServiceApplication  : Started LoadBalancerServiceApplication in 0.776 seconds (process running for 92.703)
2024-12-26T20:16:01.069+07:00  INFO 2032 --- [eureka-server] [  restartedMain] .ConditionEvaluationDeltaLoggingListener : Condition evaluation unchanged
2024-12-26T20:16:42.565+07:00  INFO 2032 --- [eureka-server] [nio-8763-exec-1] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring DispatcherServlet 'dispatcherServlet'
2024-12-26T20:16:42.565+07:00  INFO 2032 --- [eureka-server] [nio-8763-exec-1] o.s.web.servlet.DispatcherServlet        : Initializing Servlet 'dispatcherServlet'
2024-12-26T20:16:42.567+07:00  INFO 2032 --- [eureka-server] [nio-8763-exec-1] o.s.web.servlet.DispatcherServlet        : Completed initialization in 2 ms
2024-12-26T20:17:01.028+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 0ms
2024-12-26T20:18:01.030+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 1ms
2024-12-26T20:19:01.033+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 2ms
2024-12-26T20:20:01.038+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 4ms
2024-12-26T20:21:01.003+07:00  INFO 2032 --- [eureka-server] [hresholdUpdater] c.n.e.r.PeerAwareInstanceRegistryImpl    : Current renewal threshold is : 0
2024-12-26T20:21:01.043+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 4ms
2024-12-26T20:22:01.048+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 3ms
2024-12-26T20:23:01.051+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 2ms
2024-12-26T20:24:01.056+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 4ms
2024-12-26T20:25:01.062+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 5ms
2024-12-26T20:26:01.010+07:00  INFO 2032 --- [eureka-server] [hresholdUpdater] c.n.e.r.PeerAwareInstanceRegistryImpl    : Current renewal threshold is : 0
2024-12-26T20:26:01.066+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 3ms
2024-12-26T20:27:01.066+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 0ms
2024-12-26T20:28:01.070+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 3ms
2024-12-26T20:29:01.071+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 0ms
2024-12-26T20:30:01.075+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 4ms
2024-12-26T20:31:01.018+07:00  INFO 2032 --- [eureka-server] [hresholdUpdater] c.n.e.r.PeerAwareInstanceRegistryImpl    : Current renewal threshold is : 0
2024-12-26T20:31:01.081+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 4ms
2024-12-26T20:32:01.084+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 2ms
2024-12-26T20:33:01.086+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 1ms
2024-12-26T20:34:01.091+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 4ms
2024-12-26T20:40:50.225+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 3ms
2024-12-26T20:41:50.150+07:00  INFO 2032 --- [eureka-server] [hresholdUpdater] c.n.e.r.PeerAwareInstanceRegistryImpl    : Current renewal threshold is : 0
2024-12-26T20:41:50.230+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 4ms
2024-12-26T20:42:50.235+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 3ms
2024-12-26T20:45:52.923+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 0ms
2024-12-26T20:46:52.925+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 0ms
2024-12-26T20:55:48.564+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 5ms
2024-12-26T20:56:48.477+07:00  INFO 2032 --- [eureka-server] [hresholdUpdater] c.n.e.r.PeerAwareInstanceRegistryImpl    : Current renewal threshold is : 0
2024-12-26T20:56:48.566+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 4ms
2024-12-26T20:57:48.571+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 4ms
2024-12-26T21:39:45.274+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 0ms
2024-12-26T21:40:45.277+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 4ms
2024-12-26T21:41:45.277+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 1ms
2024-12-27T00:43:59.168+07:00  INFO 2032 --- [eureka-server] [hresholdUpdater] c.n.e.r.PeerAwareInstanceRegistryImpl    : Current renewal threshold is : 0
2024-12-27T00:43:59.270+07:00  INFO 2032 --- [eureka-server] [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry  : Running the evict task with compensationTime 5ms

log peer2
Starting Gradle Daemon...
Gradle Daemon started in 892 ms
> Task :eureka-discovery-service:compileJava UP-TO-DATE
> Task :eureka-discovery-service:processResources
> Task :eureka-discovery-service:classes

> Task :eureka-discovery-service:LoadBalancerServiceApplication.main()
  _____                         __ ______         __
 |_   _|                       |  ]_   _ \       [  |
   | |      .--.   ,--.    .--.| |  | |_) | ,--.  | | ,--.  _ .--.   .---. .---.  _ .--.
   | |   _/ .'`\ \`'_\ : / /'`\' |  |  __'.`'_\ : | |`'_\ :[ `.-. | / /'`\] /__\\[ `/'`\]
  _| |__/ | \__. |// | |,| \__/  | _| |__) // | |,| |// | |,| | | | | \__.| \__., | |
 |________|'.__.' \'-;__/ '.__.;__]_______/\'-;__[___]'-;__[___||__]'.___.''.__.'[___]

Powered by Spring Boot 3.3.6
2024-12-26T20:15:59.721+07:00  INFO 2127 --- [eureka-server] [  restartedMain] i.mvi.lb.LoadBalancerServiceApplication  : Starting LoadBalancerServiceApplication using Java 17.0.12 with PID 2127 (/Users/widiyanto./Documents/Work/Microservices/eureka-discovery-service/build/classes/java/main started by widiyanto. in /Users/widiyanto./Documents/Work/Microservices/main-service)
2024-12-26T20:15:59.723+07:00  INFO 2127 --- [eureka-server] [  restartedMain] i.mvi.lb.LoadBalancerServiceApplication  : The following 1 profile is active: "peer2"
2024-12-26T20:15:59.753+07:00  INFO 2127 --- [eureka-server] [  restartedMain] .e.DevToolsPropertyDefaultsPostProcessor : Devtools property defaults active! Set 'spring.devtools.add-properties' to 'false' to disable
2024-12-26T20:15:59.753+07:00  INFO 2127 --- [eureka-server] [  restartedMain] .e.DevToolsPropertyDefaultsPostProcessor : For additional web related logging consider setting the 'logging.level.web' property to 'DEBUG'
2024-12-26T20:16:00.369+07:00  INFO 2127 --- [eureka-server] [  restartedMain] o.s.cloud.context.scope.GenericScope     : BeanFactory id=fe1e9c0c-65d8-3a60-9dcf-0b96a7515b22
2024-12-26T20:16:00.408+07:00  WARN 2127 --- [eureka-server] [  restartedMain] trationDelegate$BeanPostProcessorChecker : Bean 'org.springframework.cloud.client.loadbalancer.LoadBalancerAutoConfiguration$DeferringLoadBalancerInterceptorConfig' of type [org.springframework.cloud.client.loadbalancer.LoadBalancerAutoConfiguration$DeferringLoadBalancerInterceptorConfig] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying). The currently created BeanPostProcessor [lbRestClientPostProcessor] is declared through a non-static factory method on that class; consider declaring it as static instead.
2024-12-26T20:16:00.411+07:00  WARN 2127 --- [eureka-server] [  restartedMain] trationDelegate$BeanPostProcessorChecker : Bean 'deferringLoadBalancerInterceptor' of type [org.springframework.cloud.client.loadbalancer.DeferringLoadBalancerInterceptor] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying). Is this bean getting eagerly injected/applied to a currently created BeanPostProcessor [lbRestClientPostProcessor]? Check the corresponding BeanPostProcessor declaration and its dependencies/advisors. If this bean does not have to be post-processed, declare it with ROLE_INFRASTRUCTURE.
2024-12-26T20:16:00.842+07:00  INFO 2127 --- [eureka-server] [  restartedMain] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat initialized with port 8763 (http)
2024-12-26T20:16:00.858+07:00  INFO 2127 --- [eureka-server] [  restartedMain] o.apache.catalina.core.StandardService   : Starting service [Tomcat]
2024-12-26T20:16:00.858+07:00  INFO 2127 --- [eureka-server] [  restartedMain] o.apache.catalina.core.StandardEngine    : Starting Servlet engine: [Apache Tomcat/10.1.33]
2024-12-26T20:16:00.927+07:00  INFO 2127 --- [eureka-server] [  restartedMain] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring embedded WebApplicationContext
2024-12-26T20:16:00.929+07:00  INFO 2127 --- [eureka-server] [  restartedMain] w.s.c.ServletWebServerApplicationContext : Root WebApplicationContext: initialization completed in 1174 ms
2024-12-26T20:16:02.001+07:00  INFO 2127 --- [eureka-server] [  restartedMain] c.n.d.provider.DiscoveryJerseyProvider   : Using JSON encoding codec LegacyJacksonJson
2024-12-26T20:16:02.003+07:00  INFO 2127 --- [eureka-server] [  restartedMain] c.n.d.provider.DiscoveryJerseyProvider   : Using JSON decoding codec LegacyJacksonJson
2024-12-26T20:16:02.225+07:00  INFO 2127 --- [eureka-server] [  restartedMain] c.n.d.provider.DiscoveryJerseyProvider   : Using XML encoding codec XStreamXml
2024-12-26T20:16:02.226+07:00  INFO 2127 --- [eureka-server] [  restartedMain] c.n.d.provider.DiscoveryJerseyProvider   : Using XML decoding codec XStreamXml
2024-12-26T20:16:02.706+07:00  WARN 2127 --- [eureka-server] [  restartedMain] o.s.b.d.a.OptionalLiveReloadServer       : Unable to start LiveReload server
2024-12-26T20:16:02.740+07:00  WARN 2127 --- [eureka-server] [  restartedMain] iguration$LoadBalancerCaffeineWarnLogger : Spring Cloud LoadBalancer is currently working with the default cache. While this cache implementation is useful for development and tests, it's recommended to use Caffeine cache in production.You can switch to using Caffeine cache, by adding it and org.springframework.cache.caffeine.CaffeineCacheManager to the classpath.
2024-12-26T20:16:02.749+07:00  INFO 2127 --- [eureka-server] [  restartedMain] o.s.c.n.eureka.InstanceInfoFactory       : Setting initial instance status as: STARTING
2024-12-26T20:16:02.761+07:00  INFO 2127 --- [eureka-server] [  restartedMain] com.netflix.discovery.DiscoveryClient    : Initializing Eureka in region us-east-1
2024-12-26T20:16:02.761+07:00  INFO 2127 --- [eureka-server] [  restartedMain] com.netflix.discovery.DiscoveryClient    : Client configured to neither register nor query for data.
2024-12-26T20:16:02.762+07:00  INFO 2127 --- [eureka-server] [  restartedMain] com.netflix.discovery.DiscoveryClient    : Discovery Client initialized at timestamp<PHONE_NUMBER>761 with initial instances count: 0
2024-12-26T20:16:02.784+07:00  INFO 2127 --- [eureka-server] [  restartedMain] c.n.eureka.DefaultEurekaServerContext    : Initializing ...
2024-12-26T20:16:02.785+07:00  INFO 2127 --- [eureka-server] [  restartedMain] c.n.eureka.cluster.PeerEurekaNodes       : Adding new peer nodes [http://my-eureka-server.com:8762/eureka/]
2024-12-26T20:16:02.872+07:00  INFO 2127 --- [eureka-server] [  restartedMain] c.n.d.provider.DiscoveryJerseyProvider   : Using JSON encoding codec LegacyJacksonJson
2024-12-26T20:16:02.872+07:00  INFO 2127 --- [eureka-server] [  restartedMain] c.n.d.provider.DiscoveryJerseyProvider   : Using JSON decoding codec LegacyJacksonJson
2024-12-26T20:16:02.872+07:00  INFO 2127 --- [eureka-server] [  restartedMain] c.n.d.provider.DiscoveryJerseyProvider   : Using XML encoding codec XStreamXml
2024-12-26T20:16:02.872+07:00  INFO 2127 --- [eureka-server] [  restartedMain] c.n.d.provider.DiscoveryJerseyProvider   : Using XML decoding codec XStreamXml
2024-12-26T20:16:02.894+07:00  INFO 2127 --- [eureka-server] [  restartedMain] c.n.eureka.cluster.PeerEurekaNodes       : Replica node URL:  http://my-eureka-server.com:8762/eureka/
2024-12-26T20:16:02.899+07:00  INFO 2127 --- [eureka-server] [  restartedMain] c.n.e.registry.AbstractInstanceRegistry  : Finished initializing remote region registries. All known remote regions: []
2024-12-26T20:16:02.899+07:00  INFO 2127 --- [eureka-server] [  restartedMain] c.n.eureka.DefaultEurekaServerContext    : Initialized
2024-12-26T20:16:02.905+07:00  INFO 2127 --- [eureka-server] [  restartedMain] o.s.b.a.e.web.EndpointLinksResolver      : Exposing 1 endpoint beneath base path '/actuator'
2024-12-26T20:16:02.934+07:00  INFO 2127 --- [eureka-server] [  restartedMain] o.s.c.n.e.s.EurekaServiceRegistry        : Registering application EUREKA-INSTANCE with eureka with status UP
2024-12-26T20:16:02.938+07:00  INFO 2127 --- [eureka-server] [  restartedMain] o.s.c.n.e.s.EurekaServiceRegistry        : Unregistering application EUREKA-INSTANCE with eureka with status DOWN
2024-12-26T20:16:02.939+07:00  WARN 2127 --- [eureka-server] [  restartedMain] ConfigServletWebServerApplicationContext : Exception encountered during context initialization - cancelling refresh attempt: org.springframework.context.ApplicationContextException: Failed to start bean 'webServerStartStop'
2024-12-26T20:16:02.939+07:00  INFO 2127 --- [eureka-server] [  restartedMain] c.n.eureka.DefaultEurekaServerContext    : Shutting down ...
2024-12-26T20:16:02.941+07:00  INFO 2127 --- [eureka-server] [  restartedMain] c.n.eureka.DefaultEurekaServerContext    : Shut down
2024-12-26T20:16:02.940+07:00 ERROR 2127 --- [eureka-server] [t-Conn-Cleaner2] c.n.d.s.t.j.EurekaJersey3ClientImpl      : Cannot clean connections

java.lang.IllegalStateException: Client instance has been closed.
	at org.glassfish.jersey.internal.guava.Preconditions.checkState(Preconditions.java:169) ~[jersey-common-3.1.9.jar:na]
	at org.glassfish.jersey.client.JerseyClient.checkNotClosed(JerseyClient.java:248) ~[jersey-client-3.1.9.jar:na]
	at org.glassfish.jersey.client.JerseyClient.getConfiguration(JerseyClient.java:363) ~[jersey-client-3.1.9.jar:na]
	at org.glassfish.jersey.client.JerseyClient.getConfiguration(JerseyClient.java:54) ~[jersey-client-3.1.9.jar:na]
	at com.netflix.discovery.shared.transport.jersey3.EurekaJersey3ClientImpl$ConnectionCleanerTask.run(EurekaJersey3ClientImpl.java:338) ~[eureka-client-jersey3-2.0.3.jar:2.0.3]
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[na:na]
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[na:na]
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[na:na]
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[na:na]
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[na:na]
	at java.base/java.lang.Thread.run(Thread.java:840) ~[na:na]

2024-12-26T20:16:02.942+07:00  INFO 2127 --- [eureka-server] [      Thread-13] o.s.c.n.e.server.EurekaServerBootstrap   : isAws returned false
2024-12-26T20:16:02.942+07:00  INFO 2127 --- [eureka-server] [      Thread-13] o.s.c.n.e.server.EurekaServerBootstrap   : Initialized server context
2024-12-26T20:16:02.942+07:00  INFO 2127 --- [eureka-server] [      Thread-13] c.n.e.r.PeerAwareInstanceRegistryImpl    : Got 1 instances from neighboring DS node
2024-12-26T20:16:02.942+07:00  INFO 2127 --- [eureka-server] [      Thread-13] c.n.e.r.PeerAwareInstanceRegistryImpl    : Renew threshold is: 1
2024-12-26T20:16:02.942+07:00  INFO 2127 --- [eureka-server] [      Thread-13] c.n.e.r.PeerAwareInstanceRegistryImpl    : Changing status to UP
2024-12-26T20:16:02.942+07:00 ERROR 2127 --- [eureka-server] [      Thread-13] o.s.c.n.e.server.EurekaServerBootstrap   : Cannot bootstrap eureka server :

java.lang.IllegalStateException: Timer already cancelled.
	at java.base/java.util.Timer.sched(Timer.java:409) ~[na:na]
	at java.base/java.util.Timer.schedule(Timer.java:260) ~[na:na]
	at com.netflix.eureka.registry.AbstractInstanceRegistry.postInit(AbstractInstanceRegistry.java:1226) ~[eureka-core-2.0.3.jar:2.0.3]
	at com.netflix.eureka.registry.PeerAwareInstanceRegistryImpl.openForTraffic(PeerAwareInstanceRegistryImpl.java:259) ~[eureka-core-2.0.3.jar:2.0.3]
	at org.springframework.cloud.netflix.eureka.server.InstanceRegistry.openForTraffic(InstanceRegistry.java:77) ~[spring-cloud-netflix-eureka-server-4.1.3.jar:4.1.3]
	at org.springframework.cloud.netflix.eureka.server.EurekaServerBootstrap.initEurekaServerContext(EurekaServerBootstrap.java:112) ~[spring-cloud-netflix-eureka-server-4.1.3.jar:4.1.3]
	at org.springframework.cloud.netflix.eureka.server.EurekaServerBootstrap.contextInitialized(EurekaServerBootstrap.java:70) ~[spring-cloud-netflix-eureka-server-4.1.3.jar:4.1.3]
	at org.springframework.cloud.netflix.eureka.server.EurekaServerInitializerConfiguration.lambda$start$0(EurekaServerInitializerConfiguration.java:67) ~[spring-cloud-netflix-eureka-server-4.1.3.jar:4.1.3]
	at java.base/java.lang.Thread.run(Thread.java:840) ~[na:na]

2024-12-26T20:16:02.943+07:00 ERROR 2127 --- [eureka-server] [      Thread-13] e.s.EurekaServerInitializerConfiguration : Could not initialize Eureka servlet context

java.lang.RuntimeException: Cannot bootstrap eureka server :
	at org.springframework.cloud.netflix.eureka.server.EurekaServerBootstrap.contextInitialized(EurekaServerBootstrap.java:76) ~[spring-cloud-netflix-eureka-server-4.1.3.jar:4.1.3]
	at org.springframework.cloud.netflix.eureka.server.EurekaServerInitializerConfiguration.lambda$start$0(EurekaServerInitializerConfiguration.java:67) ~[spring-cloud-netflix-eureka-server-4.1.3.jar:4.1.3]
	at java.base/java.lang.Thread.run(Thread.java:840) ~[na:na]
Caused by: java.lang.IllegalStateException: Timer already cancelled.
	at java.base/java.util.Timer.sched(Timer.java:409) ~[na:na]
	at java.base/java.util.Timer.schedule(Timer.java:260) ~[na:na]
	at com.netflix.eureka.registry.AbstractInstanceRegistry.postInit(AbstractInstanceRegistry.java:1226) ~[eureka-core-2.0.3.jar:2.0.3]
	at com.netflix.eureka.registry.PeerAwareInstanceRegistryImpl.openForTraffic(PeerAwareInstanceRegistryImpl.java:259) ~[eureka-core-2.0.3.jar:2.0.3]
	at org.springframework.cloud.netflix.eureka.server.InstanceRegistry.openForTraffic(InstanceRegistry.java:77) ~[spring-cloud-netflix-eureka-server-4.1.3.jar:4.1.3]
	at org.springframework.cloud.netflix.eureka.server.EurekaServerBootstrap.initEurekaServerContext(EurekaServerBootstrap.java:112) ~[spring-cloud-netflix-eureka-server-4.1.3.jar:4.1.3]
	at org.springframework.cloud.netflix.eureka.server.EurekaServerBootstrap.contextInitialized(EurekaServerBootstrap.java:70) ~[spring-cloud-netflix-eureka-server-4.1.3.jar:4.1.3]
	... 2 common frames omitted

2024-12-26T20:16:02.945+07:00  INFO 2127 --- [eureka-server] [  restartedMain] com.netflix.discovery.DiscoveryClient    : Shutting down DiscoveryClient ...
2024-12-26T20:16:02.945+07:00  INFO 2127 --- [eureka-server] [  restartedMain] com.netflix.discovery.DiscoveryClient    : Completed shut down of DiscoveryClient
2024-12-26T20:16:02.978+07:00  INFO 2127 --- [eureka-server] [  restartedMain] .s.b.a.l.ConditionEvaluationReportLogger :

Error starting ApplicationContext. To display the condition evaluation report re-run your application with 'debug' enabled.
2024-12-26T20:16:02.991+07:00 ERROR 2127 --- [eureka-server] [  restartedMain] o.s.b.d.LoggingFailureAnalysisReporter   :

***************************
APPLICATION FAILED TO START
***************************

Description:

Web server failed to start. Port 8763 was already in use.

Action:

Identify and stop the process that's listening on port 8763 or configure this application to listen on another port.

Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

For more on this, please refer to https://docs.gradle.org/8.10.2/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation.

BUILD SUCCESSFUL in 9s
3 actionable tasks: 2 executed, 1 up-to-date
20.16.03: Execution finished ':eureka-discovery-service:LoadBalancerServiceApplication.main()'.

just comment this library
//implementation 'org.springframework.boot:spring-boot-devtools'


CORS error when using rasa-webchat to connect to botfront-API

Describe the bug
when connecting to API from remote client (rasa-webchat) I get CORS error
Access to XMLHttpRequest at 'http://<IP_ADDRESS>:8080/socket.io/?EIO=3&transport=polling&t=N4ICe2D' from origin 'http://localhost:8082' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

To Reproduce
Steps to reproduce the behavior:

Add the following code to a html page (found on this page https://github.com/botfront/rasa-webchat)

<div id="webchat"/>
<script src="https://storage.googleapis.com/mrbot-cdn/webchat-latest.js"></script>
// Or you can replace latest with a specific version
<script>
  WebChat.default.init({
    selector: "#webchat",
    initPayload: "/get_started",
    customData: {"language": "en"}, // arbitrary custom data. Stay minimal as this will be added to the socket
    socketUrl: "http://localhost:5500",
    socketPath: "/socket.io/",
    title: "Title",
    subtitle: "Subtitle",
  })
</script>

Load the page into a browser

Expected behavior
Working chatbot client
Desktop (please complete the following information):

OS: [e.g. MacOS Client, CentOS server]
Browser Chrome

I was using the wrong port. It should have been 5005.
I also edited .botfront/docker-compose-template.yml
and changed
rasa:
    build:
      context: ./rasa
      args:
        RASA_IMAGE: ${IMAGES_CURRENT_RASA}
    container_name: botfront-rasa
    networks: ["botfront-network"]
    restart: always
    ports:
      - 5005:5005
    volumes:
      - ./models/:/app/models
    env_file:
      - .env

  actions:
    build:
      context: ./actions
      args:
        RASA_SDK_IMAGE: ${IMAGES_CURRENT_ACTIONS}
    container_name: botfront-actions
    networks: ["botfront-network"]
    restart: always
    ports:
      - "5055:5055"
    volumes:
      - "./actions:/app/actions"
    command:
      - start
      - --debug
      - --actions
      - actions
    env_file:
      - .env

to
rasa:
    build:
      context: ./rasa
      args:
        RASA_IMAGE: ${IMAGES_CURRENT_RASA}
    container_name: botfront-rasa
    networks: ["botfront-network"]
    restart: always
    ports:
      - 5005:5005
    volumes:
      - ./models/:/app/models
    env_file:
      - .env

  actions:
    build:
      context: ./actions
      args:
        RASA_SDK_IMAGE: ${IMAGES_CURRENT_ACTIONS}
    container_name: botfront-actions
    networks: ["botfront-network"]
    restart: always
    ports:
      - "5055:5055"
    volumes:
      - "./actions:/app/actions"
    command:
      - start
      - --debug
      - --actions
      - actions
      - --cors
      - "*"
    env_file:
      - .env

notice the lines I added were
 - --cors
      - "*"


Infra Fixes to DLM for Onnxrt Wheel + Int8

Several pieces being reviewed/added to DLM to fix issue we're seeing in CI and run between QA and Dev

Currently tracking down issues I've found in 6.0 builds through DLM

off the wheel files we're running into the following failure in the Unit tests. These were separated out  via: https://github.com/ROCmSoftwarePlatform/DeepLearningModels/pull/1098

Seeing a lot of failures come up with EinSum with MIOpen calls
Currently working on 1 and doing a raw build without wheel to determine if there's something on 6.0 that isn't built in correctly. Seems to effect the int8 quant set of changes as well when running test through DLM.

Failure with migx_ort_bert_distilled_benchmarks - Related to failing test from upstream parameter added to eval_squad.py causing timeouts in CI - Solved by : https://github.com/ROCmSoftwarePlatform/DeepLearningModels/pull/1097

Fix to path name. https://ontrack-internal.amd.com/browse/SWDEV-434010 . Fixed and in review with: https://github.com/ROCmSoftwarePlatform/DeepLearningModels/pull/1100

Looks like the result is the following after letting it fail:
[  FAILED  ] 135 tests, listed below:
[  FAILED  ] Einsum.ExplicitEinsumAsBatchedMatmulWithBroadcasting_1
[  FAILED  ] Einsum.ExplicitEinsumAsBatchedDiagonalOp_1
[  FAILED  ] Einsum.ImplicitEinsumAsBatchedDiagonalOp_1
[  FAILED  ] Einsum.EinsumTransposeMatMulTwoInputsTestSuite
[  FAILED  ] Einsum.EinsumTransposeMatMulThreeInputsTestSuite
[  FAILED  ] SoftmaxOperator.GH15949_regression_test
[  FAILED  ] PoolTest.GlobalMaxPool
[  FAILED  ] PoolTest.GlobalMaxPool3D
[  FAILED  ] PoolTest.GlobalAveragePool
[  FAILED  ] PoolTest.GlobalAveragePool_Large_128
[  FAILED  ] PoolTest.GlobalAveragePool_Large_256
[  FAILED  ] ReductionOpTest.ReductionVariationTest
[  FAILED  ] ReductionOpTest.ReduceL1_default_axes_keepdims
[  FAILED  ] ReductionOpTest.ReduceL1_do_not_keep_dims
[  FAILED  ] ReductionOpTest.ReduceL1_do_not_keep_dims_2
[  FAILED  ] ReductionOpTest.ReduceL1_keepdims
[  FAILED  ] ReductionOpTest.ReduceL1
[  FAILED  ] ReductionOpTest.ReduceL1_int32
[  FAILED  ] ReductionOpTest.ReduceL2_default_axes_keepdims
[  FAILED  ] ReductionOpTest.ReduceL2_default_axes_do_not_keep_dims
[  FAILED  ] ReductionOpTest.ReduceL2_do_not_keepdims
[  FAILED  ] ReductionOpTest.ReduceL2_do_not_keepdims_2
[  FAILED  ] ReductionOpTest.ReduceL2_keepdims
[  FAILED  ] ReductionOpTest.ReduceL2
[  FAILED  ] ReductionOpTest.ReduceL2_int32
[  FAILED  ] ReductionOpTest.ReduceLogSum
[  FAILED  ] ReductionOpTest.ReduceLogSumExp_default_axes_keepdims
[  FAILED  ] ReductionOpTest.ReduceLogSumExp_default_axes_do_not_keep_dims
[  FAILED  ] ReductionOpTest.ReduceLogSumExp_do_not_keepdims
[  FAILED  ] ReductionOpTest.ReduceLogSumExp_do_not_keepdims_2
[  FAILED  ] ReductionOpTest.ReduceLogSumExp_keepdims
[  FAILED  ] ReductionOpTest.ReduceLogSumExp
[  FAILED  ] ReductionOpTest.ReduceLogSumExp_half
[  FAILED  ] ReductionOpTest.ReduceMax_default_axes_keepdims
[  FAILED  ] ReductionOpTest.ReduceMax_default_axes_do_not_keep_dims
[  FAILED  ] ReductionOpTest.ReduceMax_do_not_keepdims
[  FAILED  ] ReductionOpTest.ReduceMax_do_not_keepdims_2
[  FAILED  ] ReductionOpTest.ReduceMax_keepdims
[  FAILED  ] ReductionOpTest.ReduceMax
[  FAILED  ] ReductionOpTest.ReduceMax_half
[  FAILED  ] ReductionOpTest.ReduceMax_int32
[  FAILED  ] ReductionOpTest.ReduceMax_int64
[  FAILED  ] ReductionOpTest.ReduceMax_int8
[  FAILED  ] ReductionOpTest.ReduceMax_uint8
[  FAILED  ] ReductionOpTest.ReduceMean_do_not_keepdims
[  FAILED  ] ReductionOpTest.ReduceMean_keepdims
[  FAILED  ] ReductionOpTest.ReduceMean
[  FAILED  ] ReductionOpTest.ReduceMean_int32
[  FAILED  ] ReductionOpTest.ReduceMin_default_axes_keepdims
[  FAILED  ] ReductionOpTest.ReduceMin_default_axes_do_not_keep_dims
[  FAILED  ] ReductionOpTest.ReduceMin_default_axes_do_not_keep_dims_2D
[  FAILED  ] ReductionOpTest.ReduceMin_do_not_keepdims
[  FAILED  ] ReductionOpTest.ReduceMin_do_not_keepdims_2
[  FAILED  ] ReductionOpTest.ReduceMin_keepdims
[  FAILED  ] ReductionOpTest.ReduceMin
[  FAILED  ] ReductionOpTest.ReduceMin_half
[  FAILED  ] ReductionOpTest.ReduceMin_int32
[  FAILED  ] ReductionOpTest.ReduceMin_int8
[  FAILED  ] ReductionOpTest.ReduceMin_uint8
[  FAILED  ] ReductionOpTest.ReduceSum
[  FAILED  ] ReductionOpTest.ReduceSumAxesInitializerOpset13
[  FAILED  ] ReductionOpTest.ReduceSum_axes02
[  FAILED  ] ReductionOpTest.ReduceSum_int32
[  FAILED  ] ReductionOpTest.ReduceSumHalfHalf_2
[  FAILED  ] ReductionOpTest.ReduceSumBFloat16_2
[  FAILED  ] ReductionOpTest.ReduceSum_int64
[  FAILED  ] ReductionOpTest.ReduceSum_keepdims
[  FAILED  ] ReductionOpTest.ReduceSum_int32_axes_input
[  FAILED  ] ReductionOpTest.ReduceSumSquare
[  FAILED  ] ReductionOpTest.ReduceSumSquare_do_not_keepdims
[  FAILED  ] ReductionOpTest.ReduceSumSquare_keepdims
[  FAILED  ] ReductionOpTest.ReduceProd_default_axes_keepdims
[  FAILED  ] ReductionOpTest.ReduceProd_default_axes_do_not_keep_dims
[  FAILED  ] ReductionOpTest.ReduceProd_do_not_keepdims
[  FAILED  ] ReductionOpTest.ReduceProd_do_not_keepdims_2
[  FAILED  ] ReductionOpTest.ReduceProd_keepdims
[  FAILED  ] ReductionOpTest.ReduceProd
[  FAILED  ] ReductionOpTest.ReduceProd_int32
[  FAILED  ] ReductionOpTest.ArgMax
[  FAILED  ] ReductionOpTest.ArgMax_do_not_keepdims
[  FAILED  ] ReductionOpTest.ArgMax_do_not_keepdims_2
[  FAILED  ] ReductionOpTest.ArgMax2D
[  FAILED  ] ReductionOpTest.ArgMin
[  FAILED  ] ReductionOpTest.ArgMin_do_not_keepdims
[  FAILED  ] ReductionOpTest.ArgMin_do_not_keepdims_2
[  FAILED  ] ReductionOpTest.ReduceInfMax
[  FAILED  ] ReductionOpTest.ReduceInfMin
[  FAILED  ] ReductionOpTest.ReduceInfLogSumExp
[  FAILED  ] ReductionOpTest.ReduceMax_KR_parallel
[  FAILED  ] ReductionOpTest.ReduceMax_KR
[  FAILED  ] ReductionOpTest.ReduceMax_KR_keepdims
[  FAILED  ] ReductionOpTest.ReduceMax_RK
[  FAILED  ] ReductionOpTest.ReduceMax_RK_keepdims
[  FAILED  ] ReductionOpTest.ReduceMax_RK_parallel
[  FAILED  ] ReductionOpTest.ReduceMax_KRK
[  FAILED  ] ReductionOpTest.ReduceMax_KRK_keepdims
[  FAILED  ] ReductionOpTest.ReduceMax_RKR
[  FAILED  ] ReductionOpTest.ReduceMax_RKR_parallel
[  FAILED  ] ReductionOpTest.ReduceMax_RKR_keepdims
[  FAILED  ] ReductionOpTest.ReduceMax_RKRK
[  FAILED  ] ReductionOpTest.ReduceMax_RKRK_keepdims
[  FAILED  ] ReductionOpTest.ReduceMean_KRK
[  FAILED  ] ReductionOpTest.ReduceMean_KRK_keepdims
[  FAILED  ] ReductionOpTest.ReduceMean_RKR
[  FAILED  ] ReductionOpTest.ReduceMean_RKR_parallel
[  FAILED  ] ReductionOpTest.ReduceMean_RKR_keepdims
[  FAILED  ] ReductionOpTest.ReduceMean_RKRK
[  FAILED  ] ReductionOpTest.ReduceMean_RKRK_keepdims
[  FAILED  ] ReductionOpTest.ReduceMin_KR
[  FAILED  ] ReductionOpTest.ReduceMin_KR_parallel
[  FAILED  ] ReductionOpTest.ReduceMin_KR_keepdims
[  FAILED  ] ReductionOpTest.ReduceMin_RK
[  FAILED  ] ReductionOpTest.ReduceMin_RK_parallel
[  FAILED  ] ReductionOpTest.ReduceMin_RK_keepdims
[  FAILED  ] ReductionOpTest.ReduceMin_KRK
[  FAILED  ] ReductionOpTest.ReduceMin_KRK_keepdims
[  FAILED  ] ReductionOpTest.ReduceMin_RKR
[  FAILED  ] ReductionOpTest.ReduceMin_RKR_parallel
[  FAILED  ] ReductionOpTest.ReduceMin_RKR_keepdims
[  FAILED  ] ReductionOpTest.ReduceMin_RKRK
[  FAILED  ] ReductionOpTest.ReduceMin_RKRK_keepdims
[  FAILED  ] ReductionOpTest.ReduceSum_KRK
[  FAILED  ] ReductionOpTest.ReduceSum_KRK_parallel
[  FAILED  ] ReductionOpTest.ReduceSum_KRK_keepdims
[  FAILED  ] ReductionOpTest.ReduceSum_KRK2
[  FAILED  ] ReductionOpTest.ReduceSum_KRK2_keepdims
[  FAILED  ] ReductionOpTest.ReduceSum_RKR
[  FAILED  ] ReductionOpTest.ReduceSum_RKR_parallel
[  FAILED  ] ReductionOpTest.ReduceSum_RKR_parallel_bigger
[  FAILED  ] ReductionOpTest.ReduceSum_RKR_keepdims
[  FAILED  ] ReductionOpTest.ReduceSum_RKR2
[  FAILED  ] ReductionOpTest.ReduceSum_RKR2_keepdims
[  FAILED  ] ReductionOpTest.ReduceSum_RKRK
[  FAILED  ] ReductionOpTest.ReduceSum_RKRK_keepdims
[  FAILED  ] Scatter.InvalidIndex

135 FAILED TESTS

This is still open. Other items need to be completed and are still in review

Still need to sort out issue with int8 failing and what the UTs added into DLM for onnxrt are picking up with rocm.
I've rolled back builds and wheel as far as -05 and seeing the same behavior with the failing call and tests.

GELU tests are failing consistently for fp16 and always failing at the end of the run. Not sure if related to the other issues we're seeing with the int8 quant side as well.
2023-11-25 01:41:12.673824527 [V:onnxruntime:, sequential_executor.cc:534 ExecuteThePlan] Number of streams: 1
2023-11-25 01:41:12.673833077 [V:onnxruntime:, sequential_executor.cc:184 SessionScope] Begin execution
2023-11-25 01:41:12.673884857 [V:onnxruntime:, sequential_executor.cc:518 ExecuteKernel] stream 0 launch kernel with idx 5
Output 0, diff=0.021484375 index=(0, 0, 360) ort=2.603515625 torch=2.625000000
[FAILED] Passed_cases=0/100; Max_diff=0.021484375; Diff_count=100
F

https://github.com/ROCmSoftwarePlatform/DeepLearningModels/pull/1101 fixes issue with DLM conv_to_onnx as well.

https://github.com/ROCmSoftwarePlatform/onnxruntime/pull/25 Fixes issues seen with our GELU test failing. This is due to how we invoke fast_math on fp16 but seem to lose accuracy on our Navi based cards to cause such a failure.
Defaulting this to false and adding the proper env vars to toggle this as part of our runs.

Blocked to closing this out until we get RC5 fixes to hip to test on.


Make sure window and navigator get called when needed.

This PR contains a:

[x] bugfix
[ ] new feature
[ ] code refactor
[ ] test update
[ ] typo fix
[ ] metadata update

Motivation / Use-Case
When using this library with SSR (such as in Angular or Next.js), calling the constructor results in an exception like:
window is not defined or navigator is not defined.
This bugfix makes sure we only reference window or navigator when needed. This is a workaround and does not make the library work in SSR, rather if you avoid creating an instance of NoSleep in the server, you'll be fine.
Additional Info
Reference issue: https://github.com/richtr/NoSleep.js/issues/96#issue-629321014

what needs to be done to get this in?

Hello nice project, and nice PR
The same question, is this PR get merge soon?
I am running into this issue with TradingViewCharting library (it's doesn't support the SSR) on the nextjs
The current workaround is import TradingViewChart Component in next/dynamic.
But if put the "nosleep.js" into a custom hook or react context, it's throw error.


Simple website explaining latexjs

Can be hosted with GitHub Pages.

More important to get a README up and running first.


Hand Pose pickle files

The hand pose pickle files are not available for all the images.
Will it be made available?
Do you have a list of images for which the pickle files are available?

Hi, anjugopinath:
Annotations for videos in our evaluation set are not publicly available at this moment. We will upload them as soon as they are public.


Can we built a bot for Skpe for Business?

Is it possible to integrate the bot for Skype for Business?

Thank you for the suggestion. This is on our backlog of channeles to suport.

@hailiu2586 - Status on this channel?


[Webfail] Extract timestamp from element

Timestamps are only available with the german version for Facebook fails.

Hi, @KN4CK3R ! Timestamps does not seem to appear:
https://feed.eugenemolotov.ru/pr1852/?action=display&bridge=Webfail&context=By+content+type&language=en&type=%2F&format=Html

Timestamps are only available with the german version for Facebook fails.
https://feed.eugenemolotov.ru/pr1852/?action=display&bridge=Webfail&context=By+content+type&language=de&type=%2Fffdts&format=Html

Is PR still good?

Well I got this to work for language german.


cancelPerformSelector... written wrong

Dear WinObjC Engineers,
In NSRunLoop.mm:

(void)cancelPerformSelector:(const char*)selector target:(NSObject*)target argument:(NSObject*)argument {

is written wrong.
Sincerely,
Ed

Wow, we're still treating selectors as character strings? That'll never work.
(that is the complaint here, right? it looks like it should work otherwise.)

@DHowett-MSFT

The signature does not use SEL (you are right)

The API does not appear in the header file (thus unsuspectingly overwriting what should be the published API with a private implementation that is not right.

The implementation does not use a mark and sweep, thus the O(computation) is inefficient (although it probably does not matter too much).

Would be a good opportunity to fix issues 1 and 2.  We can change the linear scan to some kind of map if it really turns out to be a performance issue.

Closed with #2121


Repeated "HTTP2 has been explicitly disabled" log statements in the rancher logs

What kind of request is this (question/bug/enhancement/feature request): bug
Steps to reproduce (least amount of steps as possible):

Deploy a cluster in the latest master.
Rancher logs show repeated log statements

I0910 22:26:13.125428   22 http.go:116] HTTP2 has been explicitly disabled
I0910 22:26:13.125710   22 http.go:116] HTTP2 has been explicitly disabled
I0910 22:26:13.125721   22 http.go:116] HTTP2 has been explicitly disabled
I0910 22:26:28.125588   22 http.go:116] HTTP2 has been explicitly disabled
I0910 22:26:28.126647   22 http.go:116] HTTP2 has been explicitly disabled
I0910 22:26:28.127171   22 http.go:116] HTTP2 has been explicitly disabled
I0910 22:26:43.125688   22 http.go:116] HTTP2 has been explicitly disabled
I0910 22:26:43.126727   22 http.go:116] HTTP2 has been explicitly disabled
I0910 22:26:43.127235   22 http.go:116] HTTP2 has been explicitly disabled
I0910 22:26:58.125517   22 http.go:116] HTTP2 has been explicitly disabled
I0910 22:26:58.126350   22 http.go:116] HTTP2 has been explicitly disabled

Other details that may be helpful:
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI): master-head - commit id : ab6598e5a
Installation option (single install/HA): HA

Cluster information

Cluster type (Hosted/Infrastructure Provider/Custom/Imported): custom
Kubernetes version (use kubectl version):

1.18

Disabled here: https://github.com/rancher/rancher/issues/26624

On master-head - commit id: 8fd81a9b

Rancher logs do NOT show these log statements anymore

HTTP2 has been explicitly disabled


[FEATURE]: Regex matcher from postgresql?

Feature hasn't been suggested before.

[X] I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request
~*
and
~
Would be nice if they have official support instead of using sql``

Closing in favor of https://github.com/drizzle-team/drizzle-orm/issues/2570.


After Upgrade from angular 17 to angular 18 the LOCALE_ID is always en_US

Which @angular/* package(s) are the source of the bug?
localize
Is this a regression?
Yes
Description
In an existing project distributed for several locales, we are determining the current locale by:
export class MyClass {
...
	constructor(@Inject(LOCALE_ID) locale: string) { }
}

Up to angular 17 the value of LOCALE_ID always reflected the locale defined in the i18n section of the project's setting in angular.json; with Angular 18 the locale is always en_US. This is the case for "ng serve" builds as well as for distribution builds.
Please provide a link to a minimal reproduction of the bug
No response
Please provide the exception or error you saw
No response
Please provide the environment you discovered this bug in (run ng version)
Angular CLI: 18.0.1
Node: 20.12.1
Package Manager: npm 10.5.0
OS: linux x64

Angular: 18.0.0
... animations, cdk, common, compiler, compiler-cli, core, forms
... localize, material, material-moment-adapter
... platform-browser, platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1800.1
@angular-devkit/build-angular   18.0.1
@angular-devkit/core            18.0.1
@angular-devkit/schematics      18.0.1
@angular/cli                    18.0.1
@schematics/angular             18.0.1
rxjs                            7.8.1
typescript                      5.4.5
zone.js                         0.14.6

Anything else?
No response

This seems like a bug but we'll need to look at a reproduction to find and fix the problem. Can you setup a minimal repro please?
You can read here why this is needed. A good way to make a minimal repro is to create a new app via ng new repro-app and adding the minimum possible code to show the problem. Then you can push this repository to github and link it here.
This might be related to your directory structure so its really important to get an accurate repro to diagnose this.

@alan-agius4 I am hitting the same issue.
I have tried to create a minimal repro from scratch.
https://github.com/michaelkrog/wrong-locale
I could only reproduce it if:

The app uses ngmodule
The app references a component in a library under another library.

Se https://github.com/angular/angular/issues/56182 for more details

The problem is because in the library import '@angular/localize/init' is imported directly in your case. @angular/localize/init should not be imported, instead it should be added as a polyfill.

@alan-agius4  🤥
You are totally right.
I forgot to rebuild the lib before serving the app again.
I can confirm that it works.

Sorry for the late response and thank you @michaelkrog for preparing the example and @alan-agius4 for the analysis.
The suggested way to include @angular/localize/init as polyfill solved the issue for me, too.


cmd/trace: Mininum mutator utilization plot window durations range is not consistent across Include options

What version of Go are you using (go version)?

$ go version
go version go1.13.4 linux/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/eg/.cache/go-build"
GOENV="/home/eg/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/eg/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/eg/go/src/bitbucket.org/triangleteam/resource-manager/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build569889623=/tmp/go-build -gno-record-gcc-switches"

What did you do?
I wrote a simple code to check built in golang tracing:
package main

import (
	"os"
	"runtime"
	"runtime/trace"
	"sync"
	"time"
)

func main() {
	f, err := os.Create("trace.out")
	if err != nil {
		panic(err)
	}

	trace.Start(f)
	defer func() {
		trace.Stop()
		_ = f.Close()
	}()

	wg := sync.WaitGroup{}

	for g := 0; g < runtime.NumCPU(); g++ {
		wg.Add(1)
		go func() {
			for i := 0; i < 40; i++ {
				bs := make([]byte, 1024*1024)
				for k := range bs {
					bs[k] = byte(k % 8)
				}
				time.Sleep(50 * time.Millisecond)
			}
			wg.Done()
		}()
	}

	wg.Wait()
}

After running this program and getting trace.out file as an output I do $ go tool trace trace.out, open http://<IP_ADDRESS>:32935/mmu in the browser and look at the plots with and without STW checkbox set.

What did you expect to see?
I expect that X-axis range (min and max Window duration for which MMU function is evaluated) is the same with STW set and not set.
What did you see instead?
I see that with STW checkbox set the window duration range is [1ms, ~10s], and when checkbox is unset range is [1ns, 1ms].

To conclude: if I get everything correctly, such behavior makes it harder to understand how GC affects the utilization. Should we make the window duration range consistent across any set of checked options? Or maybe we should make it possible for user to configure the range.

@aclements


[Bug] Archived build failed with other library used swift-collections

[x] I have read the documentation.
[x] I have read the limitations.
[x] I could not find my issue.

Describe the bug
When archiving the test app, the process works fine for the iOS app but results in a compiler error when archiving for Catalyst.
To Reproduce

Install dependencies swift-composable-architecture and MetaCodable
Archived app with Mac Catalyst
Compiler error

And here is a reproducible project
Expected behavior
Like archived iOS app, build/archived success
Screenshots

Environment (please complete the following information, remove ones not applicable):

OS: macos
Version 15.1
Xcode 16.1
Swift 5.10

Additional context

Seems more like a SwiftPM support with mac catalyst issue. Have you tried reaching out to SwiftPM for help?


No module named 'codes.threshold'

Modules like codes, Area and _8connected not found

I will see the problem in two days.
On Sat, Nov 10, 2018, 2:47 PM Md Arfinul Haque<EMAIL_ADDRESS>wrote:

Modules like codes, Area and _8connected not found
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/deepakrana47/Wheat-quality-detector-2/issues/1, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AKjDCzrzDiBGqr5k90qaErzS8keLw5hbks5utpnEgaJpZM4YX57F
.

@Arfinul the changes has been done you can test now.

Ghnta

can you provide the python file name on which you are getting the error

no module named threshold

try after pulling the git repo. As, at my end code is working just fine.

I'm getting an import error of threshold module while running cmd_wheat_quality_detector_v2.py

Okkayy sir, i will try now ....thanx a lot sir , lit of things learnt from
you
On Mon 12 Nov, 2018, 10:51 deepak singh rana<EMAIL_ADDRESS>wrote:

I have pushed the new code, you can test it now.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/deepakrana47/Wheat-quality-detector-2/issues/1#issuecomment-437759877,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AdZ2OvBrutKhBXvUIhu55Wk1qlCcU10hks5uuQVNgaJpZM4YX57F
.

Thank you for sharing all required modules to execute.
I have Python 2.7.15 installed on window 10
But can't install "tensorflow", as tensorflow doesn't support python2.7 on windows.
Tried to execute on Python3, after doing some change like printing format etc..
But getting error :

I will look into the problem and get back to you.
On Mon, Nov 12, 2018 at 6:11 PM Md Arfinul Haque<EMAIL_ADDRESS>wrote:

Thank you for sharing all required modules to execute.
I have Python 2.7.15 installed on window 10
But can't install "tensorflow", as tensorflow doesn't support python2.7 on
windows.
Tried to execute on Python3, after doing some change like printing format
etc..
But getting error :
[image: image]
https://user-images.githubusercontent.com/29590484/48348085-46b49700-e6a6-11e8-83df-9b13c359ab75.png
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/deepakrana47/Wheat-quality-detector-2/issues/1#issuecomment-437865251,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKjDC3QhIzeWCkzKiPdMP9RrUAXPNVsEks5uuWx1gaJpZM4YX57F
.

I think if I will generate "weights_30_30_.h5" model file, with the environment installed.
Then it will work.
But I am not able to file the module to generate this model file.
The same issue was there with "grain_feature.pkl", but i regenerated it and it worked.
Can you please share the python module generating this model file ("weights_30_30_.h5) ?

classifier_2_v5.py and classifier_2_v2.py are used for generation of weight_30_30_.h5 file

Thanks to reply.
But, which python file I should execute for generating "weight_30_30_.h5 file" ?

execute this file "classifier_2_v2.py"

I executed but this is creating .h5 file of the classifier.
But there is need of creating .h5 file of the segmentation data that will help in 2nd level segmentation.
How to create this file - segmentation_data/weights_30_30_.h5 ?

@Arfinul I had added the "Number_grain_detect.py" and dataset (segmentation_data/boundry_1_30.pkl and segmentation_data/boundry_2_30.pkl). This file is used for generating "segmentation_data/weights_30_30_.h5".
for level 2 segmentation you can go through my paper (https://www.ijeecse.com/V5N1-023.pdf).

"boundry_1_30.pkl" and "boundry_2_30.pkl" these two file i had already shared (present in segmentation_data/ ). The problem is arise due to opening python2.7 pickle file in python3.

Able to execute now.

if you are using this project some where please mention  this refrence also
"Rana, D.S., Segmentation of Overlapping Wheat Grains for Quality Detection"
On Wed, Nov 14, 2018 at 3:37 PM Md Arfinul Haque<EMAIL_ADDRESS>wrote:

Closed #1
https://github.com/deepakrana47/Wheat-quality-detector-2/issues/1.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/deepakrana47/Wheat-quality-detector-2/issues/1#event-1965418968,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKjDC0aqHfticKfrFSMgZ7eSjERxVfqYks5uu-tWgaJpZM4YX57F
.

For sure.
Will definitely add your paper as a reference, As your code and paper have participated in understanding the approach and is the latest too.
Having some research idea on this topic. Working on the same.
Will contact you for any suggestion.
Thank you


jsdom or babel-polyfill cause memory leak (?)

Hello.
First of all thanks for this project, it's been great so far. I'm running into a issue where when Jest can resolve babel-polyfill the node memory heap keeps on growing resulting in memory allocation errors in node 5 or extremely slow test in node 6 when node starts to reach the memory limit.
This very simple repository reproduce the issue https://github.com/quentin-/jest-test
describe('test', function() {
  beforeAll(function() {
    global.gc();
  });

  it('work', function() {
    expect(1).toBe(1);
  });
});

# heap size is trending upward.
# test become unbearably slow after a while
npm run test -- --logHeapUsage

node: 6.7.0

Even without babel-polyfill the memory footprint is trendy upward indefinitely (very slowly).

Some more specific data on the heap growth in the example repo, from running it on my machine.
npm install
npm run test -- --logHeapUsage

The heap size after the first test is 45MB and it grows linearly with a slope of 0.48.
rm -rf node_modules/babel-polyfill
npm run test -- --logHeapUsage

The heap size after the first test is 48MB and it grows linearly with a slope of 1.03.
Is that to be expected? This is 1MB growth on the heap for this test:
describe('test', function() {
  it('works', function() {
    expect(1).toBe(1);
  });
});

I've done a little research on this one, but not deep enough.
Indeed we seem to leak some memory here. But it's not because of babel-polyfill for sure (it just makes the heap grow faster, like @turadg noticed).
Tried to profile this with Chrome DevTools, but it didn't show timeline for Allocation Timelines and I didn't have too much time to wonder why.
node --expose-gc --inspect `which jest` --logHeapUsage -i

Any help on this one is highly appreciated!

@thymikee, what really confuses me is that his repo requires babel-polyfill as a dev dependency, but he doesn't actually load it anywhere in the project. How/why would this make it worse?

When using babel-jest and when babel-polyfill is available, Jest will load it automatically.

@cpojer, but he's not using babel-jest, just jest.

babel-jest is used as a dep of jest-runtime

FWIW I repeated the run of Quentin jest-test repo with Node 7.2.1 and Jest 17.0.3.
With babel: 44MB + 1.00MB * specs run
Without babel: 41MB + 0.52MB * specs run

Further investigation: the suspect is jsdom.
When running Jest with jsdom environment, the Runtime object doesn't get swiped by gc.
On the other hand, when --env=node Runtime is properly garbage collected.
Below are results after running couple of hundred tests:
--env=jsdom:

--env=node:

Since jest-environment-node and jest-environment-jsdom are nearly identical, it makes it even more probable, that jsdom is to blame here, although I'm not 100% sure.

Do you know what exactly is being retained or what kind of stuff may lead to cycles? We may want to unset more things in the dispose method here: https://github.com/cpojer/jest/blob/master/packages/jest-environment-jsdom/src/index.js#L19

Update: Managed to separate the case with jsdom only and filed an issue there: https://github.com/tmpvar/jsdom/issues/1682
Feel free to help debugging this 😄

See my comment in tmpvar/jsdom#1682 : the memory leak in jsdom only happens when window.close() is called synchronously after jsdom.jsdom() I see two options here:

To try fixing jsdom. There is obviously something asynchronous happening in jsdom.jsdom. This leads to a reference of the window being held beyond the window.close() call.
Try fixing jest-envirnment-jsdom. If it is rewritten to return a promise, instead setting directly a window, we could use jsdom.env, which solves the problem by being asynchronous.

I did research further. It seems that JSDOM is just a drop in an ocean. If I implement a fix for JSDOM locally, I still get huge memory leaks. However, as soon as I remove babel-polyfill, the leaks drop by 95%. IT seems that certain shims in corejs (the Object getters/setters, for example) are causing the leaks when combined with jest.
A solution would be disabling babel-polyfill and starting jest with
node --harmony jest --no-polyfill...

I would change the title of this ticket back to babel-polyfill, since it seems to be far bigger memory issue than JSDOM.
I would add a config option to disable automatic babel-polyfill import.

95% drops are interesting, I have experienced some drops, but not this big, and the stack was still growing fast.
I've did a quick test and it looks like on --env=node it grows stack in similar fashion when paired with bebel-polyfil (comparing Node env + polyfill with JSDOM env without), so maybe there's something shared about these two?

I'm wondering: do we even need babel-polyfill in recent versions of Node? Shall we just not load it (except for regenerator, which we may still need).

...unless you want to test with exactly the same setup as the "real" thing. The node and core.js implementations of the ES6/7 features could be different. ;-)

Okay, here are my findings so far:

A huge leakage happens when using babel-polyfill.
Jsdom does not correctly destroy the window when jsdom.jsdom() and window.close() are called synchronously one after another.

If I remove babel-polyfill, the memory usage still grows during the tests, since all the windows are still in the memory. How much it grows depends on what your tests are how you utilize the windows. Right after the tests (probably on the next tick) the memory drops since all windows are destroyed.
Babel-polyfill makes the whole thing even worse, since (1) its memory leak makes the memory usage grow even faster from test-to-test and (2) the windows are not destroyed, even after the tests complete.
Just removing babel-polyfill alleviated the problem in one of our projects (memory almost does not grow). However we are still having issues on another, bigger one (500 tests) where the tests OOM randomly just because the windows are not destroyed right after completion of each test.
How do we solve it? Well, just removing babel-polyfill alleviates the problem for smaller projects/tests. Fixing jsdom issue while having babel-polyfill on board would not fix anything, since the windows would not get destroyed because of the leakage. That means that we need to tackle both issues at once:

Remove babel-polyfill (or at least give an option to disable it in jest).
Fix jsdom or change the way jest calls jsdom (use jsdom.env) so that the windows get destroyed after each test and not at the end of all tests. Otherwise we might hit memory limits during the tests.

Are you sure jsdom.env fixes the problem for you? I've changed jest-environment-jsdom locally to use it once and didn't see better results. Jest disposes jsdom (calls window.close()) not in the same tick. also wrapping the close() method in setTimeout didn't help.
BTW, I appreciate your help on investigating that so much, thank you!

It's in our all interest to get this issue fixed. So you are most welcome! ^^
Check out the code in my comment on the jsdom issue:
https://github.com/tmpvar/jsdom/issues/1682#issuecomment-270310752
If I use the jsdom.env version for spwanWindow and print the heap usage, I bare see any memory spikes at all. Maybe my methodology is wrong. Can you try it?

Sure I have tried that and it indeed worked for me (but didn't check in the inspector). I need to find some time to test it better in Jest, because last time it was a really quick check, where I could miss something!

Okay. We have this issue fixed in our project with a small workaround. These steps are necessary:

Remove babel-polyfill from your project. This is essential.
Create a new setup file in your project that overrides the describe method and automatically creates/destroys the JSDom environment before/after each test. See the example below.
Run jest with node --harmony (for babel-polyfill replacement), --env node (instead of the default jsdom environment) and --setupTestFrameworkScriptFile path/to/your/setup.js

Following example of a setup file:
import jsdom from 'jsdom'

const FAKE_DOM_HTML = `
    <html>
    <body>
    </body>
    </html>
`

/*
 * First, we override Jasmine's describe method so that we can automatically add beforeAll and afterAll.
 * In the beforeAll and afterAll we asynchronously setup and tear down the jsdom instance.
 * This solves the synchronous window.close() issue with jsdom described here:
 *
 * https://github.com/tmpvar/jsdom/issues/1682#issuecomment-270310752
 *
 * Be aware, that if your project has "babel-polyfill" in its node_modules, you will have
 * problems with leaking windows. If you need polyfills for the building process, use the cloned version
 * that is renamed to something else than babel-polyfill.
 */
const desc = global.describe
global.describe = (title, test) => {
    /* We need to keep reference to the window to destroy the correct one afterwards.
     * Otherwise, some tests might fail. This is probably related to this fact here:
     * https://github.com/airbnb/enzyme/blob/master/docs/guides/jsdom.md#describewithdom-api-and-clearing-the-document-after-every-test
     */
    let testWindow = null
    desc(title, () => {
        beforeAll((done) => {
            // We wait until JSDom has finished building the window, before continuing with the tests.
            jsdom.env(FAKE_DOM_HTML, (err, window) => { // eslint-disable-line
                testWindow = window
                global.window = window
                done()
            })
        })
        afterAll((done) => {
            // After the test suite completes, we ASYNCHRONOUSLY delete the apropriate window, making sure it is released correctly.
            setImmediate(() => {
                if (testWindow) {
                    testWindow.close()
                }
                done()
            })
        })
        const testRunner = test.bind({})
        testRunner()
    })
}
global.describe.skip = desc.skip

Now you can run jest with:
node --harmony node_modules/.bin/jest --env node ----setupTestFrameworkScriptFile path/to/your/setup.js

Profit!
In the jest project, following could be done to make the life easier:

Make polyfills optional. For, example, if babel-jest is provided, but --no-polyfills flag is set, run the code with --harmony flag.
Rewrite jest-environment-jsdom to create/destroy the window asynchronously as shown above.

Hi there, let me add some observations from our project. I am trying to migrate our Mocha stack to Jest and I encountered similar problems.
I've tried removing babel-polyfill and adding the afterAll hacks as @romansemko suggested, however, I have got the same results for all cases — around 7 extra MB in heap memory per describe. It makes the heap grow over 1G after 1500 tests and crashes node for JavaScript heap out of memory after a while. We have over 3k tests for now and the main problem with the leakage is that the tests take 25m to finish. With mocha it is under 3 minutes for comparison.
Our test environment is quite complicated, we mock canvas rendering context in jsdom, we still have half of our codebase in coffee-scriptand we have large number of dependencies, any of them might have another leaks on their own.
I realized that besides transforming coffee-script via transform config option I had require('coffee-script/register') in one of our setupFiles as well. So I removed it and tada 🎉 the memory usage dropped. So the main culprit in our case was global coffee-script/register.
We have some async-await stuff in our codebase so we need babel-polyfill. I added it to the env and I could see the rise of the heap again. This time it was around 50% of the original spaced filled with coffee-script + babel-polyfill leaks. It is interesting that, when I removed babel-polyfill only and kept coffee-script there were similar amounts of leaks as with coffee-script + babel-polyfill. But babel-polyfill itself had half of them too.
Since we don't really need the whole babel-polyfill I replaced it with regenerator-runtime/runtime and I was able to get almost the same results as without it. I also tried Node 7 with --harmony --harmony-async-await but I was not able to make it work, I was still getting errors ReferenceError: regeneratorRuntime is not defined.
Anyway, I think the best solution would be to solve this on jest level. Not in jsdom or babel-polyfill and not in testEnv or testRunner (in afterAlls). Currently we run our tests with Mocha and everything works (with possibly present hidden leaks) quite fast. I guess there has to be more thorough environment reset in Mocha. Yes, we can delete/unset more things in dispose method as @cpojer suggested, but it shouldn't be jsdom or babel-polyfill thinggie only, it should be something more radical as the leaks might be in variety of dependencies. Maybe it should be even higher up in the environment creation hierarchy? Could there be a particular reason, maybe a design decision, that leads to the leaks from the specs being leaked "globally" (copared to Mocha), @cpojer?

@jakubzitny thanks for sharing your story!
I'll try to make this issue a priority for the next couple of days.

The difference is probably that in mocha, everything is within one context. In Jest, every test has its own context and is isolated from each other. It seems like it creates some cycles that can't be GC'd, unfortunately.

UPDATE: I'm not yet sure why, but just tested it on latest master build with and without babel-jest and the leak is gone, so it was probably somewhere on our end.

This was fixed accidentally with this commit https://github.com/facebook/jest/commit/8256904751d85e16909152ddaf8395d7c2b60eba and I have no idea why this works, seriously.
Anybody have any ideas? Maybe it's some kind of weird edge bug in Node.

@thymikee, this change basically waits for the next tick before returning the result. Hence, when the environment is disposed afterwards, the window.close() is called in the next tick. This makes the jsdom's window to be GCed correctly (because it is not called synchronously within the same tick, as before).

I wish this was that simple. Try running env.dispose() in the next tick and see the results. This is weirder than it seems

@thymikee any idea when this will be released? Also hitting issues with memory leaks on circleci and the setImmediate change appears to do the trick. Thanks for tracking it down!

It will land in Jest 19. We plan to release it in a week.

This should be fixed now for the most part, right? :)

We upgraded to Jest 19 in the hopes that this memory leak would be fixed, but unfortunately that's not the case. We've been using the --runInBand flag to run tests on individual folders to dodge this memory leak up until this point, but now (with Jest 19) the memory leak has resurfaced. You can see how the test times are snowballing here:

As a result, Circle CI gives us this failure:

Is anyone else still plagued by this memory leak in Jest 19?

Yes -- after upgrading to Jest 19, we were also still seeing a memory leak with a combination of babel-polyfill being present in node_modules and jest in our project.
Removing babel-polyfill addressed the issue for us.

FWIW, it seems the issue only presents itself when running async, as the --runInBand flag completely avoids it. Is that helpful at all?

@mute I did an npm uninstall babel-polyfill right before our npm test command and it did get us a little bit farther before crashing, but it still crashes very early on in the batch of tests we have to run.

I apologize. I forgot to merge https://github.com/facebook/jest/pull/2755 into the release (honestly I thought I did), it will be part of the next release.

All good @cpojer. I'm just glad it's fixed!

@cpojer when do you expect the release with #2755 to be on NPM? If it's more than a week, would you be open to cutting a prerelease? This memory leak is costing us hours of CI time with all the garbage collection it triggers.

@turadg if it takes a while, you can always do what we're doing (for now) so you don't waste any more time. Look at our npm run test:ci command below:
{
  "scripts": {
    "test": "jest",
    "test:ci": "suites=\"fooFolder barFolder bazFolder\"; STATUS=0; for i in $suites; do npm test -- \"${i}/*\" --runInBand; STATUS=$(( $? > $STATUS ? $? : $STATUS )); done; exit $STATUS",
    "watch": "npm test -- --watch"
  }
}

@cpojer it's been a week since the last comment and still no release. Any idea when the next one will be?

No, there is no fixed release schedule here. There may be one next week.

Greetings. It's April 5th and we are still experiencing this issue on Jest 19.0.2. Originally when running jest, I was up to 500s and 1.6Gb ram usage per concurrent test when I ran out of patience and killed jest.
After removing babel-polyfill from our project, running jest still actually passes, but it's still slow, and heap size still continuously increases. But now, when Jest completes, the heap size is only 500Mb.
Now, if I run node with --expose-gc, suddenly the heap stops growing. Heap size per spec is around 50Mb. Now in our case, we are migrating from Karma, and our test time was around 35 seconds for 550 test specs.
It appears that this issue was supposed to be fixed in v19. But is it?

Can you try jest@next for now and see if it helps?

What's the hold up on a patch release?

@cpojer's time off mainly. Although there's a chance we could roll out 19.1, but @dmitriiabramov is the one to decide.

@thymikee I'll give it a try.

@thymikee I was facing the same memory issue and then very slow tests. I made a fresh install of node_modules and then jest@next - my tests went from ~750s to ~125s and memory was stable around 800mb per worker (previously hitting the limit of 1.45gb per worker)

Still getting the memory leak on Jest 20.0.1, but it only happens in our Travis-CI environment. Any ideas on why that would be?

The same tests run in just under a minute on my local machine:

@jedmao We still had the same issue after updating to Jest 20.0.1 with CircleCI.  We were able to fix it by using --maxWorkers=1 (more info on that flag)
Testing showed that one worker was the best number (fastest tests).  --env=node also sped up the tests if not using --maxWorkers but didn't seem to make a difference when setting maxWorkers so we just went with only --maxWorkers.

@mlanter @jedmao I encourage you to debug your tests with --inspect flag for Chrome Debugger and try to figure out where the leak may come from (it's likely something in your tests). To simulate slow CI environment, you can throttle the CPU a bit:

@thymikee thanks for the tip. It appears that I cannot --inspect unless I also use --runInBand, which defeats the purpose, because the memory leak does not present itself with --runInBand. Have you been able to --inspect w/o --runInBand?
That said, I ran the tests @ 20x slowdown with --runInBand and everything ran swimmingly.

@mlanter I have a feeling that --maxWorkers=1 is doing the exact same thing as --runInBand. Either way, thanks for the tip! Both methods worked just fine in my CI environment, even though they had memory leak issues before Jest 20.
I think I'm fixed here, folks!


fixed issue [#592]

Replaced strftime() with isoformat() as @ironfroggy suggested to fix metadata update failure when the selected year is less than 1900. As a result, the start date and end date of the temporal coverage have the string representation format of YYYY-MM-DD as specified in ISO 8601 which is returned from isoformat() as opposed to the previous format of MM/DD/YYYY. I think this should be fine. With this fix, users can select year before 1900 and successfully save changes with metadata updated successfully.
@ironfroggy @pkdash Could you review the code and raise issues if any?

@hyi - will this change also allow us to type a date into the coverage element that has hours, minutes, and seconds?  I ask because for time series resources, they may begin at a particular time on a day.  One could just select the day on which they start, but it is more correct to select the date/time of the first observation.
When I was testing creation of a time series resource the other night I noticed that the validation on the date fields would only allow me to enter a day - I couldn't enter a time.

@horsburgh The current datePicker input widget only allows you to pick a day, not a time. I am not able to input any time either, which is limited by input widget, not the django form validation. If input widget allows to input a time, the form validation should work since it takes a datetime object which includes time. Is there an issue raised regarding time input for start and end dates? If not, we should create one and work on front end input widget to allow users to input time. @mauriel133 Any idea on an input widget that allows to select date as well as input time?

@horsburgh @mauriel133 A simple googling gives me this: https://eonasdan.github.io/bootstrap-datetimepicker/ which appears to provide interactive date picker in conjunction with time input. It comes with bootstrap 3. @mauriel133 Are you able to explore this while exploring upgrading bootstrap and jquery versions for HydroShare?

@hyi and @mauriel133 - Let's make input of times into the coverage element a separate issue.

@hyi, @mauriel133 - Will this be resolved for v 1.5.3?
Or should it be deferred to a later release?

@mjstealey I think this should be resolved for v1.5.3 since the other related issue [#579] has already been merged and slated for v1.5.3. Merging this PR will resolve the issue with temporal start and end dates selection limitation to 10 years in conjunction with the other fix to issue [#579] which is already merged. @horsburgh or @mauriel133 will create a different issue on allowing to input time for start and end dates, which will be tackled after v1.5.3.

@hyi - This sounds good. Please let me know when this is ready to go in as we are scheduled to deploy v 1.5.3 tomorrow, and it would be nice to get this onto a test machine before then.

@mjstealey this PR is ready to be merged and ready to go for testing. The code change is simple with low risk. It keeps the same coverage test number and I have tested it locally with no issues found.

@hyi - merged and deployed to dev - please verify

@mjstealey tested and verified. It is working as expected. Will ask @vmmerwade to verify the issue he opened.


Update Tests

Ensure that https://github.com/picoCTF/picoCTF-Platform-2/tree/master/api/tests are up-to-date and add documentation on how to run them.

By up-to-date, I mean tests that reasonably pass against the current code base. Adding tests that get us decent coverage will have to be done over time.


Remove redundant activation events from samples

The github auth sample could be included in this :)

AFAICT bumping the types is not required. vsce only complains if you try to use types from a newer version of VS Code than is required in the engine property.
https://insiders.vscode.dev/github/microsoft/vscode-vsce/blob/1936e8b56627e873ebffa2390e4d1a466676cc65/src/validation.ts#L99-L101

The custom editor sample does not work anymore.
Setup:

@broken-bytes The custom editor sample works as expected for me:

If it still doesn't work for you, could you please file a new issue with reproducible steps so we can investigate further? Thanks!


Reflect any vector

reflect should at least support 2-D vectors as well as 3-D. In theory I think it works for arbitrary N but I haven't been able to wrap my head around what that means...

The unittest works cleverly by having integer exactly representable as floats and 0.5. Nice touch.
Use v4.0.4+


Why module execute company messages?

Describe the bug

I subscribed new messages package for month and i got guru meditation error instead for updating required fields on thingSpeak.
And I think I also have to fix another logical issue, when a company message received instead of sending it to execute, we better just delete it.

To Reproduce
Either subscribe to new package or send message I'll attach its body.
Expected behavior
When user subscribe new package module should updated required fields #96 added in this task.
Screenshots
Here is the  of the issue
Additional context
When system rebooted it ask for time from orange pi and also receive it after 2 minutes continuously but look at last message carefully message time stamp is not correct it is also a bug, if fixed in next PR it'll be great otherwise, I'll might create separate bug.

here it the message which we receive when subscribed to new package:
Your Offer with 0 Onnet Mins 0 Other Network Mins 0 MBs 10000 SMS with 30day validity has been subscribed for Rs. Status:*303*30#

#142 PR fixed this issue so, closing this issue.