Lock errors using eclipse over the internet

[pokrakam]

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.

---Edit---:

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.

[Wozza]

I know this is an old thread, but wanted to say for users working on ABAP Cloud (BTP) there is a user sessions Fiori app, you can use that to kill your sessions and release the locks.

[Armin_Beil]

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,
Armin

[pokrakam]

Hi armin.beil.2,

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.

Thanks,

Mike

[V]

Is there any progress? The problem still exists for us. Why does this happen with ADT and not in SE80 via SAP GUI?

[Armin_Beil]

Hello Vß. No, unfortunately there is no progress. We didn't get the necessary time budget to further work on this. Do you have the situation reproducible and could you create a customer case ('OSS Ticket')?