Trouble with ami event

[sinoee]

hi,here is my ami config:
[cdr]
secret = v1danetw0rk
deny=0.0.0.0/0.0.0.0
permit=127.0.0.1/255.255.255.0
read = system,call,dialplan,dtmf
eventfilter=!Event: VarSet
eventfilter=!Event: PeerStatus
eventfilter=!uEvent: NewCallerId
eventfilter=!uEvent: Unknown

and when connect ami ,the cli show like below,the filedes? don’t konw what’s mean,always glow ,sometime lke 2000+… and the client lost lot’s of events… the pbxserver have large calls per miniter. when there is small calls,it’s okay.

[root@VCIGAA logs]# asterisk -x ‘manager show connected’
Setting max files open to 20000
Username IP Address Start Elapsed FileDes HttpCnt Read Write
cdr 127.0.0.1 1602319492 28 1533 0 02307 00016
1 users connected.

here is the client

ManagerConnectionFactory connectionFactory = new ManagerConnectionFactory(server_ip, server_port,server_username, server_password);
managerConnection = connectionFactory.createManagerConnection();
while (true) {
try {
managerConnection.addEventListener(this);
managerConnection.setSocketTimeout(5000);
managerConnection.setSocketReadTimeout(300 * 1000);
managerConnection.login();
setConnected(true);
log.info(“login success（{}:{}。”, server_ip, server_port);
break;
} catch (Exception e) {
setConnected(false);
log.error(“login fail：{}”, server_ip, server_port, e);

		}
		try {
			Thread.sleep(5000);
		} catch (InterruptedException e) {
			e.printStackTrace();
		}
	}

[sinoee]

thanks for response.

[david551]

FileDes is presumably the file descriptor corresponding to the TCP socket, so is purely informative.

As this is a TCP connection, Asterisk would have to be throwing away the events, in which case I would expect to see log messages, or your (unnamed language) class library is throwing them away.

The only thing I’m aware of that would cause Asterisk to loose events is if your AMI client was failing to read the TCP stream sufficiently fast, which would result in TCP flow control causing the OS on Asterisk to exceed its buffer allocation for the connection. Asterisk uses non-blocking writes, so that it sacrifices AMI event to more important processing, if this happens. However, as I remember it, it logs a message in this case.

When we had this, it was because of long running processing in the AMI client that didn’t adequately service the TCP stream.

For help with your (unnamed language) class library, you should contact its developers.

[sinoee]

thanks.i think that’s the reason. the unnamed language is java. And i use asterisk-java-2.2.0.jar to connect to ami… Is there something i need to do can resolve the problem.