sixt / ja-micro Goto Github PK

When calling another micro service from a ja-micro service, there is an issue when getting a response larger than 2M. I started implementing a fix from jetty's documentation, but tests are failing, so it needs a bit more work.

It is a valid case for users of kafka to publish messages with a null value (especially for 'deleting' data in compacted topics). Currently, this generates an NPE.

KafkaSubscriberFactory.initialize() and KafkaPublisherFactory.initialize() no longer need to be called in AbstractService.initializeKafka()

Your project, Sixt/ja-micro, depends on the outdated library FastClasspathScanner in the following source files:

• src/main/java/com/sixt/service/framework/injection/TracingModule.java
• src/main/java/com/sixt/service/framework/kafka/messaging/ReflectionTypeDictionaryFactory.java
• src/main/java/com/sixt/service/framework/injection/ConfigurationModule.java
• src/main/java/com/sixt/service/framework/injection/ServiceRegistryModule.java
• src/main/java/com/sixt/service/framework/injection/MetricsReporterModule.java
• src/main/java/com/sixt/service/framework/JettyServiceBase.java
• src/test/java/com/sixt/service/framework/AbstractServiceAutomaticHandlerRegistrationTest.java
• src/main/java/com/squareup/wire/schema/internal/parser/RpcMethodScanner.java

FastClasspathScanner has been significantly reworked since the version your code depends upon:

• a significant number of bugs have been fixed
• some nontrivial API changes have been made to simplify and unify the API
• FastClasspathScanner has been renamed to ClassGraph: https://github.com/classgraph/classgraph

ClassGraph is a significantly more robust library than FastClasspathScanner, and is more future-proof. All future development work will be focused on ClassGraph, and FastClasspathScanner will see no future development.

Please consider porting your code over to the new ClassGraph API, particularly if your project is in production or has downstream dependencies:

• https://github.com/classgraph/classgraph/wiki/Porting-FastClasspathScanner-code-to-ClassGraph
• https://github.com/classgraph/classgraph/wiki/Code-examples
• https://github.com/classgraph/classgraph/wiki/ClassGraph-API

Feel free to close this bug report if this code is no longer in use. (You were sent this bug report because your project depends upon FastClasspathScanner, and has been starred by 612 users. Apologies if this bug report is not helpful.)

Hi there, just curious what happened.

It seemed that there were regular contributions

Thank you

Add support grpc

Probably add 2 different metrics, one for sync and one for async publishing

Ja-micro throws a NPE during RpcCallException.fromJson(error) if it tries to decode an error response from another service that does not conform with the new error handling and does not contain a category.

Reproducable with this test:

@Test
public void testFromJson_OldErrorHandling() {
    String error = "{\"id\":\"com.sixt.service.foobar\",\"code\":500,\"detail\":\"error message\",\"status\":\"Internal Server Error\"}";
    RpcCallException ex = RpcCallException.fromJson(error);
    assertThat(ex).isNotNull();
}

Consul 1.0.0 has breaking API changes, see CHANGELOG and PR

Starting from this release it's not possible to use GET to update health checks. While trying do it we're getting: "Received 405 trying to update health".

It is necessary to use PUT verb for updating health checks.

please include all packages, especially google ones

https://help.github.com/articles/creating-a-pull-request-template-for-your-repository/

If we have a proper template it would be clear to everybody who wants to participate what information has to be provided in a pull request.

My proposal is to have at least the information proposed in the article from GitHub.
But I'm open for a more stricter set of data.
What do you think?

The readme says "the developer can simply focus on the functionality of his services instead." Can I suggest you change this to something more gender neutral?

What did you do
Stop consul agent. Start new instance of consul with fresh database.
I also notice this when consul agent can't connect to cluster (network partitioning) for some time and then join again but old service registrations and health checks are not valid in cluster anymore.

What did you expect to see
Services which use ja-micro reregister themselves with the new health checks (like services which use go-micro)

What did you see instead
Java services is trying to update old health checks but but getting error 500:

2018/04/27 07:58:31 [ERR] http: Request PUT /v1/agent/check/pass/service:8b298f948734, error: CheckID "service:8b298f948734" does not have associated TTL from=10.254.26.1:52890
    2018/04/27 07:58:32 [ERR] http: Request PUT /v1/agent/check/pass/service:7559eca09166, error: CheckID "service:7559eca09166" does not have associated TTL from=10.254.26.1:52944
    2018/04/27 07:58:33 [ERR] http: Request PUT /v1/agent/check/pass/service:7dc2b04fd50f, error: CheckID "service:7dc2b04fd50f" does not have associated TTL from=10.254.26.1:53030
    2018/04/27 07:58:34 [ERR] http: Request PUT /v1/agent/check/pass/service:c98c1b816f12, error: CheckID "service:c98c1b816f12" does not have associated TTL from=10.254.26.1:53084
    2018/04/27 07:58:35 [ERR] http: Request PUT /v1/agent/check/pass/service:4d83c1bd8ada, error: CheckID "service:4d83c1bd8ada" does not have associated TTL from=10.254.26.1:53154
    2018/04/27 07:58:35 [ERR] http: Request PUT /v1/agent/check/pass/service:d407da4e2393, error: CheckID "service:d407da4e2393" does not have associated TTL from=10.254.26.1:53160

