| Alexander 
 
   
 
						
						
					 | Date: 1/17/2012 
 
 
	
			У нас соединение одно. Если мы действительно два раза открываем что-то - это ошибка, надо открывать один раз.
			
			
			
			
		
 | 
			
				|  | 
	
		| Thanks: |   |  | 
			
				|  | 
		
			| 
 | 
		
			
				| FiNick 
 
   
 
						
						
					 | Date: 1/17/2012 
 
 
	
			Еще на ртс возникли вопросы на счет обработки lifeNum, переспросил что конкретно не нравится, завтра напишут. У нас точно все правильно написано? Из документации:  Quote:«Безбазовый» клиент должен изменить номер жизни с помощью вызова P2TableSet-> SetLifeNumToIni и переоткрыть поток вручную. Посмотрел код, не заметил чтобы мы переоткрывали потоки, или это както спрятано?
			
			
			
			
		
 | 
			
				|  | 
	
		| Thanks: |   |  | 
			
				|  | 
		
			| 
 | 
		
			
				| Alexander 
 
   
 
						
						
					 | Date: 1/17/2012 
 
 
	
			FiNick Еще на ртс возникли вопросы на счет обработки lifeNum, переспросил что конкретно не нравится, завтра напишут. У нас точно все правильно написано? Из документации:  Quote:«Безбазовый» клиент должен изменить номер жизни с помощью вызова P2TableSet-> SetLifeNumToIni и переоткрыть поток вручную. Посмотрел код, не заметил чтобы мы переоткрывали потоки, или это както спрятано? Т.к. конкретной проблемы нет, то ответить всё ли у нас правильно невозможно. Событие OnStreamLifeNumChanged у нас обрабатывается
			
			
			
			
		
 | 
			
				|  | 
	
		| Thanks: |   |  | 
			
				|  | 
		
			| 
 | 
		
			
				| Alexander 
 
   
 
						
						
					 | Date: 1/17/2012 
 
 
	
			А остальные проблемы решены сейчас?
			
			
			
			
		
 | 
			
				|  | 
	
		| Thanks: |   |  | 
			
				|  | 
		
			| 
 | 
		
			
				| FiNick 
 
   
 
						
						
					 | Date: 1/17/2012 
 
 
	
			Alexander Mukhanchikov А остальные проблемы решены сейчас? Я в своей версии программы разбил получение данных на три потока, и это помогло, очереди значительно снизились, этот вопрос у ртс отпал. Также вроде через клиринг прохожу нормально. Но у меня при работе робота стала вылетать иногда ошибка "не могу отменить заявку с номером таким-то", и не ясно, это косяк моего торгового алгоритма, или тех изменений, что я вносил чтобы через клиринг проходить. Короче, там явно придется еще повозиться, чтобы все аккуратно написать и все ошибки выловить
			
			
			
			
		
 | 
			
				|  | 
	
		| Thanks: |   |  | 
			
				|  | 
		
			| 
 | 
		
			
				| Mikhail Sukhov 
 
   
 
						
						
					 | Date: 1/18/2012 
 
 
	
			FiNick стала вылетать иногда ошибка "не могу отменить заявку с номером таким-то", и не ясно, это косяк моего торгового алгоритма, или тех изменений, что я вносил чтобы через клиринг проходить.
 Ошибка говорит что заявка уже снята или исполнена. Тоесть, снять ее уже не получится. Обычно бывает из-за того, что или алгоритм неправильно работает, или данные не успевают прийти. Второе - это нормальная ситуация. Нужно разруливать подобное.
			
			
			
			
		
 | 
			
				|  | 
	
		| Thanks: |   |  | 
			
				|  | 
		
			| 
 | 
		
			
				| vardes 
 
   
 
						
						
					 | Date: 1/18/2012 
						
							|  |  |  |   |  
 
 
	
			Всем привет! Написал робота скальпера для плазы и использованием библиотеки Stock#. Соответственно на демо-счете адекватно потестить не получается, пришлось проходить сертификацию. Отправил им логи после работы программы, вот что они написали: Quote:По логу есть два вопроса:
 1) У вас растет очередь сообщений, и с этим надо бороться:
 2012-01-17 11:40:31.582;p2mq-cli;;New message added to recvList. Size: 73
 2012-01-17 12:06:34.368;p2mq-cli;;New message added to recvList. Size: 2140
 2012-01-17 14:46:50.340;p2mq-cli;;New message added to recvList. Size: 279
 Бороться можно например путем получения реплики в нескольких соединениях, каждое открывающееся в отдельном треде и со своим циклом выборки.
 
 2) Как вы обрабатываете событие смены номера жизни для агрегированных потоков и для FUT/OPTCOMMON ? Т.к. обрабатывает их наверняка библиотека сток-#, то предлагаю эксперимент:
 - обнулить номер жизни в используемых orders_aggr.ini, fut/opt_common.ini или в forts_scheme.ini - смотря откуда схему берете
 - запустить свое приложение один раз, выключить
 - запустить второй раз, выключить
 - прислать логи П2 за оба запуска.
 
 Т.к. я пользуюсь библиотекой, как она есть, прошу специалистов помочь в решении поставленных вопросов. Буду очень вам благодарен.
			
			
			
			
		
 | 
			
				|  | 
	
		| Thanks: |   |  | 
			
				|  | 
		
			| 
 | 
		
			
				| Alexander 
 
   
 
						
						
					 | Date: 1/18/2012 
 
 
	
			Какая помощь нужна?По первому вопросу - проблема известна, давно писали уже об этом. Как решать - тоже понятно.
 FiNick вроде сделал, но можете ему помочь в этом. Его изменения пока у него локально хранятся.
 
 По второму - вроде всё расписано как надо делать. Как обрабатываем - смотрите OnStreamLifeNumChanged.
 | 
			
				|  | 
	
		| Thanks: |   |  | 
			
				|  | 
		
			| 
 | 
		
			
				| Mikhail Sukhov 
 
   
 
						
						
					 | Date: 1/18/2012 
 
 
	
			Что за библиотека? Ссылкой поделитесь?[biggrin] 
			
			
			
			
		
 | 
			
				|  | 
	
		| Thanks: |   |  | 
			
				|  | 
		
			| 
 | 
		
			
				| FiNick 
 
   
 
						
						
					 | Date: 1/18/2012 
 
 
	
			С номером жизни вроде нормально все. Сказали сделать сохранение ревизий, чтобы данные постоянно не подгружать, и тогда сертификат выдадут.
 Проблема в том, что то что у нас было написано для этого (Save/LoadRevision) у меня вот не работает: делается LoadRevision и у меня только два инструмента в списке, и только по этим инструментам сделки подгружаются, как ремонтировать не знаю
 | 
			
				|  | 
	
		| Thanks: |   |  | 
			
				|  |