-
Notifications
You must be signed in to change notification settings - Fork 150
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
“ERROR: Subject remapping requires Options.oldRequestStyle() …” #424
Comments
@gdiet Do you re-use / re-send message objects? We are able to reproduce this under those conditions. I had also seen it intermittently but couldn't quite put my finger on it. |
@scottf We call |
@gdiet It's up on sonatype in the snapshot repo You should just need to change your version number
You might need to add sonatype to your repos
|
@scottf Thanks, that did the trick. I'll get the snapshot version deployed and will check in the next few days whether or not I still get these |
@scottf with 2.9.0-SNAPSHOT, up until now the message didn't appear again. I hope it doesn't reappear over the weekend - it often pops up on Saturday during system maintenance. I'll post an update on Monday. Thanks to the team for a great MQ server & Java library! |
@scottf No more occurrences of the "Subject remapping" message over the weekend. Yay! I close the issue. |
Have swapped out my pub/sub mechanism with nats 2.10.0 on Java 11 and have run into this issue. Will be gone for a bit, but when I am back I will try to make a small reproduceable example. Here is another error i'm getting in case it is related |
@Zannith Please send more information when you get a chance. |
The cause of this error appears to be having having all subjects on a stream with the > wildcard. Maybe this is expected behavior? But I think it could still have a better error. Changing the subject of line Here is my example test
|
You cannot have a stream with |
@ripienaar Okay, so it only supports *? The above test is actually working with the > though, so long as I have something before it. And I am getting no error with it. Is that something I should file a new bug for? |
It supports wildcards, but what |
Ah okay that makes sense, So I would need to be certain that whatever subject prefix I have does not crossover into any of the internal subjects. Thank you for the clarification! |
@Zannith You cannot set a stream subject to have a wildcard, but your subscribe subject can have a wildcard, I'll add validation for this. See Issue #447 As far as your test, I think you need to subscribe before publishing. The handler in the dispatcher can be null or you can use the nc.CreateDispatcher() no param method, but the handler is not in use until the subscribe since the dispatcher does not yet know which subject to send to it. |
In our cloud production system, we use java NATS 2.8.0 client together with docker
nats:2.1.9-linux
NATS server (no JetStream involved). Occasionally (a couple of times per week) the NATS client prints to stdout:This error message was introduced with the "Subject Remapping Fix" in #327
We don't know the exact circumstances that trigger the message. Logging the whole NATS traffic (for investigations) would be possible but cumbersome.
I see the following issues:
System.out
in the Java NATS client except for the connection tracing that can be enabled as option, see io.nats.client.Options#isTraceConnection. Is it intended that System.out is used for signalling potential problems?Builder.oldRequestStyle()
says "Turn on the old request style that uses a new inbox and subscriber for each request." This sounds to me like the new request style (which probably re-uses inbox and subscriber) in general is regarded as "better", and you use the old request style as "last resort". What I'm missing here is documentation helping me to decide.The text was updated successfully, but these errors were encountered: