Hi Daniel,
yes, probably you 've hit the nail in the head.
As usual open another issue in JIRA.
We will help you with the building process after checking the code.
thanks for your help,
francesco
On 8/3/2008, "Daniel Felsing" <[EMAIL PROTECTED]> wrote:
>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:[EMAIL PROTECTED]
>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:[EMAIL PROTECTED]
>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:[EMAIL PROTECTED]
>> 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:[EMAIL PROTECTED]
>> 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:[EMAIL PROTECTED]
>> 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: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
