iRule events firing out of order?

That's an interesting problem.

 

 

According to the Wiki they should fire in order, but the SERVER_DATA is also tied to the TCP::collect.

 

SERVER_CONNECTED - Triggered when a connection has been established with the target node.

 

SERVER_DATA - Triggered when new data is received from the target node after TCP::collect command has been issued.

 

 

Perhaps this is related to the issue you are having:

 

Causes TCP to start collecting the specified amount of content data. After collecting the data in a clientside event, the CLIENT_DATA event will be triggered. When collecting the data in a serverside event, the SERVER_DATA event will be triggered.

 

 

It is important to note that, when an explicit length is not specified, the semantics of TCP::collect and TCP::release are different than those of the HTTP::collect and HTTP::release commands. With TCP::collect, the event for processing the data (CLIENT_DATA or SERVER_DATA ) will fire without TCP::release being called, whereas with HTTP::collect, the event (HTTP_REQUEST_DATA or HTTP_RESPONSE_DATA) will not fire without HTTP::release being called.

 

 

TCP::collect: http://devcentral.f5.com/wiki/default.aspx/iRules/TCP__collect.html

Hey Hamish,

 

 

Are you calling TCP::collect in a serverside event or context other than SERVER_CONNECTED? If not, I don't see how this would happen during normal operation.

 

 

Aaron

Hmm... Not my iRule, so let me look..

 

 

Yes, a TCP::collect is being used in CLIENT_DATA, but that should simply collect data for a CLEINT_DATA event.

 

 

The SERVER_CONNECTED should run before SERVER_DATA... I dont' see how we could get SERVER_DATA even called without a TCP::collect in SERVER_CONNECTED first... But if that were true, then I also don't see why a variable set in SERVER_CONNECTED is sometimes undefined in SERVER_DATA... (Only about 4% of the time, but it does happen).

 

 

Hmm... Order of processing... Is it possible that SERVER_DATA is being called AFTER SERVER_CONNECTED but BEFORE the SERVER_CONNECTED event has finished? Can TCP::collect cause an event to be 'paused' and pre-empted by the _DATA event?

 

 

Hm... Down the bottom of the TCP::collect wiki page... Says TCP::collect implicitly holds the accepted event... Does that mean what I think it means? Although Sparks example back from 2008 seems to indicate that it isn't http://devcentral.f5.com/Forums/tabid/1082223/asg/50/showtab/groupforums/aff/5/aft/24911/afv/topic/Default.aspx (Because he sets variables after his collect too).

 

 

Let me try moving some code around and put the TCP::collect at the end of the SERVER_CONNECTED event...

 

 

H

 

Hmm... Problem just moved... Another variable now claims it isn't set (But this one is set in CLIENT_DATA only on specific packets. That may be a genuine bug in the iRule itself)

 

 

Sigh... Tomorrow is another day I guess...

 

 

H

I wonder how the events are supported within the F5... It's almost like some variables aren't being made available between events immediately... And if the events trigger too close to each other, then I get no such variable errors... (WHich should be impossible, because SERVER_CONNECTED is literally

when SERVER_CONNECTED {
  set s_offset 1
  TCP::collect
}

and then about 4% of the time when I sent a sudden load of about 100 connections and requests, I get TCL errors in SERVER_DATA claiming s_offset isn't a known variable...

H

Just to reassure you (and other readers), it is impossible for iRule events to fire out of order, though this is mostly true by definition. An iRule event fires whenever that action happens, so SERVER_CONNECTED fires whenever we have successfully connected to the server. That said, I don't know what could be causing the problem you describe. The only thing that makes any sense to me is if the client connection closes after we get the SYN-ACK from the server and before server data arrives. That would sever the relationship between the client and server connections, and I think it just happens that variables are associated with the client connection. You could test this theory by testing inside SERVER_DATA if the variable exists, and if it doesn't then see if there's a client connection (maybe do a catch of clientside { [IP::client_addr] } and log the result, or something like that). Just a thought.