2

I have an intermittent issue when distributing indexes :( All servers are Windows Server 2008.

I have two servers to distribute to and one of them has failed twice with this error:

INFO: [MDEXHost1] Starting shell utility 'move_dgraph-input_to_dgraph-input-old'.
10-Jun-2015 06:08:36 com.endeca.soleng.eac.toolkit.script.Script runBeanShellScript
SEVERE: Utility 'move_dgraph-input_to_dgraph-input-old' failed.

With a bit of further digging I've found this error in a log file in the PlatformServices\workspace\logs\shell folder:

Failed to move D:\Firebird\config\script\..\..\.\data\dgraphs\Dgraph1\dgraph_input to
D:\Firebird\config\script\..\..\.\data\dgraphs\Dgraph1\dgraph_input_old: No such file or directory at -e line 1.

The state of the server is that is has a dgraph_input_new folder but it's struggling to create the dgraph_input_old folder. The dgraph_input folder does exist so the 'No such file or directory' is interesting.

The server has plenty of disk space for the operation and as it's intermittent I don't think it's file/folder permissions (otherwise it would fail all the time). I've even asked for on-access virus scanning to be disabled for those folders in case our virus scanner was locking files/folders.

I'm struggling to come up with a resolution to the issue, HALP!

EDIT: The forge process did stop the dgraph but the TomCat6 process is still running. Is that normal? Could TomCat be locking the folder?

EDIT: The task to move the folder is a bit of Perl that looks like this:

perl.exe -e "use strict; use File::Spec; use File::Copy; use File::Glob qw/:glob/;my $source = 'D:\Firebird\config\script\..\..\.\data\dgraphs\Dgraph1\dgraph_input'; $source =~ s/[\\\/]+$//;my @sources = bsd_glob($source); foreach my $file (@sources) {my @fromPath = File::Spec->splitdir($file); if (scalar @fromPath eq 0) { die \"Failed to split path: $!\"; } my $fromRelative = @fromPath[scalar @fromPath - 1];my $toFile = 'D:\Firebird\config\script\..\..\.\data\dgraphs\Dgraph1\dgraph_input_old'; if ( -d $toFile ) { $toFile =File::Spec->catdir($toFile, $fromRelative); } my $res = move($file, $toFile);if (! $res) { die \"Failed to move $file to$toFile: $!\"; }}"

EDIT: It seems to be a plain permission issue, I can't rename the folder without elevating myself to an administrator. The service is running as a user who's in the Administrators group. What could happen to make this folder admin only?

GogLlundain
  • 552
  • 4
  • 9
  • Do you have this directory `D:\Firebird\data\dgraphs\Dgraph1\dgraph_input_old` ? – KrishPrabakar Jun 23 '15 at 13:31
  • No, I have `dgraph_input` and `dgraph_input_new` – GogLlundain Jun 23 '15 at 13:51
  • Create the folder `dgraph_input_old` manually and rerun your script. – KrishPrabakar Jun 23 '15 at 14:02
  • I'm hoping to find the root of the intermittent issue so that I don't have to nurse the Forge. I did try it and it still fails, I'm running the Perl directly which I've added to the original post. – GogLlundain Jun 23 '15 at 14:13
  • Further to this issue the dgraph was terminated (by the Forge process) and didn't ever come back to life again. There weren't any interesting log file entries to be found on the box, to resolve we un-installed and re-installed the Endeca software. We left the application files alone. This brought the service back into a healthy state. We'll need to see if this dgraph will accept further updates once we run the baseline update. I'll update the thread once that's happened. – GogLlundain Jun 24 '15 at 12:51

1 Answers1

0

I know this question is dated back 3 years ago. But recently i experienced the same issue, thought it could help others.

The logs were interesting as GogLlundain pointed out.

The way to solve this is.

  1. Stop mdex server in the workbench which will in parallel kill dgraph process too.
  2. If you open the task manager in the server where mdex is defined, you can find two dgraph.exe is running.
  3. Kill the older task(i.e dgraph.exe) then run the baseline script, Your process will run smoothly.
Bananas
  • 141
  • 12