Asynchronous Reserve Finally failed?

[Former Member]

Can someone explain to me why I continually see this error in the DTR log file:

asynchronous reserveFinally failed: missing name server configuration, no logon known -> operation will be retried name reservation : name server=http://nwdiserver:55000/,  category=SAP_DevelopmentComponentName, name=example.com/test/test/dc, reservationKey=6505225, state=FINALIZE_PENDING

The SLD has been configured to be a Name Server as well as a SLD. The Supplier Bridge has been configured, and data has successfully been transferred.

So what does this message really mean?

[Former Member]

I know that this may be a bit too late to reply to this thread, but somebody just pointed me out to this query and so I will try to clarify what is happening a bit more in detail.

When you create some objects in the NetWeaver Developer Studio (NWDS) whose names need a reservation (like dictionary files, DC definitions, etc.), the NWDS sets up a special 'name reservation' property on such a file after adding it to DTR.

The property tells DTR that a preliminary name reservation was done by the NWDS on the name server and after check-in, DTR is supposed to finalize the name reservation. The property also tells DTR on which name server the name has to be reserved - since there could be multiple name servers in a landscape. DTR records such an entry in its 'name-reservation queue' and marks it as being preliminarily-reserved.

However, the property does not provide the authorization details of the name server to DTR i.e., DTR has no mechanism to connect to the name server until the administrator or CMS configures the name server in DTR with the appropriate credentials.

The finalization itself is an asynchronous operation i.e., after the check-in is complete the name-reservation entry in DTR gets the new status of 'finalize-pending'. A background task in DTR picks up such pending reservations, tries to see if the name server is registered with DTR and if so, contacts the name server and finalizes the name reservation. If the file was reverted, then the reservation gets the status 'revert-pending' and DTR reverts the preliminary reservation from the name server.

If a developer has checked-in a file with a name reservation pointing to 'old-name-server' and in the meantime if the name server was relocated to 'new-name-server', then DTR does not have a mechanism to contact the old-name-server anymore. And that is when you get the 'missing name server configuration' error.

As you see in the error message, DTR does not yet give up on the reservation. So, if you configure the old name server once again, then when the background task runs the next time, it will successfully reserve the name on the old-name server.

Currently, there is no possibility to edit such name reservation entries in DTR's queue and change their URLs to point to the new name server.

In a future release, this mechanism of finalization of reservations via DTR will be completely removed. The reservations will be handled directly by the NWDS.

Here is what I would suggest before you relocate your name servers:

Use the <a href="http://host:port/dtr/sysconfig/support/NameReservationList">http://host:port/dtr/sysconfig/support/NameReservationList</a>

URL to check if there are any entries in the REVERT_PENDING or FINALIZE_PENDING state.

If so, wait for a few minutes for the background task to process these entries. But make sure that the name server mentioned in the queue is indeed configured in DTR via the URL:

<a href="http://host:port/dtr/system-tools/administration/NameServerConfiguration">http://host:port/dtr/system-tools/administration/NameServerConfiguration</a>.

You can also check when the background task last ran via the following URL:

<a href="http://host:port/dtr/sysconfig/scheduled_tasks.html">http://host:port/dtr/sysconfig/scheduled_tasks.html</a>

(the task ID is 'ProcessNameReservationsTask').

Only when there are no more reservations pending, then you should reconfigure the nameserver.

If you did not take care for the above steps, then you need to add the name server configuration to DTR as Adrian explained.

- Girish

[Former Member]

Check the Nameserver Configuration of your DTR: It seems to be missing logon credentials.

http://<hostname>:<port>/dtr/system-tools/administration/NameServerConfiguration

Also make sure you use fully qualified domain names.

[Former Member]

One nameserver was defined, however, the FQDN of the SLD nameserver was not defined. I've corrected that.

BTW, the Key Store field was blank - is this an issue?

[Former Member]

Was there anything more to this story? I've been getting the exact same error, but we're using the FQDN of the Name Server.

