eclipse-ee4j / eclipse-ee4j/jersey

Outdated values of ContainerRequestContext property inside ConstraintValidator under high concurrent requests

Open
#5,420 4 comments 0 reactions 0 assignees View on GitHub
Dominant language
Java
Stars
730
Forks
382
PR merge metrics
No merged PRs in 30d

Description

### Problem Description

In Jersey 2.25.1, we are seeing outdated values of properties set in ContainerRequestContext object inside ConstraintValidator under high concurrent requests. We are accessing the ContainerRequestContext through Context annotation as shown below.

### Reproducer

```
public class CustomFilter implements ContainerRequestFilter {

@Override
public void filter(@Context ContainerRequestContext requestContext) throws IOException {
requestContext.setProperty("testProperty", requestContext.getHeaderString("testProperty"));
}
}
```

```
@Target( { ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER } )
@Retention( RetentionPolicy.RUNTIME )
@Constraint( validatedBy = EventValidator.Validator.class )
public @interface EventValidator {
String message() default "";

Class[] groups() default {};

Class[] payload() default {};

@Log4j2
class Validator implements ConstraintValidator {

@Context
private ContainerRequestContext requestContext;

@Override
public void initialize(final EventValidator eventValidator) {
}

@Override
public boolean isValid(Event event, ConstraintValidatorContext constraintValidatorContext) {
// Incorrect value in property when TPS of requests is high
String property = (String) this.requestContext.getProperty("testProperty");
return true;
}
}
}
```

### Observations

- For every request that enters our app, the hashCode value of ContainerRequestContext object in CustomFilter class is different for every request. However, the hashCode value of ContainerRequestContext object in Validator class remains same for all the requests (maybe because Validator is singleton). Is a proxy object of ContainerRequestContext (The first object under Validator class) used for all requests that enters ConstraintValidator? If yes, then in high concurrency of requests, the property value fetched from the proxy ContainerRequestContext object is outdated in a few cases. This issue does not happen when concurrency is low.
- This issue does not happen in classes which are Request scoped because in those classes, just like the CustomFilter class, every request has a different ContainerRequestContext object. So, we see no issues of property fetched from ContainerRequestContext object in such classes even in high concurrency.

### Questions

- Is it a known issue that outdated values are taken from ContainerRequestContext object in ConstraintValidator class in jersey 2.25.1? If yes, in which version of jersey was this fixed? (We are unable to see older release nodes from 2.25.1 to 2.29. Hence the question. We know that this is a very old jersey library that we are using)
- If our assumption of using a ContainerRequestContext proxy object by Jersey in ConstraintValidator is correct, how does it usually take the right value from the main ContainerRequestContext object? You can point us to the code.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.