TREX: IndexmanagementService error HTTP server error 407

[Former Member]

Hello,

the TREX-Index of our installation seems to be dead.

In the TREX-Monitor - Server Status all lights are green (both HTTP- and name-server) but in index monitor our indices are marked with the status red.

The application log says: "Error 04.08.05 09:47:51 IndexmanagementService Communication error. HTTP server error: 407 (Errorcode 7266)",

the http-error 407 means: "Proxy authentication required"

The message seems to be wrong, as we never configured the portal to use a proxy - has anyone out there an idea?

More symptoms:

In TREX-Monitor - Display Index Details the Drop-Down-List of "Index-ID" is empty

In TREX-Monitor - Change Queue Status I got the error:

com.sapportals.wdf.WdfError

(...)

The portal search says:

Search Failure

Error during search occurred - com.sapportals.wcm.WcmException: HTTP server error: 407 (Errorcode 7266)

An unexpected severe error occurred during the search call. If the situation persists, inform your system administrator.

[Former Member · Accepted solution]

1) did this constallation ever worked?

2) is there a proxy between two machines?

3) can you do dns resolution to the right host and ping it in cmd.exe?

regards,

dimitry

[Former Member · Accepted solution]

thank you very much for this extremly fast reply

1) did this constallation ever worked?

yes - until yesterday, 11:30 am... the most important change was that we deleted our test-collaboration-rooms

2) is there a proxy between two machines?

no

3) can you do dns resolution to the right host and ping it in cmd.exe?

both ping and the usage of http://YBNQ000R3.deoko.zeiss.org:30005/TREXHttpServer/TREXISAPIExt.dll as an url in a browser works fine

[Former Member]

what ever happened - the index is running

thank you for your help

[Former Member]

we know now what happened...

one of our custom-made applications uses a proxy-connection, defined within the program.

after using this connection, the whole portal 'believes' that this connection is the one and only.

our workaround was to create in service configuration / com.sap.portal.ivs.httpservice a full, never needed procy-configuration with bypasses.

can anyone explain, why the proxy-settings in an encapsulated application influence the complete system?