(I just started getting an "Error - Check log for details" message in NWDS. Upon checking the log, I see I've been getting the precise message you quote ever since we've had the NWDI installed. My names do actually get reserved in the Name Server. Evidently the problem has something to do with an operation that completes the name reservation. My NWDI is SP 15, my NWDS SP 13.)

[Former Member]

I have the same issue, also running NWDI sp15 and NWDS sp9

I get the following error on default trace:

<b>asynchronous reserveFinally failed:</b> missing name server configuration, no logon known -> operation will be retried name reservation : name server=http://<<i>host</i>>:50000/, category=SAP_DevelopmentComponentName, name="<i>vendor.com</i>"/java/siar/gr/batch, reservationKey=55393723, state=FINALIZE_PENDING

Any ideas??

is this a known bug of sp15?

thanks in advance

Adrian

[Former Member]

Make sure you have at least one NameServer defined in the DTR NameServer Configuration: Since SP14 or 15 this seems to be mandatory if you do not want to get the errormessage you are experiencing.

[Former Member]

Hi

I have one NameServer defined in the DTR NameServer Configuration . these are the parameters:

<b>URL:</b> http://<<i>host</i>>:50000/sld/cimom

<b>User:</b><i>j2ee_admin</i>

<b>Pwd:</b> *****

<b>Trust Store:</b>TrustedCAs

<b>Key Store:</b>

The user was previously <i>cmsadm</i>, but i change it yesterday, just to check.

are these the correct ones?

thanks adrian

[Former Member]

From a security perspective you should not use j2ee_admin, but a dedicated user for Name Reservation with security role LcrInstanceWriterNR. <a href="http://help.sap.com/saphelp_nw04/helpdata/en/4e/90a43f4aa1330ee10000000a114084/frameset.htm">Check here for more info</a>.

[Former Member]

Besides of that, is there anything else wrong with the configuration, I have already reset the user so now it uses CMSADM instead of j2ee_admin.

I also check that uses CMSADM has the security role LcrInstanceWriterNR

thanks adrian

[Former Member]

We submitted an OSS note on this. Consistent with Pascal's advice, SAP's reply was to give the user (CMSADM) the security role LcrInstanceWriterNR. We did that, but it hasn't solved the problem. I will post whatever resolution we eventually find.

(They also emphasized the importance of having NWDS and NWDI on the same SP level, but that is not the cause of the "finallyReserve" problem.)

[Former Member]

I got it!!!!

first, all entries in the *_SUCCEEDED and *_FAILED queues on

http://server:port/dtr/sysconfig/support/NameReservationList are final,

i.e. once a reservation got this status, it won't be picked up by DTR's

background task.

Additionally, a name reservation task will be processed always with the

same Name Server configuration which was valid on task creation. If you

change the Name Server URL in the meantime, DTR will still trying to

connect the old Name Server (see the URL in the log entry you have

provided).

If you still have entries in the *_PENDING queues you can give a try to

specify http://server:port/ as a 2nd Name Server under

http://<i>server:port</i>/dtr/system-tools/administration/NameServerConfiguration with the same user credentials as 1st name server http://<i>server:port</i>/sld/cimom.

After some minutes the queue will be processed.

it really works

that all focks

Message was edited by: Adrian Vindel

[Former Member]

Fantastic! Yes, that worked for me. In fact, my OSS response from SAP refers to this thread and your solution (saying they are unable to recreate the problem themselves).

In your opinion, is the root problem a bug?

[Former Member]

Hi Adrian,

Your solution works over here as well.... though temporarily: the 2nd nameserver definition keeps vanishing. It get the feeling that this is populated by the SLD: There's only one nameserver definition in the SLD (Technical Landscape -> System Landscape Directory) and that uses sld/cimom as URL.

Do you have this same problem?

Kind regards,

Pascal

[Former Member]

Yes pascal, i have the same problem, the second server keeps "vanishing" and i have to repeat this operation again

you know,**** happens

Message was edited by: Adrian Vindel

[Former Member]

Good to read that you're having this same issue... Obviously something for SAP to fix.

We'll probably create a customer message for this. I'll keep you posted.