Reduce logging

[tveon]

Fixes issue #63

Description of changes:

• Add basic .gitignore
• Reduce logging level to debug for statements which are likely to occur frequently in production systems

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[blacktooth]

Are you facing performance issues due to these logging statements? These statements are logged during auto-registration flow which we don't expect to be a frequent operation. Is it different in your use-case?

[snemarch]

Are you facing performance issues due to these logging statements? These statements are logged during auto-registration flow which we don't expect to be a frequent operation. Is it different in your use-case?

See #63 🙂 – we get the log statement for every sent. Not sure of the performance implications, but drowns useful log messages and does have some log storage cost.

[blacktooth]

Are you seeing this logged for every request?

[snemarch]

We're only seeing the "Auto Creating schema" message once, and then the "Schema Version Id is null" on every message.

[mohitpali]

Thanks for fixing this. Would you mind updating it in class GlueSchemaRegistryKafkaSerializer.java as well. This class is a generic class that can be used with additional property called "dataFormat" and passing "JSON" or "AVRO".

[snemarch]

Note that re the information in #63, I think there might be an underlying issue, and changing the log level will just mask that.

[mohitpali]

I think this got lost in merge conflicts resolution. This has been a miss on our side. The schema auto creation should still be info because we don't expect that to happen very often. The Over logging issue is legit. Are you suggesting that there is an underlying issue with the library or your set-up particularly ? Either ways, we would be happy to help.

[snemarch]

@mohitpali - so, if I understand correctly:

1. Usecases where dynamic schema registration is used isn't meant to store the registered schemaVersionId, and the cache a crucial part of the design, not "just" an optimization.
2. Usecases where you can manually evolve schemas can have the schemaVersionId predefined.

Even with re-changing log level to DEBUG, would it be worth adding a comment to the codebase that it's normal to get this on a per-message basis for dynamic scenarios, and that caching further down ensures this is not a performance problem?

Thanks for your help in clearing up matters! :)

[mohitpali]

Your understanding is correct. Adding comment is also a good idea.

[mohitpali]

If you could please change the below line to info, we should be good to merge.
log.debug("Auto Creating schema with schemaName: {} and schemaDefinition : {}", schemaName, schemaDefinition);

[snemarch]

If you could please change the below line to info, we should be good to merge.

@tveon is on vacation for the next few weeks, but I'll see if I can persuade him to do that one-line update :)

[tveon]

Done. 👍 🌴

[snemarch]

Hello, good people, do you have any plans for when the next release is going to be? 😃

PS: I just noticed that while there's a 1.1.1 release on Maven Central, this GitHub repo only has tags for 1.0.2 and 1.1.0.