Win64 Server 2008 and SocketException Invalid argument

Wowza Streaming Engine
1

Doing an eval of Wowza 2.2.3 b26454 on Windows Server 2008 R2 64-bit with 64-bit Java JDK v1.06.0_23 VM Version 19.0-b09.

Target application is re-streaming an Axis IP camera. I’m using the rtplive example application and the re-streaming works fine.

However… with just a single Flash client connecting and disconnecting, the second connect attempt (after the 10s publishing timeout disconnect) always causes Wowza to fail to re-publish the stream from the camera.

Always see a sequence like this… (camera source IP changed to 1.2.3.4)

[SIZE="2"]INFO stream unpublish camera.stream -
INFO stream destroy camera.stream -
INFO server comment - MediaStreamMap.removeLiveStreamPacketizer[rtplive/_definst_/camera.stream]: Destroy live stream packetizer: cupertinostreamingpacketizer
INFO server comment - MediaStreamMap.removeLiveStreamPacketizer[rtplive/_definst_/camera.stream]: Destroy live stream packetizer: sanjosestreamingpacketizer
INFO server comment - MediaStreamMap.removeLiveStreamPacketizer[rtplive/_definst_/camera.stream]: Destroy live stream packetizer: smoothstreamingpacketizer
INFO stream destroy camera.stream -
INFO session connect-pending 1.2.3.4 -
INFO session connect 1.2.3.4 -
INFO stream create - -
INFO server comment - MediaStreamMediaCasterPlay: startPlay
INFO server comment - RTPMediaCaster.create[71149648]
INFO server comment - RTPMediaCaster.init[71149648]
INFO server comment - RTPMediaCaster.Reconnector[71149648:rtplive/_definst_:camera.stream]: start: 1
ERROR server comment - Failed to connect: org.apache.mina.common.RuntimeIOException: java.net.SocketException: Invalid argument: sun.nio.ch.Net.setIntOption
WARN server comment - RTPSessionDescriptionDataProviderBasic.getStreamInfo: RTSP/RTP re-streaming. Cannot connect to server: rtsp://1.2.3.4:554/axis-media/media.amp?videocodec=h264&streamprofile=Test
ERROR server comment - Failed to connect: org.apache.mina.common.RuntimeIOException: java.net.SocketException: Invalid argument: sun.nio.ch.Net.setIntOption
ERROR server comment - Failed to connect: org.apache.mina.common.RuntimeIOException: java.net.SocketException: Invalid argument: sun.nio.ch.Net.setIntOption
ERROR server comment - Failed to connect: org.apache.mina.common.RuntimeIOException: java.net.SocketException: Invalid argument: sun.nio.ch.Net.setIntOption
ERROR server comment - Failed to connect: org.apache.mina.common.RuntimeIOException: java.net.SocketException: Invalid argument: sun.nio.ch.Net.setIntOption
INFO server comment - MediaStreamMediaCasterPlay: close
ERROR server comment - Failed to connect: org.apache.mina.common.RuntimeIOException: java.net.SocketException: Invalid argument: sun.nio.ch.Net.setIntOption
INFO session comment 1823691562 client connectionClosed [1823691562] watchdog
INFO session disconnect 1823691562 -
ERROR server comment - Failed to connect: org.apache.mina.common.RuntimeIOException: java.net.SocketException: Invalid argument: sun.nio.ch.Net.setIntOption
ERROR server comment - Failed to connect: org.apache.mina.common.RuntimeIOException: java.net.SocketException: Invalid argument: sun.nio.ch.Net.setIntOption
ERROR server comment - Failed to connect: org.apache.mina.common.RuntimeIOException: java.net.SocketException: Invalid argument: sun.nio.ch.Net.setIntOption
INFO server comment - RTPMediaCaster.shutdown[71149648:rtplive/_definst_:camera.stream]: camera.stream
INFO server comment - RTPMediaCaster.disconnect[71149648:rtplive/_definst_:camera.stream]
INFO server comment - RTPMediaCaster.closeRTPSession[71149648:rtplive/_definst_:camera.stream]
INFO server comment - RTPMediaCaster.Reconnector[71149648:rtplive/_definst_:camera.stream]: done: 1
INFO session comment 247810772 client connectionClosed [247810772] pingtimeout
INFO session disconnect 247810772 -[/SIZE]

