Skip to Content

Lock errors using eclipse over the internet

Update 1: I found out how to reproduce the issue fairly reliably, see end of post.

Update 2: I found the root cause involves a dump and does seems to originate from Azure/SAP combination, see my answer below.

When I use my local eclipse to connect to a cloud instance (Azure), I often see timeout and locking errors. There is no problem with the connection, via SAPGUI it is perfectly stable and when it works Eclipse is also generally quick. But then very randomly I'll hit a bump that goes something like:

Save -> spinning wheel for a while > message "Timeout getting a lock"

If I try again I see the message "Object could not be locked / User DEVELOPER is currently editing ZCL..."

I have to manually remove the lock via SM12 to continue working.

It seems to happen more often when I've left the system idle for a couple of minutes - but not always.

I have 200MB fibre broadband and experience no other internet issues. SAPGUI and remote desktop to the same instance is perfectly fine. I use VPN both inbound and outbound to work remotely all day long, there are no issues whatsoever other than using ADT.


I've been trying to observe a pattern, it seems to mainly happen on generation and code changes, but NOT save. The following procedure reproduces it quite often:

  1. Open SM12, view locks
  2. Open a class, make a change, activate.
  3. Make another change. You should now see the padlock and the * (change indicator) in the tab to indicate that it is locked and changed.
  4. Leave it for 10-15 minutes
  5. SM12 should still show it's locked
  6. Save the class -> success. The * is no longer in the tab but the padlock is still there.
  7. SM12 should still show it's locked
  8. Ctrl-F3 to activate -> spinny wheel -> Object could not be locked, locked by <your userid>

If you close and re-open, the last change is still there, so it definitely saved under the existing lock. But you can no longer edit until you remove the lock in SM12.

Something is definitively fishy and it's not at my end.

I'm using the latest Eclipse Oxygen with latest ADT on a Mac. I will try it on a Windows VM when I have some more time.

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

