#!/usr/bin/perl -w
###Подключение всех необходимых модулей###
use strict;
use POSIX;
use POSIX ":sys_wait_h";
use IO::Socket;
use IO::Handle;
###Создаем процесс-демон###
my $pid= fork();
exit() if $pid;
die "Couldn't fork: $! " unless defined($pid);
###Создаем связь с новым терминалом###
POSIX::setsid() or die "Can't start a new session $!";
###Переменная - бесконечное время жизни сервера###
my $time_to_die =0;
###Переменная - интернет-сокет или сервер###
my $server;
###Функция обработчик сигналов INT и TERM###
###Она срабатывает перед этими сигналами###
sub signal_handler{
  $time_to_die = 1;
  close($server);
}
$SIG{INT}= $SIG{TERM} = $SIG{HUP} = \&signal_handler;

###Функция обработчик сигнала CHLD - для уборки процессов зомби ###
sub REAPER {
  while ((my $waitedpid = waitpid(-1,WNOHANG)) > 0) { }
  $SIG{CHLD} = \&REAPER
}

###Заполняем массив разрешенных команд при старте сервера###

###Создаем интернет сокет на порту 17403###
my $server_port=17403;
$server= new IO::Socket::INET(LocalPort => $server_port,
                 TYPE => SOCK_STREAM,
                 Reuse => 1,
                 Listen => 10)
or die "Couldn't be a tcp server on port $server_port: $@\n";
###Сервер работает до бесконечности пока его не вырубит Term ###
until($time_to_die){
  my $client;
  my $req;
  ###Обрабатываем входящие подключения
  while($client = $server->accept()){
    ###Включаем обработку зомби###
    $SIG{CHLD} = \&REAPER
    ###Тот который постучался, отделяем в отдельный процесс###
    defined(my $child_pid=fork()) or die "Can't fork new child $!";
    ###Родительский процесс идет в конец и ждет следующего подключения###
    next if $child_pid;
    ###Дочернему процессу копия сокета не нужна, её закрываем###
    if($child_pid == 0) {
      close($server);
    }
    ###Очистка буфера###
    $client->autoflush(1);
    my $response = <$client>;
    my @get_req = split(' ', $response);
    print $client $get_req[1];
  exit;
  }
  continue {
    close($client);
  }

}

* This source code was highlighted with Source Code Highlighter.

У меня есть код, который дает идентификатор пользователя утилите, которая затем отправляет email этому пользователю.

emailUtil.sendEmail(userId, "foo");

public void sendEmail(String userId, String message) throws MailException {
    /* ... logic that could throw a MailException */
}

MailException может быть брошен по ряду причин, проблем с адресом email, проблем с шаблоном почты и т.д.

Мой вопрос заключается в следующем: вы создаете новый тип исключения для каждого из этих исключений, а затем обрабатываете их по отдельности или создаете один MailException, а затем сохраняете что-то в исключении (что-то машиночитаемое, а не текст описания), что позволяет нам делать разные вещи на основе того, что на самом деле произошло.

Edit: как уточнение, исключения не предназначены для журналов, а что-нет, это относится к тому, как код реагирует на них. Чтобы продолжить работу с примером mail, предположим, что когда мы отправляем почту, она может потерпеть неудачу, потому что у вас нет адреса email, или потому что у вас нет действительного адреса email, или она может потерпеть неудачу.. и т.д.

Мой код хотел бы реагировать по-разному на каждую из этих проблем (в основном путем изменения сообщения, возвращенного клиенту, но и фактической логики).

Было бы лучше иметь реализацию исключения для каждой из этих проблем или одно зонтичное исключение, которое имело бы что-то внутреннее (например, перечисление), что позволило бы коду различать, какая проблема была.

Я сталкиваюсь с некоторыми узкими местами производительности, когда мой клиент C# вставляет массовые данные в базу данных SQL Server 2005, и я ищу способы ускорить этот процесс.

Я уже использую SqlClient.SqlBulkCopy (который основан на TDS) для ускорения передачи данных по проводу, что очень помогло, но я все еще ищу больше.

У меня есть простой стол, который выглядит так:

 CREATE TABLE [BulkData](
 [ContainerId] [int] NOT NULL,
 [BinId] [smallint] NOT NULL,
 [Sequence] [smallint] NOT NULL,
 [ItemId] [int] NOT NULL,
 [Left] [smallint] NOT NULL,
 [Top] [smallint] NOT NULL,
 [Right] [smallint] NOT NULL,
 [Bottom] [smallint] NOT NULL,
 CONSTRAINT [PKBulkData] PRIMARY KEY CLUSTERED 
 (
  [ContainerIdId] ASC,
  [BinId] ASC,
  [Sequence] ASC
))

Я вставляю данные в блоки, которые в среднем составляют около 300 строк, где ContainerId и BinId являются постоянными в каждом блоке, а значение последовательности равно 0-n, и значения предварительно сортируются на основе первичного ключа.

Счетчик производительности %Disk time тратит много времени на 100%, поэтому ясно, что диск IO является главной проблемой, но скорость, которую я получаю, на несколько порядков ниже, чем у необработанной копии файла.

Поможет ли это кому-нибудь, если я:

1. Отбросьте первичный ключ, пока я выполняю вставку, и воссоздайте его позже
2. Сделайте вставки во временную таблицу с той же схемой и периодически переносите их в основную таблицу, чтобы сохранить размер таблицы, в которой происходят вставки, небольшим
3. Что-нибудь еще? --

Основываясь на полученных ответах, позвольте мне немного прояснить ситуацию:

Портман: я использую кластеризованный индекс, потому что когда все данные будут импортированы, мне нужно будет обращаться к данным последовательно в этом порядке. Мне не особенно нужно, чтобы индекс был там при импорте данных. Есть ли какое-либо преимущество в том, чтобы иметь некластеризованный индекс PK при выполнении вставок, а не полностью отбрасывать ограничение для импорта?

Chopeen: данные генерируются удаленно на многих других машинах (мой сервер SQL в настоящее время может обрабатывать только около 10, но я хотел бы иметь возможность добавить еще). Нецелесообразно запускать весь процесс на локальном компьютере, потому что тогда ему придется обрабатывать в 50 раз больше входных данных, чтобы генерировать выходные данные.

Джейсон: я не делаю никаких параллельных запросов к таблице во время процесса импорта, я попробую удалить первичный ключ и посмотрю, поможет ли это.