hgetall fails on key with large number of fields about mod-redis HOT 16 CLOSED

i can't seem to be able to reproduce your error...

from mod-redis.

Hi - many thanks for looking at this...

Weirdly your test case as you have written it passes for me until I replace:
args.add("123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890");
with:
args.add("1234567890");

Then I get the failure exceptions as above.

from mod-redis.

i've tried with 1234567890 and it did nothing, so i increased it to the big one and still no issue..., maybe it could be related to a specific OS, JVM version, REDIS version? can you details what versions are you using?

from mod-redis.

For the client I'm running it on Windows 7:

• mod-redis 1.1.4
• vertx 2.0.2
• jdk1.7.0_9

Redis I'm running on Centos 6.5 (although I get the same issue when running the Windows Redis port)

• redis 2.8.17

The client side is a development environment (I found the issue in a unit test). Production will all be Centos 6.5 with OpenJDK 1.7, so I will try that when I get a moment and report back

from mod-redis.

i am testing on ubuntu 14.04lts 64
redis 2.8.4
vert.x 2.1.2
git master

and it works, i tried to downgrade to 2.0.2-final (vert.x) and it still passed...

from mod-redis.

i've also upgraded redis to use this ppa:
https://launchpad.net/~chris-lea/+archive/ubuntu/redis-server

and still no signs of the bug...

from mod-redis.

i might think this is comming from the network between your machine and the redis server...

from mod-redis.

ok thanks - I'll try with it all components running co-hosted on the same Centos 6.5 server and I'll report back.

from mod-redis.

I've retested in our production environment, Centos 6.5 with all dependencies upgraded to the latest version and can't duplicate the issue which is great news.

With all the latest dependencies I still get the issue in my development environment - it fails some of the junit integration tests during the maven build. I'm actually thinking the issue may related to the vertx testtools which is a bit of a pain as I will have to slacked off some of the tests to get a build.

Anyway thanks very much for looking into this - I think I can work around the issue now.

from mod-redis.

I'm having similar issues...
my pre-condition is:
using the hgetall command on a remote redis server (i.e. not localhost) with a greater latency rate than the rate of executing the command...
e.g. : sending hgetall every 100ms ... and the full response takes more than 100ms to arrive (or related to pipelining)..

I think it's happening because of the way you are using the Buffer object in ReplyParser class to handle the async inputs...

from mod-redis.

why have you closed this?

from mod-redis.

Because the issue is not reproducible, if you can provide an working example showing it I will investigate further.

from mod-redis.

Interesting approach ... the fact it is not reproducible by you does not mean that it is eligible for closing. What about @elad-yosifon ? Once closed, once somebody hits the same issue and visits this project, it is possible he does not find it among closed ones (why would he try to find it among closed issues anyway) hence he submits another one.

however ... your project, your issues :)

from mod-redis.

It's a prerequisite for any issue that it needs to be reproducible and
the onus is on the person who reported the issue to provide a reproducer.

This is not something specific to Vert.x, it's a completely standard
approach used by any project I have worked on in the last 20 years.
You'd be hard pushed to find a high profile project that does not do
this. Including JBoss, Eclipse, Apache, Oracle, SpringSource, Pivotal etc

On 05/07/15 10:27, Štefan Miklošovič wrote:

Interesting approach ... the fact it is not reproducible by you does
not mean that it is eligible for closing. Once closed, once somebody
hits the same issue and visits this project, it is possible he does
not find it among open ones hence the submits another one.

however ... your project, your issues :)

—
Reply to this email directly or view it on GitHub
#26 (comment).

from mod-redis.

If the issue can be reproduced, the issue can be-opened. Closed issues do not "disappear".

from mod-redis.

@smiklosovic 9 months ago there was a test added to the project with the details of this issue, the test passes on our machines and also on the CI environment, there isn't much more I can do unless someone provides a different reproducer:

https://github.com/vert-x/mod-redis/blob/master/mod/src/test/java/io/vertx/redis/Issue26.java

If the issue affects you, please update the test to show the bug and then I can investigate further, otherwise it is like a needle on a haystack

from mod-redis.