The first 0 of value is gone.
In the linux server, the value of redis is string type, the value is 0123456, there is no 0 after taking it out, but there is no problem locally, I don’t know why, I hope to solve it, thank you!
Comment From: sundb
Can you give more details about what you encountered? .e.g version, commands
Comment From: rainfordream
template.setValueSerializer(fastJsonRedisSerializer);
eg: @Test public void testSet() { cache.put("test", "0123456", 20l); Object o = cache.get("test"); System.out.println(o.toString()); }
I have no problem locally, but if I put it on the server, the value will be less than the first 0. Thanks.
Comment From: sundb
Perhaps you could use the command GET test to check what is stored on the server.
My guess is that the return should be 0123456, if so, you could check if cache.get("test") converts it to a integer.
Comment From: rainfordream
@Override public Object get(Object key) { return redisTemplate.opsForValue().get(key); }
This is the implementation of get, because the local is good, only the server has problems, is it related to the redis configuration of the server
Comment From: sundb
@rainfordream This should not be related to the config, no matter what redis will not convert 012345 to an integer.
Please use redis-cli and GET test command to check the response.
Comment From: rainfordream
There is no problem with the GET command. Will it have something to do with server serialization?
Finally, we changed the solution, adding an A_ splicing 0123456 in front, and then reported an error, showing com.alibaba.fastjson.JsonException: syntax error, pos 1, json:A_123456
Comment From: rainfordream
But there is no problem running these locally, but there are problems when they are connected to the server. This is where I am confused.
Comment From: sundb
It looks like it might have something to do with your server serialization, as you can see from your exception that the server is trying to parse json:A_123456 as a json, but it should be json: "A_123456".
Before that you should have json:0123456, which fastjson automatically converts to a number.
If both your local and server reply with 0123456, then you should try to confirm why they are not serialized in the same way, perhaps because the version of fastjson is not the same.
Comment From: rainfordream
Thank you very much.