I like the concept of publishing on-demand to save us from streaming out of the camera when there’s no one watching… but it’s not a mandatory feature, especially if we target non-Flash mobile devices too. Not tried stream manager publishing control yet on this server. Have tried same application config on 32-bit Windows Vista + 32-bit JDK with the same camera, no problem (albeit on my home LAN and not via a hosted server as with the 64-bit case).

Even if we use some kind of manual or scripted stream publishing management, would not want this re-connect failure to happen every time we re-start a stream from a camera.

Thoughts?

Thanks,

David.

NB: similar to this thread? https://www.wowza.com/forums/showthread.php?5549-Load-testing-tool-trouble

2

David,

It might be a connection limit of the camera. Some or all IP cameras have a limit on the number of connections they allow. Maybe the previous connection is not disposed of and the limit is reached. It’s better to use StreamManager in any case, but if this is the problem StreamManager should solve it. Change the Application.xml /StreamType to “live” to ensure that you have control and that Flash clients can’t start before you do start the stream in StreamManager.

Richard

3

This is connectivity problem. If not camera rejecting, then some other problem in the network preventing Wowza from connecting to the stream.

ERROR server comment - Failed to connect: org.apache.mina.common.RuntimeIOException: java.net.SocketException: Invalid argument: sun.nio.ch.Net.setIntOption

Richard

4

David,

Zip up conf and logs folders, and the camera.stream file, and send them to support@wowza.com

Include a link to this thread.

Richard

5

it seems on the face of it, from your home experiment, the 64bit JDK is different enough to cause problems when opening sockets.

The simplest solution is to go with a 32bit hosted server, however looks like Wowza development need to look at why the 64bit JDK is different.

Shamrock

6

Thanks Richard. I don’t believe it is a connection limit issue at the camera. I can run two simultaneous H.264 stream connections to the camera on the local net while also re-streaming via the Internet-based Wowza server. Still get the re-publishing failures irrespective of whether I have other connections to the camera… one, two or none.

Similarly, I can connect/disconnect to the same camera all day long with my local dev copy of Wowza on 32-bit Vista.

I’ll move on and play around with the StreamManager start/stop method.

I’m mostly concerned that I didn’t make a “wrong” decision by picking Win64 as the Wowza host.

David.

7

Okay… slowly going nuts here. Any more suggestions greatly appreciated.

I’ve been using StreamManager for the last few days and the previously described “SocketException: Invalid argument” state still occurs sporadically. Sometimes I can connect/disconnect to the Axis camera origin 10 times in a row with no problems. More likely… like this morning … I can’t connect at all for hours and even re-booting my remote Wowza server and all local hardware doesn’t fix it.

I finally just got the camera’s stream to publish but only after leaving the server to issue 50+ of these “invalid argument” errors and then magically… success.

I’ve tried switching ports for rtsp and forwarding the UDP range 6970 to 9999 from my local Linksys router to the camera. No effect.

I can completely turn off the Windows Server firewall and no effect.

Running out of ideas…

Anyone got any suggestions for what might be going wrong and where else I can look?

Configurable connect timeout issue (even though the error message bears no relation to this)?

Get an industrial-strength router?

Many thanks,

David.

Note: Once the camea stream is published, I can connect to Wowza and view that stream for hours and hours without a hitch.

8

Richard… any chance you could try a few stream start/stops from one of your in-house servers, if I email you the camera.stream ? Would help me elimnate (or not) my server-end setup.

It’s running right now and same issue. Once I get a connection, Wowza streams indefinitely. The minute I stop and re-start the stream… errors return. Every time Wowza posts another error message to its console window, the camera’s link lights flash. You might think the camera is seeing packets for every connect attempt and rejecting but if I totally power cycle it… makes no difference. Not a deadlock state in the camera interface.

Thanks,

David.

9

Done. Thank you Richard.