Протокол буферизует вход
В нашем бизнесе мы требуем для входа каждого запроса/ответа который, приезжая в наш сервер. В это время, будучи, мы используем xml в качестве стандартной реализации. Файлы журнала используются, если мы должны отладить/проследить некоторую ошибку.
Мне довольно любопытно, если мы переключаемся на буферы протокола, так как это является двоичным, каков будет лучший способ зарегистрировать запрос/ответ в файл?
Например:
FileOutputStream output = new FileOutputStream("\\files\log.txt");
request.build().writeTo(outout);
Для кого-либо, кто использовал буферы протокола в Вашем приложении, как Вы регистрируете свой запрос/ответ, на всякий случай нам нужен он для отладки цели?
2 ответа
Мы используем метод ShortDebugString () объекта C ++ для записи удобочитаемой версии всех входящих и исходящих сообщений в текстовый файл. ShortDebugString () возвращает однострочную версию той же строки, возвращаемой методом toString () в Java. Не уверен, насколько легко сделать то же самое на Java.
Если у вас есть конкурирующие потребности в протоколировании и производительности, то я полагаю, вы можете сбрасывать двоичные данные в файл как есть, при этом, возможно, каждой записи будет предшествовать тег, содержащий метку времени и значение длины, чтобы вы знали, где заканчивается этот конкретный бит данных. Но спешу признать, что это очень некрасиво. Вам придется написать утилиту для чтения и анализа этого файла, и без нее вы будете беспомощны.
Более разумным решением было бы выгрузить двоичные данные в текстовом виде. Я думаю о "строках" текста, опять же, начиная с любой информации о метках, которую вы считаете уместной, затем информация о длине в десятичном или шестнадцатеричном формате, затем столько шестнадцатеричных байт, сколько необходимо для сброса вашего буфера - таким образом, вы можете получить довольно длинные строки. Но поскольку файл структурирован по строкам, вы можете использовать для работы с ним текстовые инструменты (в простейшем случае редактор). Шестнадцатеричный дамп, по сути, означает, что вы используете два байта в журнале для представления одного байта данных (плюс немного накладных расходов). В наше время дисковое пространство стоит дешево.
Если эти двоичные буферы имеют достаточно последовательную структуру, вы можете даже разделить и обозначить поля (или что-то вроде этого), чтобы ваши данные стали немного более читаемыми и, что более важно, более удобными для поиска. Конечно, вам решать, сколько усилий вы хотите приложить, чтобы ваши записи журнала выглядели красиво; но время, потраченное здесь, может окупиться немного позже при анализе.