Opened 12 years ago
Closed 9 years ago
#2761 closed defect (expired)
Camd35 and cachex3 create duplicate users for got cache
Reported by: | superg1972 | Owned by: | Corsair |
---|---|---|---|
Priority: | major | Component: | Protocol - Camd3 |
Severity: | high | Keywords: | CACHE-EX |
Cc: | CapNCooK | Sensitive: | no |
Description
Revision
7437 and above
Issue Description
after the change of corsair, something is broken with cacheex mode 3 and camd35. There are duplicates in the users (it is like disconnections and reconnetctions)
When the issue occurs
Using 7437 and above with 7426 the issue is not present
How the issue is reproducable
Use cacheex 3 with camd35 to get cash.
Change History (17)
comment:1 by , 12 years ago
Cc: | added |
---|---|
Keywords: | CACHE-EX added |
Owner: | set to |
comment:2 by , 12 years ago
We have tested the 7443, but unfortunately the issue continue to be present.... multiple logins on same user. It is the reader (with oscam more than 7436) that loose the connection and create a new one. on the other side (with oscam 7426) you see multiple logins on the user and multiple same client in the cacheex tab.
comment:3 by , 12 years ago
I wonder if the double-connection issue is only camd35 related..
See this screenshot, i think this is the symptom you see also ?
http://i45.tinypic.com/2lue8gh.jpg
--
I have only cc-cam peers connected....
comment:4 by , 12 years ago
We have just tested the 7450 and unfortunately the reader replicates the logins. The results is in the other oscam that could have a lower version (tested with 7426) will have in the Cacheex tab multiple clients with the same user, got and hits.
Getting Client xxxxxxxxxxx REVERSE CACHE PUSH 0 341 48
Getting Client xxxxxxxxxxx REVERSE CACHE PUSH 0 341 48
Getting Client xxxxxxxxxxx REVERSE CACHE PUSH 0 341 48
Getting Client xxxxxxxxxxx REVERSE CACHE PUSH 0 341 48
comment:5 by , 12 years ago
Tested with 7452 (camd35-cacheex) on the oscam with the reader and the issue is still present. On the client the logins are duplicated.
comment:7 by , 12 years ago
I personally tested the 7456. On my side i didn't get any issue, but i got feedbacks from the other peers that i was duplicating the logins on their oscam.
comment:8 by , 12 years ago
A small update... with 7456 the duplication is less than before.... we have 2 or maiximum 3 duplicates only in certain moments.
comment:9 by , 12 years ago
In the oscam where is set the reader (and so the oscam that will create multiple connections on the other side), the error that is shown is:
2012/09/19 12:52:17 62D588 p superg_cache [camd35] disconnected: reason rto
comment:10 by , 12 years ago
Not completely on topic, but for me this build (7456) is:
- Causing 250% CPU
- Causing rising RAM (15.0 in 30 minutes / 2GB)
- Causing my total cache-size to drop to avg 200 (normally avg 2000)
- Freezes on cache
Since i have no camd35 readers, only some users, i cannot report duplicate connections.
comment:11 by , 12 years ago
Tested 7473... the issue with camd35 still perisist
Getting Client test 192.168.1.100 2E147xx REVERSE CACHE PUSH 0 788 0 0 0
Getting Client test 192.168.1.100 2E147xx REVERSE CACHE PUSH 0 788 0 0 0
Getting Client test 192.168.1.100 2E147xx REVERSE CACHE PUSH 0 788 0 0 0
Getting Client test 192.168.1.100 2E147xx REVERSE CACHE PUSH 0 788 0 0 0
Getting Client test 192.168.1.100 2E147xx REVERSE CACHE PUSH 0 788 0 0 0
Getting Client test 192.168.1.100 2E147xx REVERSE CACHE PUSH 0 788 0 0 0
Getting Client test 192.168.1.100 2E147xx REVERSE CACHE PUSH 0 788 0 0 0
2012/09/20 13:35:45 749648 p test [camd35] disconnected: reason rto
2012/09/20 13:35:46 749648 p test [camd35] connecting to 192.168.1.200:12445
comment:12 by , 12 years ago
About my post above..
Now testing with 7474, and this seems to be solved.
Can't tell anything about the disconnects/dupl. connections because i have CC-Cam peers only.
Please test duplicate connections issue with 7474
comment:13 by , 12 years ago
Unfortunately the issue of the multiple connection has not been fixed. Tested with 7475 on the server that push the cache and 7190 on the server that get the cache (camd35).
Getting Client quelo_cache REVERSE CACHE PUSH 0 3788 1465
Getting Client quelo_cache REVERSE CACHE PUSH 0 3788 1465
Getting Client quelo_cache REVERSE CACHE PUSH 0 3788 1465
Getting Client quelo_cache REVERSE CACHE PUSH 0 3788 1465
comment:14 by , 12 years ago
The issue is also present with a camd35 cache3 setup. Changed the reconnect timeout to 960 on the reader, but on one server still duplicate logons. Bypassed the issue with drop duplicate users.
comment:16 by , 11 years ago
Unfortunately in 8680 the problem still presents :(. Please look after what's going on, because the camd35 protocol is much better than cccam, and why do we use cccam protocol, if we have a better one?
comment:17 by , 9 years ago
Resolution: | → expired |
---|---|
Status: | new → closed |
Also tested, with cc-cam only / cache-ex only server.
Also crashing within 2 minutes.
Therefore => ticket title is not correct i think, but i leave this for now.
--
Last version that does not crash for me with cache-ex: still 7190
Also, suggested job-queue fix in 7437 (too much DNS lookups fix) is not giving expected (fixed) behaviour. Jobqueue still fills up until 'dirty fix' to prevent this kicks in.. (delete job queue > 20)
@corsair: If some debuglog is needed, please tell me what you need.