You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Daniel Felsing <da...@maven.at> on 2008/08/03 11:38:07 UTC
Re: Re: UPnP Basedriver 0.8.0 from felix - Devices get lost after a certain period of time...(basedriver locks up) - found the problem - please help!
Hello all (and especially to Mr. Lenzi and Mr. Furfari :-),
Ok.. i run a test as follows and i think i have pinned down the problem.
I have everything properly configured...and as i wrote two hosts A and B.
Both hosts are running OSGi with UPnPBasedriver 0.8.
Host A exports about 20 devices, host B imports them and acts as a central
server.
Ok...everything runs fine for about 8 hours now. After that i get the
following:
CyberDomo warning: too many open files
Java.net.SocketException: Too many open files
That happens in SSDPNotifySocket....in the Device.announce method of
cybergarage upnp library and that in the thread "Advertiser" on line 68
----------->
Under Linux Systems every Socket uses a "file descriptor" in the system
which is in most unix systems default value of 1024 max descriptors.
Now i tried to push that value to 65535 and vuala everything is running > 8
hours.
If i check my open file descriptors with lsof -p pidofmyjavaprogram i see
now MANY open ports that have not been closed properly (right now > 1400 for
10 hours of operation).
Ok..that made me let a bit deeper into the code of cyberlink library.
I saw a fix that was introduced by someone because of "non-closed" ssdp udp
sockets in the announce method of org/cybergarage/upnp/Device.java
1240 SSDPNotifySocket ssdpSock = new SSDPNotifySocket(bindAddr);
1241
1242 SSDPNotifyRequest ssdpReq = new SSDPNotifyRequest();
1243 ssdpReq.setServer(UPnP.getServerName());
1244 ssdpReq.setLeaseTime(getLeaseTime());
1245 ssdpReq.setLocation(devLocation);
1246 ssdpReq.setNTS(NTS.ALIVE);
1247
1248 // uuid:device-UUID(::upnp:rootdevice)*
1249 if (isRootDevice() == true) {
1250 String devNT = getNotifyDeviceNT();
1251 String devUSN = getNotifyDeviceUSN();
1252 ssdpReq.setNT(devNT);
1253 ssdpReq.setUSN(devUSN);
1254 ssdpSock.post(ssdpReq);
1255
1256 String devUDN = getUDN();
1257 ssdpReq.setNT(devUDN);
1258 ssdpReq.setUSN(devUDN);
1259 ssdpSock.post(ssdpReq);
1260 }
1261
1262 //
uuid:device-UUID::urn:schemas-upnp-org:device:deviceType:v
1263 String devNT = getNotifyDeviceTypeNT();
1264 String devUSN = getNotifyDeviceTypeUSN();
1265 ssdpReq.setNT(devNT);
1266 ssdpReq.setUSN(devUSN);
1267 ssdpSock.post(ssdpReq);
1268
1269 // Thanks for Mikael Hakman (04/25/05)
1270 ssdpSock.close();
Ok seems fine so far...
Ok now i looked into org/cybergarage/upnp/Service.java and there the "socket
close fix" was NOT introduced for both announce and byebye.....
599 public void announce(String bindAddr)
600 {
601 //
uuid:device-UUID::urn:schemas-upnp-org:service:serviceType:v
602 Device rootDev = getRootDevice();
603 String devLocation = rootDev.getLocationURL(bindAddr);
604 String serviceNT = getNotifyServiceTypeNT();
605 String serviceUSN = getNotifyServiceTypeUSN();
606
607 Device dev = getDevice();
608
609 SSDPNotifyRequest ssdpReq = new SSDPNotifyRequest();
610 ssdpReq.setServer(UPnP.getServerName());
611 ssdpReq.setLeaseTime(dev.getLeaseTime());
612 ssdpReq.setLocation(devLocation);
613 ssdpReq.setNTS(NTS.ALIVE);
614 ssdpReq.setNT(serviceNT);
615 ssdpReq.setUSN(serviceUSN);
616
617 SSDPNotifySocket ssdpSock = new SSDPNotifySocket(bindAddr);
618 Device.notifyWait();
619 ssdpSock.post(ssdpReq);
620 }
622 public void byebye(String bindAddr)
623 {
624 //
uuid:device-UUID::urn:schemas-upnp-org:service:serviceType:v
625
626 String devNT = getNotifyServiceTypeNT();
627 String devUSN = getNotifyServiceTypeUSN();
628
629 SSDPNotifyRequest ssdpReq = new SSDPNotifyRequest();
630 ssdpReq.setNTS(NTS.BYEBYE);
631 ssdpReq.setNT(devNT);
632 ssdpReq.setUSN(devUSN);
633
634 SSDPNotifySocket ssdpSock = new SSDPNotifySocket(bindAddr);
635 Device.notifyWait();
636 ssdpSock.post(ssdpReq);
637 }
So .... may this be the root of the problem?
So if it is...i am very bad in using pom.xml files to build the basedriver
against the latest cyberlink library :-((((((
So Question A is: can mr lenzi and mr furfari confirm this as a bug and the
cause of my problem?
And Question B is: could one of you please please fix it, build me the
basedriver against the fixed code and send it to me? :-/
Or just update the pom.xml and the sourcecode so i can build it using the
"apache felix" maven repository
Kind regards and MANY MANY thanks in advance,
Daniel Felsing
-----Ursprüngliche Nachricht-----
Von: Daniel Felsing [mailto:daniel.felsing@maven.at]
Gesendet: Freitag, 01. August 2008 08:46
An: 'users@felix.apache.org'
Betreff: Re: Re: UPnP Basedriver 0.8.0 from felix - Devices get lost after a
certain period of time...(basedriver locks up)
Hi again,
i just checked the active ethernet links via ifconfig.
Eth0 and eth1
One is the cable connection, the second wlan.
I have not configured wlan since i use cable connection for programming - it
seems that one of those ip addresses is selected randomly in the base
driver.
The dhcp is properly running though.
I just deactivated the wlan address...now i'm curious what is happening :-)
Since this can be the only fault on my side which is causing that prob.
Kind regards,
Daniel
-----Ursprüngliche Nachricht-----
Von: Remco Poortinga [mailto:Remco.Poortinga@telin.nl]
Gesendet: Freitag, 01. August 2008 08:40
An: users@felix.apache.org
Betreff: RE: Re: UPnP Basedriver 0.8.0 from felix - Devices get lost after a
certain period of time...(basedriver locks up)
Hi Daniel,
IP(v4) addresses in the 196.254.0.0/16 range are link-local IP
addresses.
These are (obviously) not routable beyond link scope, but probably do
show up because of the UPnP bridge?
(that is: the bridge does see them at that location and just reports
that)
These addresses are often used as an address when e.g. DHCP fails (so if
a machine boots up, but can't find a place to get an address from, it
will use an address from this range).
Since your problems (if I understand correctly) don't happen directly
from the start, maybe there's an issue with DHCP when a lease expires?
Just guessing here, and of course these addresses showing up might not
be related to/causing your problem at all; but might be worth
exploring.
Best regards,
Remco
> -----Original Message-----
> From: Daniel Felsing [mailto:daniel.felsing@maven.at]
> Sent: Friday, August 01, 2008 8:25 AM
> To: users@felix.apache.org
> Subject: Re: Re: UPnP Basedriver 0.8.0 from felix - Devices
> get lost after a certain period of time...(basedriver locks up)
>
> Hello again....
>
>
> A follow up to the below - remember the ip address of the
> host exporting the devies is 192.168.0.9, the importer host
> is 192.168.0.5 Notice the differences in the Location
> line....sometimes a very weird ip address shows up...and
> sometimes the importer host is shown.
>
>
> Sometimes i see:
>
> --------------------------------------------
> debug 20080801 08:17:37 bid#94 - [Importer]
> ssdpPacket.isAlive
> debug 20080801 08:17:37 bid#94 - [Importer] Device already
> discovered
> debug 20080801 08:17:37 bid#94 - [Importer] check for service
> updating
> debug 20080801 08:17:37 bid#94 - [Importer]
> deviceNotifyReceived
> debug 20080801 08:17:37 bid#94 -
> ================REQUEST=====================
> NOTIFY * HTTP/1.1
> Server: Linux/2.6.20-17-generic UPnP/1.0 CyberDomo/1.8
> Cache-Control: max-age=1800
> Location: http://169.254.5.186:4020/gen-desc.xml
> NTS: ssdp:alive
> NT: urn:schemas-upnp-org:service:GetLevel:1
> USN:
> uuid:AT-SM-FHZ1-S20_Switch2::urn:schemas-upnp-org:service:GetLevel:1
> HOST: 239.255.255.250:1900
>
>
> And sometimes:
>
> --------------------------------------------
> debug 20080801 08:19:10 bid#94 - [Importer]
> ssdpPacket.isAlive
> debug 20080801 08:19:10 bid#94 - [Importer] Device already
> discovered
> debug 20080801 08:19:10 bid#94 - [Importer] check for service
> updating
> debug 20080801 08:19:10 bid#94 - [Importer]
> deviceNotifyReceived
> debug 20080801 08:19:10 bid#94 -
> ================REQUEST=====================
> NOTIFY * HTTP/1.1
> Server: Linux/2.6.20-17-generic UPnP/1.0 CyberDomo/1.8
> Cache-Control: max-age=1800
> Location: http://192.168.0.5:4007/gen-desc.xml
> NTS: ssdp:alive
> NT: upnp:rootdevice
> USN: uuid:AT-SM-FHZ1-S20_Switch1::upnp:rootdevice
> HOST: 239.255.255.250:1900
>
>
>
>
> Here agaain:
> --------------------------------------------
> debug 20080801 08:21:05 bid#94 - [Importer]
> ssdpPacket.isAlive
> debug 20080801 08:21:05 bid#94 - [Importer] Device already
> discovered
> debug 20080801 08:21:05 bid#94 - [Importer] check for service
> updating
> debug 20080801 08:21:05 bid#94 - [Importer]
> deviceNotifyReceived
> debug 20080801 08:21:05 bid#94 -
> ================REQUEST=====================
> NOTIFY * HTTP/1.1
> Server: Linux/2.6.20-17-generic UPnP/1.0 CyberDomo/1.8
> Cache-Control: max-age=1800
> Location: http://169.254.5.186:4021/gen-desc.xml
> NTS: ssdp:alive
> NT: urn:schemas-upnp-org:service:SwitchDevice:1
> USN:
> uuid:AT-SM-FHZ1-shutter1::urn:schemas-upnp-org:service:SwitchDevice:1
> HOST: 239.255.255.250:1900
>
>
> --------------------------------------------
> debug 20080801 08:22:19 bid#94 - [Importer]
> ssdpPacket.isAlive
> debug 20080801 08:22:19 bid#94 - [Importer] Device already
> discovered
> debug 20080801 08:22:19 bid#94 - [Importer]
> deviceNotifyReceived
> debug 20080801 08:22:19 bid#94 -
> ================REQUEST=====================
> NOTIFY * HTTP/1.1
> Server: Linux/2.6.20-17-generic UPnP/1.0 CyberDomo/1.8
> Cache-Control: max-age=1800
> Location: http://169.254.5.186:4005/gen-desc.xml
> NTS: ssdp:alive
> NT: uuid:AT-SM-FHZ1-rainsensor1
> USN: uuid:AT-SM-FHZ1-rainsensor1
> HOST: 239.255.255.250:1900
>
>
> --------------------------------------------
> debug 20080801 08:21:46 bid#94 - [Importer]
> ssdpPacket.isAlive
> debug 20080801 08:21:46 bid#94 - [Importer] Device already
> discovered
> debug 20080801 08:21:46 bid#94 - [Importer]
> deviceNotifyReceived
> debug 20080801 08:21:46 bid#94 -
> ================REQUEST=====================
> NOTIFY * HTTP/1.1
> Server: Linux/2.6.20-17-generic UPnP/1.0 CyberDomo/1.8
> Cache-Control: max-age=1800
> Location: http://192.168.0.5:4012/gen-desc.xml
> NTS: ssdp:alive
> NT: urn:schemas-upnp-org:device:FHZDimmingSwitch:1
> USN:
> uuid:AT-SM-FHZ1-S20_Switch8::urn:schemas-upnp-org:device:FHZDi
mmingSwitch:1
> HOST: 239.255.255.250:1900
>
> -----Ursprüngliche Nachricht-----
> Von: Daniel Felsing [mailto:daniel.felsing@maven.at]
> Gesendet: Freitag, 01. August 2008 08:13
> An: users@felix.apache.org
> Betreff: Re: UPnP Basedriver 0.8.0 from felix - Devices get
> lost after a certain period of time...(basedriver locks up)
>
> Hello,
>
> a small follow up - maybe this causes the problem?
> This shows the discovery of a specific upnp device, which is
> then refined.
> What makes me wonder is the proposed location which is wrong:
> Location:
> http://169.254.5.186:4009/gen-desc.xml
> If you look at the 2nd message which delivers me the event
> the ip address of the host is correct: HOST: 192.168.0.9
>
>
> debug 20080801 08:08:51 bid#102 -
> at.smarthome.fhzupnprefiningdriver.FHZRefiningDriverImpl[FHZRe
> finingDriver
> match method called for DEVICE_CATEGORY: UPnP]
> info 20080801 08:08:51 bid#94 -
> [56;org.osgi.service.upnp.UPnPDevice] ServiceEvent REGISTERED
> debug 20080801 08:08:51 bid#102 -
> at.smarthome.fhzupnprefiningdriver.FHZRefiningDriverImpl[Match
> ed device:
> uuid:AT-SM-FHZ1-dimmablelight1 of model type FHZDimmableLight]
> debug 20080801 08:08:51 bid#94 - [Importer] searching for
> UPnPEventListener
> debug 20080801 08:08:51 bid#102 -
> at.smarthome.fhzupnprefiningdriver.FHZRefiningDriverImpl[FHZRe
> finingDriver
> attach method called for DEVICE_CATEGORY: UPnP]
> info 20080801 08:08:51 bid#102 -
> at.smarthome.fhzupnprefiningdriver.FHZRefiningDriverImpl[Attac
> hing to device with UDN: uuid:AT-SM-FHZ1-dimmablelight1 of
> model type FHZDimmableLight]
> debug 20080801 08:08:51 bid#102 -
> at.smarthome.fhzupnprefiningdriver.FHZRefiningDriverImpl[at.sm
> arthome.fhzupn
> prefiningdriver 1.0 creating new DimmableLight Device]
> debug 20080801 08:08:51 bid#94 - [Importer]
> deviceSearchResponseReceived
> debug 20080801 08:08:51 bid#94 -
> ================REQUEST=====================
> HTTP/1.1 200 OK
> Content-Type: text/html; charset="utf-8"
> Server: Linux/2.6.20-17-generic UPnP/1.0 CyberDomo/1.8
> Content-Length: 0
> Cache-Control: max-age=1800
> EXT:
> Date: Fri, 01 Aug 2008 08:05:56 GMT
> ST: upnp:rootdevice
> USN: uuid:AT-SM-FHZ1-S20_Switch4::upnp:rootdevice
> Location: http://169.254.5.186:4009/gen-desc.xml
> MYNAME: FHZDimmingSwitch
>
> --------------------------------------------
>
> debug 20080801 08:08:51 bid#94 -
> Event::org.osgi.framework.ServiceEvent[source={org.osgi.servic
> e.upnp.UPnPEve
> ntListener}={upnp.filter=(UPnP.device.UDN=uuid:AT-SM-FHZ1-dimm
ablelight1),
> service.id=57}]
> debug 20080801 08:08:52 bid#94 - [Importer]
> httpRequestRecieved
> event
> debug 20080801 08:08:52 bid#94 -
> ================REQUEST=====================
> NOTIFY /evetSub HTTP/1.0
> Content-Type: text/xml; charset="utf-8"
> HOST: 192.168.0.9
> NT: upnp:event
> NTS: upnp:propchange
> SID: uuid:5cca-a11b-f11d-e0c2
> SEQ: 0
> Content-Length: 165
> Connection: close
>
> <?xml version="1.0" encoding="utf-8"?>
> <propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
> <property>
> <Status>off</Status>
> </property>
> </propertyset>
> --------------------------------------------
>
>
> Kind regards,
> Daniel Felsing
>
>
> -----Ursprüngliche Nachricht-----
> Von: Daniel Felsing [mailto:daniel.felsing@maven.at]
> Gesendet: Freitag, 01. August 2008 08:03
> An: users@felix.apache.org
> Cc: 'Francesco Furfari'; 'Stefano "Kismet" Lenzi'
> Betreff: UPnP Basedriver 0.8.0 from felix - Devices get lost
> after a certain period of time...(basedriver locks up)
>
> Hello all,
>
>
>
> I already published that in another post but since it is a
> new topic / problem i summarise my architecture.
>
>
>
> I have 2 hosts A and B. Both are running UPnP Basedriver to
> access the upnp network.
>
>
>
>
>
> Host A acts as a upnp bridge to export X10 like devices
> (Switches, Motionsensors, Lights etc.) into the upnp network.
> Right now 19 devices get exported.
>
> I'm using the helper class UPnPEventNotifier there.
>
>
>
> Host B acts as a central server which imports and refines
> those devices (using a refining driver) using the base driver.
>
> The refined devices use UPnPSubscriber to subscribe to UPnP
> Events and get status updates of the devices.
>
>
>
>
>
> Host A and B are connected through a gigabit switch, so no
> wireless or anything other in between.
>
>
>
>
>
> After a random time - say 30-50 minutes - it often occur that
> devices just unregister and disappear.
>
> I refer to the topic of the domoware site since the guy there
> had a similiar problem and maybe mr lenzi and mr furfari can
> remember that:
>
> https://sourceforge.net/forum/forum.php?thread_id=1871253
> <https://sourceforge.net/forum/forum.php?thread_id=1871253&for
um_id=406095>
> &forum_id=406095
>
>
>
>
>
> ok - the other guy was using devices that were not exported
> by the upnp basedriver.i'm only using devices that get
> exported by upnp base driver from felix.
>
> That's the difference.
>
>
>
>
>
> I tried the solution explained there to use the
> DriverController.search method to propagate msearches for all
> devices every 10 minutes.
>
> After 3 hours of operation doing that the basedriver on Host
> A (the bridge) begin to lockup. The devices all disappear and
> i get continous error messages
>
> by Cyberdomo saying "Too many files open".
>
>
>
>
>
> So to summarise my problem:
>
>
>
> a) The renewal of devices without m-search using the
> base-driver on
> both ends doesn't seem to work properly, since after some
> time devices disappear. (however all is working fine for some time)
>
> b) After doing m-searches the basedriver is getting
> unstable saying
> "too many files open"
>
>
>
>
>
> I really need help.
>
>
>
>
>
> Kind regards,
>
> Daniel Felsing
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org