Bug #19076 | MaxDB Sync Manager not usable over volatile networks | ||
---|---|---|---|
Submitted: | 13 Apr 2006 16:16 | Modified: | 7 Jan 2008 11:12 |
Reporter: | Christopher Kocmoud | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MaxDB | Severity: | S1 (Critical) |
Version: | 7.6 | OS: | Windows (Windows XP) |
Assigned to: | CPU Architecture: | Any |
[13 Apr 2006 16:16]
Christopher Kocmoud
[13 Apr 2006 19:15]
Christopher Kocmoud
Severity changed. Did not read the severity level explanations when bug report was submitted.
[14 Apr 2006 16:38]
C.J. Adams-Collier
Hello! It's good to hear of another Synchronization Manager use case. I've spoken with the devs recently, and their time is being spent on other projects right now, so this may not be completed in a timely manner. I'll pass it on to them though. Cheers, C.J.
[18 Apr 2006 11:55]
Wolfgang Auer
Hello Christopher, It was intended that all active topic subscribers are set to an inactive state when a socket exception occurs, and a restart the message server is not necessary. The sync service should reconnect to the message server without problems. We tested this by terminating the sync services with [CTRL] [C]. In your case the message service does not detect that the socket is broken. C.J. will open a ticket for us and we will fix the problem in one of the next releases. Your idea of periodically attempting to reestablish the TCP socket connection will be set on your plans for the further Synchronization Manager development. regards Wolfgang
[18 Apr 2006 16:00]
C.J. Adams-Collier
Hello! I've spoken again with the syncman dev team. They tell me that they will put some time into addressing this issue for the next release. Thank you for the submission of this issue. C.J.
[18 Apr 2006 18:50]
Christopher Kocmoud
Thank you for all your comments. It's reassuring to get such great feedback from support! We were aware of how the Sync Mgr was *intended* to be used. We are evaluating MaxDB/SyncMgr for use with a mobile Toughbook that intermittently leaves the WiFi range of the primary database station for data collection. Once it re-enters the WiFi footprint, we were hoping it would "automatically" re-sync and bidirectionally propogate DB changes. Sounds like this may happen, resources permitting, in the next release. Thanks!
[10 May 2006 16:28]
C.J. Adams-Collier
http://www.sapdb.org/webpts?wptsdetail=yes&ErrorType=0&ErrorID=1141392 Feature planned to be added in 7.6.0.30
[10 Sep 2007 8:34]
Wolfgang Auer
Solution has been submitted. http://www.sapdb.org/webpts?wptsdetail=yes&ErrorType=0&ErrorID=1141392 regards Wolfgang