We have WSO2CEP running on Azure VM which is a complex event engine and will send out the notification by its pulisher by using simple HTTP POST. However, it will work well on AWS EC2 but not Azure VM. It will throw below exception sometime.

ID: [-1] [] [2016-10-07 16:05:00,043] ERROR {org.wso2.carbon.event.output.adapter.core.OutputEventAdapter} -  Event dropped at Output Adapter '57f629ee23a74a1688b9e7c1_PUBLISHER' for tenant id '-1234', Read timed out 
java.net.SocketTimeoutException: Read timed out
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
    at java.net.SocketInputStream.read(SocketInputStream.java:170)
    at java.net.SocketInputStream.read(SocketInputStream.java:141)
    at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
    at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
    at org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:78)
    at org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:106)
    at org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1116)
    at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.readLine(MultiThreadedHttpConnectionManager.java:1413)
    at org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1973)
    at org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1735)
    at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1098)
    at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
    at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
    at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
    at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:346)
    at org.wso2.carbon.event.output.adapter.http.HTTPEventAdapter$HTTPSender.run(HTTPEventAdapter.java:317)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

I though it possibly caused by the issue discussed here and here. The workaround is assign the Instance-level public IP(ILPIP) to the VM. However, we are now using the Azure Resource Manager model and the all related ILPIP articles seems talk about the classic mode (Azure Service Manager).

Currently we have a dynamic Public IP address assign to the Network Interface of the Virtual Machine.

Is the ARM still have ILPIP? and how can we set it up?

1 Answer 1


In brief, to my knowledge, there is no way to assign an ILPIP to an ARM VM.

Because there is no concept of ILPIP in ARM. ARM changes the network architecture.

When you assign a public IP to VM in ARM (actually, it is assigned to the vNIC connected to the VM), this IP will not be shared by other VM, which is different with ASM. In ASM, the public IP address is owned by the cloud service. All VMs belonging to same cloud service will share the public IP address. That's the reason why we need ILPIP. But in ARM, VM has its' own public IP address.

So, I would doubt if your problem is same with the link mentioned above. Please try to perform a network capture on the VM to check the exactly network behavior, which is very useful for network troubleshooting.

  • Hi Steven, thanks for the answer. According to the article. In ASM, it maintains a source NAT table and it got a hardcoded timeout value, If your application keeps a connection idle for 4 minutes, its entry in the connection table will get deleted. And AFAIK, in the ARM, even the static public IP still have a idle timeout value default to 4 mins, but why? If the public IP is no more share with any other VM in ARM architecture.
    – Bruce
    Oct 11, 2016 at 9:52
  • "but why?" - that's a good question. I've hit into this issue and spent about a week debugging & working with a vendor overcoming this issue on Azure. It's mind boggling to know that this issue had a solution in the "classic" version of Azure but in the modern version THERE IS NO WAY AROUND THIS. And the public IP has 1:1 relationship with the VM so why the need for a stateful connection table?! Even @docs, no mention that modern Azure does not support this docs.microsoft.com/en-gb/azure/virtual-network/… Microsoft, this is disgusting. WTF?!
    – joonas.fi
    Jan 23, 2017 at 9:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.