Skip to Main Content

DevOps, CI/CD and Automation

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

Heavy TCP traffic after CQN registration using cx_Oracle

user6055956Apr 28 2016 — edited May 7 2016

Hello all,

I am using the sample code provided with cx_Oracle 5.2.1 to register a Continuous Query Notification to an Oracle 11.2.0.4 database ("C:\Python34\cx_Oracle-doc\samples\DatabaseChangeNotification.py").

The registration works fine and I can see the registration by querying "SELECT * FROM USER_CHANGE_NOTIFICATION_REGS"

However, once the registration is in place and before any changes are made to the database (I am currently the only one who runs queries & modifies this particular sandbox database), the oracle server sends a continuous & never-ending deluge of packets to my client. None of these connections results in my callback being triggered.

From wireshark I see that the DB initiates a connection, then sends 66 bytes of data (packet in bold below). The client then disconnects and the connection is successfully closed. (see below for example traffic). Once this connection is closed, the process starts again, this time coming from the next port number on the server (port 29549 in this example). The 66 bytes are slightly different with each connection, but never contains a table name or other recognizable text.

These connections are continuously created and destroyed always with consecutive source port numbers that seem to loop once the available port range is exhausted. I have left the python shell open for up to 3 hours and the traffic continues non-stop. The original CQN subscription was registered with a short timeout (e.g. 300 sec) and even though the subscription expires and no longer shows up in USER_CHANGE_NOTIFICATION_REGS, the incoming tcp traffic continues unabated.

Any ideas as to what is going on here?

Thanks!

No.    Time                Source                     Destination           Protocol   Length   Info                                                  

29548  0.000000000    <remoteDB IP>          10.1.4.136            TCP      74     29548→50000 [SYN] Seq=0 Win=5840 Len=0

50000  0.000057000    10.1.4.136            <remoteDB IP>          TCP      74     50000→29548 [SYN, ACK] Seq=0 Ack=1 Win=28960 Len=0

29548  0.014081000    <remoteDB IP>          10.1.4.136            TCP      66     29548→50000 [ACK] Seq=1 Ack=1 Win=5888 Len=0

29548  0.014267000    <remoteDB IP>          10.1.4.136            TCP      140    29548→50000 [PSH, ACK] Seq=1 Ack=1 Win=5888 Len=74

50000  0.014287000    10.1.4.136            <remoteDB IP>          TCP      66     50000→29548 [ACK] Seq=1 Ack=75 Win=29056 Len=0

50000  0.014335000    10.1.4.136            <remoteDB IP>          TCP      66     50000→29548 [FIN, ACK] Seq=1 Ack=75 Win=29056 Len=0

29548  0.028260000    <remoteDB IP>          10.1.4.136            TCP      66     29548→50000 [FIN, ACK] Seq=75 Ack=2 Win=5888 Len=0

50000  0.028312000    10.1.4.136            <remoteDB IP>          TCP      66     50000→29548 [ACK] Seq=2 Ack=76

Update: after 3.5 hours the python callback was called (once & without me making any database changes) and gave the following output:

Message type: 5

Message database name:

Message tables:

Traceback (most recent call last):

  File "/media/pdrive/Python Projects/play.py", line 8, in callback

    for table in message.tables:

TypeError: 'NoneType' object is not iterable

This post has been answered by Anthony Tuininga-Oracle on May 6 2016
Jump to Answer

Comments

Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Jun 4 2016
Added on Apr 28 2016
6 comments
1,982 views