It is necessary to restart service just to register again in Consul

Background:
When using kafka topics which are 'compact', you hint to kafka that it can delete all records for a given key by publishing to the topic with a null body for the given key.

This data is available in the ConsumerRecord, I will add they key to the KafkaTopicInfo, since it is already passed to the event callback handler.

RpcClient fails trying to decode an empty response received as result of an outgoing service call.

Oracle has requested we not use 'java' in the name. micro-j and j-micro are already in use by companies. We need a catchy name. Please help!

To allow service developers to write SITs with services that use custom or multiple topics, refactor ServiceTestEventHandler and ServiceUnderTestImpl to allow the user to specify the topic

Has anyone successfully imported this project into IntelliJ ?
When I tried to do that, it failed complaining about gradle issue.

Second, after I manually downloaded dependent jar libraries, and compiled this project, I found a lot of java files reference this java file, com.sixt.service.framework.protobuf.RpcEnvelope.java, but it does not exist.
Same issue happens to com.sixt.service.framework.protobuf.FrameworkTest.java.

Or these two java files will be generated automatically ? Did I miss anything ?

Thanks.

Json that can't be unmarshaled back to the request object, or in the case that we receive a non-matching protobuf object, an RpcCallException with category BadRequest should be thrown. The JsonHandler is currently silently ignoring these

Could not open the project use idea, the plugin could not found.

Plugin [id: 'net.researchgate.release', version: '2.6.0'] was not found in any of the following sources:

- Gradle Core Plugins (plugin is not in 'org.gradle' namespace)
- Plugin Repositories (could not resolve plugin artifact 'net.researchgate.release:net.researchgate.release.gradle.plugin:2.6.0')
  Searched in the following repositories:
    Gradle Central Plugin Repository
Open File

It looks like the etcdv3 library may be (or nearly is) feature-complete enough to develop a service-registry plugin.

As part of this work, the existing RegistrationManager / RegistrationMonitorWorker should be refactored and generalized. These two classes can retain their functionality, but should be more generic to allow multiple kinds of plugins like consul and etcd.

I want to download the source jar, but I can't find where it is.

We discovered that the default partition strategy in the java client is different than what is used in librdkafka, which is used by several other clients, so we now have aligned on using the xxHash strategy.

This initial implementation will just be bound to xxHash. If developers need other strategies, feel free to prepare a pull request ;)

We saw an issue where flyway did not perform as expected (3 service instances coming up at the same time, one threw a migration error, yet the other two started up fine.) It looks related to several issues reported against flyway in the last year. Let's try 4.1.2 and see if the problem happens again.

The problem field looks like:
map<string, OtherMessageType> metadata = 10;

18:39:53.248 [Thread-287] INFO c.s.s.f.s.mockservice.MessageHandler - Starting message handler for com.sixt.service.zoning on port 42378
18:39:53.261 [pool-49-thread-1] ERROR c.s.s.f.r.consul.RegistrationManager - Error inspecting handlers
java.lang.NoSuchMethodException: com.google.protobuf.MapEntry.()
at java.lang.Class.getConstructor0(Class.java:3082)
at java.lang.Class.getDeclaredConstructor(Class.java:2178)
at com.sixt.service.framework.registry.consul.RegistrationManager.getProtobufClassFieldDescriptions(RegistrationManager.java:320)
at com.sixt.service.framework.registry.consul.RegistrationManager.getProtobufClassFieldDescriptions(RegistrationManager.java:341)
at com.sixt.service.framework.registry.consul.RegistrationManager.getProtobufClassFieldDescriptions(RegistrationManager.java:341)
at com.sixt.service.framework.registry.consul.RegistrationManager.addEndpointsTags(RegistrationManager.java:306)
at com.sixt.service.framework.registry.consul.RegistrationManager.getRegistrationTags(RegistrationManager.java:248)
at com.sixt.service.framework.registry.consul.RegistrationManager.buildJsonRequest(RegistrationManager.java:203)
at com.sixt.service.framework.registry.consul.RegistrationManager.attemptRegistration(RegistrationManager.java:133)
at com.sixt.service.framework.registry.consul.RegistrationManager.run(RegistrationManager.java:106)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)