Loki4j appender does not work after context refresh event

[cui086]

Hi,

I have a spring application that uses cloud config server. After each time we refresh the config, hence firing a content refresh event. The loki append does not send out the log anymore.

I have attached a loki4j_append_time_seconds_max graph here. Please let me know how should I trouble shoot this better.

[cui086]

   | 14:39:37,158 |-INFO in com.github.loki4j.client.pipeline.AsyncBufferPipeline@3003e580 - <<< Batch #10422e19064c46 (25,999 bytes): Loki responded with status 204
   | 14:39:37,161 |-INFO in com.github.loki4j.client.pipeline.AsyncBufferPipeline@3003e580 - Drain completed
 | 14:39:37,161 |-INFO in com.github.loki4j.logback.Loki4jAppender[LOKI] - Successfully stopped
  | 14:39:22,998 |-INFO in com.github.loki4j.client.pipeline.AsyncBufferPipeline@28757abd - >>> Batch #1d9742840f8f6 (DRAIN, 132 records, 30 streams, est. size 92,449 bytes) converted to 97,223 bytes
  | 14:39:23,030 |-INFO in com.github.loki4j.client.pipeline.AsyncBufferPipeline@28757abd - <<< Batch #1d9742840f8f6 (97,223 bytes): Loki responded with status 204
   | 14:39:37,193 |-INFO in com.github.loki4j.logback.Loki4jAppender[LOKI] - Stopping...
 14:39:37,193 |-INFO in com.github.loki4j.client.pipeline.AsyncBufferPipeline@28757abd - Pipeline is draining...
  | 14:39:37,212 |-INFO in com.github.loki4j.client.pipeline.AsyncBufferPipeline@28757abd - >>> Batch #1d97777b9fd0c (DRAIN, 69 records, 17 streams, est. size 45,214 bytes) converted to 47,812 bytes
   | 14:39:37,221 |-INFO in com.github.loki4j.client.pipeline.AsyncBufferPipeline@28757abd - <<< Batch #1d97777b9fd0c (47,812 bytes): Loki responded with status 204
    | 14:39:37,243 |-INFO in com.github.loki4j.client.pipeline.AsyncBufferPipeline@28757abd - Drain completed
| 14:39:37,243 |-INFO in com.github.loki4j.logback.Loki4jAppender[LOKI] - Successfully stopped

Also tried with verbose enabled. But stopped after context refresh event.

[nehaev]

Hi @cui086, thanks for posting this! Still I'm not sure how do I reproduce this. It would be great if anybody could provide a test or a code snippet that I can run and see the issue.

[nehaev]

Closing this issue as non-reproducible. Ready to re-open it once a test or a code snippet that I can run and see the issue is available.