[JAVA-3606] NullPointerException: DecoderContext.decodeWithChildContext Created: 24/Jan/20 Updated: 09/Oct/20 Resolved: 09/Oct/20 |
|
| Status: | Closed |
| Project: | Java Driver |
| Component/s: | POJO |
| Affects Version/s: | 3.12.0 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Carlos S | Assignee: | Brian DeLeonardis (Inactive) |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
java 8, documentdb(aws) |
||
| Attachments: |
|
||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||
| Description |
|
I am getting NPE at DecoderContext. The issue presents rarely, about 5% of the time, but when it does is at server start. Once it happens, all other calls to the same find method decoder fail with the same error. There are other tickets If possible, please provide an intermediate improvement to improve the error response (NPE does not include any context information). Maybe providing the context of the call in the exception would help to find the issue:
Notes
|
| Comments |
| Comment by Brian DeLeonardis (Inactive) [ 09/Oct/20 ] | ||||||
|
I was able to reproduce this bug with the following code (PojoQuickTour has the main method): Reproducer.zip Failed to decode 'Container'. Decoding 'one' errored with: Failed to decode 'One'. Decoding 'two' errored with: Failed to decode 'Two'. Decoding 'three' errored with: Failed to decode 'Three'. Decoding 'four' errored with: Failed to decode 'Four'. Decoding 'five' errored with: Missing codec in 'Four' for 'five'
After this commit I can no longer reproduce the error and the program runs to completion each time. I believe the same bug that was causing Best, | ||||||
| Comment by Ross Lawley [ 30/Apr/20 ] | ||||||
|
HI daniel.desprez@zerpsed.com, Could you open a new ticket and add as much information as possible. If you can create a reproduction case that would be super helpful. Ross | ||||||
| Comment by Daniel Desprez [ 29/Apr/20 ] | ||||||
|
@Ross Lawley thanks for the reply. Perhaps it looks that way, but I disagree for these reasons: 1. I'm not using @BsonDiscriminator or derived classes in my POJOs, which 2. This is rare. I can bounce my application and reads of the same data into POJO's are decoded with no problem. 95% of the time, there is not problem. 3. If I downgrade to 3.11.1 I get the occasional NPE at app startup, which continues for subsequent reads of the same data. If I upgrade to 3.12.2 I no longer the the NPE and instead handle the CodecConfigurationException at the same read locations. Still, only occasional on app startup and resolvable by restarting the app. I'm trying to give you more visibility now that a null check is in place. Please let me know if I can provide anything else that would assist you and I'll be happy to do so. | ||||||
| Comment by Ross Lawley [ 29/Apr/20 ] | ||||||
|
daniel.desprez@zerpsed.com that is another issue as per the exception error message you may have to explicitly declare the class in the PojoCodec.
| ||||||
| Comment by Daniel Desprez [ 28/Apr/20 ] | ||||||
|
Hi @Ross Lawley . I started monitoring this bug after encountering it around 3/20/2020. I updated our clients to use 3.12.2 and we have recently begun catching the wrapped exception. Thought I would share the new stack trace with you (attached). All behavior is the same between our app handling the NPE from 3.11.1 and the stack below using 3.12.2. Only on app startup, occurrence is rare, the calling code using the mongo client is similar as well. One commonality I see is this behavior is only occurring in environments where the client connects to a single mongo process. In my production and test env's with clustered mongos this behavior has not occurred; this could be purely coincidental.
Thanks, Daniel
| ||||||
| Comment by Ross Lawley [ 30/Mar/20 ] | ||||||
|
csamail@gmail.com just to let you know 3.12.2 has been released. Ross | ||||||
| Comment by Carlos S [ 20/Feb/20 ] | ||||||
|
Thank you Ross, I am looking forward for the release | ||||||
| Comment by Ross Lawley [ 03/Feb/20 ] | ||||||
|
I've added a null check so hopefully some more context will be provided and that will help identify the cause of this bug. Also I made a change to how the ProvidersRegistry handles caching , which should stop a race creating multiple instances of the PojoCodecImpl. These fixes will be released in 3.12.2 I'll refrain from closing this ticket until we learn if the changes have made a difference. So for now I'm changing the status back to Scheduled and once 3.12.2 is released we'll follow up. Ross | ||||||
| Comment by Githook User [ 03/Feb/20 ] | ||||||
|
Author: {'username': 'rozza', 'name': 'Ross Lawley', 'email': 'ross.lawley@gmail.com'}Message: Codec improvements Ensure DecoderContext null checks the decoder
| ||||||
| Comment by Githook User [ 03/Feb/20 ] | ||||||
|
Author: {'username': 'rozza', 'name': 'Ross Lawley', 'email': 'ross.lawley@gmail.com'}Message: Codec improvements Ensure DecoderContext null checks the decoder
| ||||||
| Comment by Ross Lawley [ 30/Jan/20 ] | ||||||
| Comment by Carlos S [ 29/Jan/20 ] | ||||||
|
Again, I have only been able to reproduce in production, with higher and more random loads than I know how to produce in development environment. At this moment, what would really help a null pointer check (with context). | ||||||
| Comment by Carlos S [ 29/Jan/20 ] | ||||||
|
Yes, the error has happened in both 3.10.2 and 3.12.0 drivers. Attached is the skeleton of all the pojos used (no getters or setters). The main Pojo in my case is named PG and the collection has about 40 entries of that type, each entry is about 20kb when formatted as json text. | ||||||
| Comment by Ross Lawley [ 29/Jan/20 ] | ||||||
|
I've closed Unfortunately, in Also just to clarify you are seeing this issue with the 3.12 driver? Many thanks, | ||||||
| Comment by Carlos S [ 24/Jan/20 ] | ||||||
|
In answer to questions in other tickets, the query does not use projections:
|