5 Answers

  • Jun 14, 2018 at 12:37 PM

    Hi Mike,

    Can you please check the nameserver entry in your /etc/resolv.conf?

    Depending whether your server is external please change the value e.g. to:

    #Using Google Nameserver


    Hope that helps,


    Add comment
    10|10000 characters needed characters exceeded

    • Hi Ingo,

      Good point to check, but didn't help. It was pointing to my router, which had my ISP and Google's NS.

      I changed it to Google, still did the same. I then entered the IP address directly into the SAPLogon config and still get the same behaviour.



  • Jan 11 at 02:11 PM

    Hi Mike and Community,

    I'm sorry for the slow progress, it was not possible for our team to work on this topic as much as we would like to.

    Meanwhile two problematic flows are well understood on our side. One was already described by Kjetil: ADT does not properly listen to the success-response of the lock request in case the lock request needs more than 30 seconds.

    The other problematic flow is unfortunately more difficult. The ADT locking concept is based on a stateful RFC connection. In case this connection completely breaks we are sufficiently prepared and no lock-yourself-situation happens. However in the situation that we discuss here it seems the RFC connection breaks in a way that makes it immediately unusable for the ADT client while at the same time the connection looks fine from the servers perspective. In fact the connection is still writable for the server on TCP layer. Therefore the ABAP server may need multiple minutes to detect that the network connection is actually broken and during that time frame the user currently faces zombie-locks.

    Unfortunately, I still cannot provide a correction date at the moment...

    We will also consider to automatically detect such situations and to perform a SM12-like deletion as a repair, but the final solution shouldn't repair but rather ensure that we just don't run into the problematic situation at all. Also an automated SM12-like deletion would not work for all developers, because there are surely developer roles without the necessary admin-authorizations.

    One more thing to add: The lock-yourself-issues occur after RFC connections break on a network layer or after requests hang for more than 30 seconds while they usually should take less than 1 second. Therefore, in case you experience these lock-yourself-issues regularly there is probably a network issue in your setup that regularly causes broken or hanging RFC connections. If you find a way to fix the network issue in your setup - for example in Ingo's case it was the wrongly configured nameserver - then the follow-up issues and the lock-yourself-issues will also be solved immediately.

    This also means that once we succeed to fix the robustness of the ADT locking mechanism this will only avoid that the lock-yourself-situations occur. The network issues including slow requests (might include hanging IDE) will remain unless you can fix the network root issue.

    @Mike: Since you wrote your network issues occur only with ADT I assume that you also expect the network root issue on SAP side. I will try to find a RFC expert that is willing to help you analyze the network root issue, but since SCN is not a official support channel (e.g. like customer incidents) I cannot guarantee the help of other SAP colleagues here.

    I'll provide an update once there is further progress from ADT side.

    Best regards,

    Add comment
    10|10000 characters needed characters exceeded

    • Hi Armin Beil,

      Thanks for your detailed response!

      I think there's a little more to it than a flaky network connection, for two reasons:

      1. It only happens with the combination of ADT and Azure. I have used ADT on flaky 3G mobile and hotel internet connections to an AWS instance many times, yet I have never experienced this issue with AWS.
      2. The failure is binary. Not some kind of 'if it takes longer than 1s'... When it fails I can often tell immediately as I get the MacOS spinning ball straight away. It's either broken and I wait 60 seconds, or it might occasionally be delayed a few seconds at most and it works. I never see 10, 15 or 30 second delays. So delays themselves don't seem to be the problem (you said as much).

      I tried one other thing: I used the Windows client from the CAL NetWeaver ABAP system on AWS to connect to a CAL NetWeaver ABAP instance on Azure: Same result. This conclusively proves it has nothing to do with my local setup.

      Just to be clear on the above test: Remote Desktop -> Windows instance on AWS -> Eclipse -> NetWeaver ABAP on Azure

      My best guess is that what you describe as "the RFC connection breaks in a way that makes it immediately unusable for the ADT client" is something that happens on Azure. Either it's something about Azure networking or perhaps the SAP systems are preconfigured differently when deployed onto Azure?

      Whichever the case may be, an SM12-type deletion seems just a plaster if it appears to be the case that there is a root cause that is not present on AWS.



  • Mar 17, 2018 at 01:48 PM

    Hi Mike,

    I could imagine, that the backend parameters are just set in a wrong way.

    Here's the link to the backend-configuration guide (Section More information).

    I would suggest you start first to check on those and see if it will fix the issue.


    Add comment
    10|10000 characters needed characters exceeded

    • No restart needed, it keeps the authentication, I just close the class, delete the locks and resume. Then it’s fine, until maybe I go get myself some coffee or write an email and boom, fail on next save, then locked by my other self.

  • Mar 31, 2018 at 09:39 PM

    OK, so after installing Eclipse on a Windows machine I found the same issue there too. Then I noticed a series of dumps that coincided with the lock failures.

    The dump is CALL_FUNCTION_ACCEPT_FAILED in SAPMSSY1 (RFC): Error while starting a Remote Function Call (ACCEPT).

    I pulled out an RFC trace which had a little more detail than the dump: It clearly comes from eclipse (FM SADT_REST_RFC_ENDPOINT), and complains that the gateway might be closed. But the thing is if I retry then it works. Can anyone shed some light?

    Here's the RFC trace file:

    **** Trace file opened at 20180331 210646 UTC, by disp+work                                                                                                    
    **** Versions SAP-REL 753,0,16 RFC-VER U 3 1782874 MT-SL                                                                                                      
    ======> CPIC-CALL: 'ThSAPCMRCV', communication rc: CM_DEALLOCATED_ABEND (cmRc=17), taskhandler rc: READ_FROM_GW_FAILED (thRc=239)                              
    Error with SAP gateway communication; check if SAP gateway is closed                                                                                          
    ABAP Programm: SAPMSSY1 (Transaction: )                                                                                                                        
    Called function module: SADT_REST_RFC_ENDPOINT                                                                                                                
    User: DEVELOPER (Client: 001)                                                                                                                                  
    Destination: NPL_752_openSAP (Handle: 1, DtConId: 00000000000000000000000000000000, DtConCnt: 0, ConvId: 26968172,{871330C0-3514-11E8-C5C0-ECC27F000001})      
    EPP RootContextId: 00000000000000000000000000000000, ConnectionId: 871330C0351411E8C5C0ECC27F000001, ConnectionCnt: 17                                        
    EPP TransactionId:                                                                                                                                            
    SERVER> RFC Server Session (handle: 1, 26968172, {871330C0-3514-11E8-C5C0-ECC27F000001})                                                                      
    SERVER> Caller host:                                                                                                                                          
    SERVER> Caller transaction code:  (Caller Program: SAPJCo31)                                                                                                  
    SERVER> Called function module: SADT_REST_RFC_ENDPOINT                                                                                                        
    Error RFCIO_ERROR_SYSERROR in /bas/753_REL/src/krn/rfc/abrfcpic.c : 3838                                                                                      
    CPIC-CALL: 'ThSAPCMRCV', communication rc: CM_DEALLOCATED_ABEND (cmRc=17), taskhandler rc: READ_FROM_GW_FAILED (thRc=239)                                      
    Error with SAP gateway communication; check if SAP gateway is closed                                                                                          
    Error RFCIO_ERROR_MESSAGE in /bas/753_REL/src/krn/rfc/abrfcio.c : 1985 

    Then I also looked into the Gateway trace and found a curious bit of info that seems to indicate that it's disconnecting its own public ("P") and local (L) network interfaces from each other:

    ***LOG Q0R=> GwReadFromRemGw, GwRead ( GwRead-006) [gwdp.c       4843]                                                                                
    Sat Mar 31 21:25:04:466 2018                                                                                                                          
    ***LOG Q0I=> NiIRead: P=; L= recv (110: Connection timed out) [/bas/753_REL/src/base/ni/nixxi.cpp 5430]            
    *** ERROR => NiIRead: SiRecv failed for hdl 223/sock 27                                                                                              
        (SI_ECONN_BROKEN/110; I4; ST; P=; L= [nixxi.cpp    5430]                                                        
    ***LOG S23=> GwDisconnectClient, client disconnected (237) [gwxxrd.c     11191]                                                                      
    GwDisconnectClient: client 237 disconnected, hostname = <my_public_hostname>, addr =, tp = sapdp00        
    *  LOCATION    SAP-Gateway on host vhcalnplci.dummy.nodomain / sapgw00                                                                                
    *  ERROR       connection to partner                                                                                                                  
    *              '<my_public_hostname>'                                                                          
    *              broken                                                                                                                                
    *  TIME        Sat Mar 31 21:25:04 2018                                                                                                              
    *  RELEASE     753                                                                                                                                    
    *  COMPONENT   NI (network interface)                                                                                                                
    *  VERSION     40                                                                                                                                    
    *  RC          -6                                                                                                                                    
    *  MODULE      /bas/753_REL/src/base/ni/nixxi.cpp                                                                                                    
    *  LINE        5430                                                                                                                                  
    *  DETAIL      NiIRead: P=; L=                                                                                      
    *  SYSTEM CALL recv                                                                                                                                  
    *  ERRNO       110                                                                                                                                    
    *  ERRNO TEXT  Connection timed out                                                                                                                  
    *  COUNTER     499                                                                                                                                    

    Add comment
    10|10000 characters needed characters exceeded

    • Hi Kjetil and Mike,

      thanks a lot for the additional input. We found a way to reliably reproduce the issue in our own dev systems and we made progress on the analysis. Since it's not just ADT we have to involve another software layer (JCo/RFC) in the analysis which might cost some additional time, but we are getting closer.

      I'll provide an update when it's fixed.

      Best regards,

  • Dec 07, 2018 at 03:06 PM


    Has anyone a recent update on this blogpost? Still looking for a solution.


    Add comment
    10|10000 characters needed characters exceeded