java - Sockets with OSGi: Bundle stopped, socket still open -

i'm facing issue working serversocket inside 1 of bundles, let's call it: foobundle.

this foobundle has, among others, socketlistener.java class. class thread , make little overview of it, i'll paste pseudocode:

public class socketlistener implements runnable{  serversocket providersocket; socket connection = null; private boolean closeit = false;     public void run() {         try {             //create server socket             providersocket = new serversocket(41000, 10);         } catch (ioexception e1) {             //catching exception....         }         while(!closeit){         try{             connection = providersocket.accept();             in = new scanner(new inputstreamreader(onnection.getinputstream()));             while(in.hasnext() !=false)                      message = message + " "+in.next();               // bla bla bla...             } catch (ioexception e) {               //bla bla...             }         finally{          try{               if (message.equalsignorecase("bye"))                   providersocket.close();                           closeit = true;              }        catch(ioexception ioexception){         //........          } } 

as can see, it's simple thread waits connection until message receives 1 of socketclients "bye".

this problem i'm facing right now: when bundle stopped, need restart entire osgi framework : if try restart bundle, java.net.bindexception message thrown: "address in use". so, stopped bundle socket hasn't been closed.

in osgi, need take care of stop() method inside activator must include, can't pass reference of anonymous thread activator.

imagine class diagram inside bundle:

**foobundle** |__foobundleactivator |__fooimpl |__socketlistener (thread) 

the socketlistener thread called fooimpl class anonymous thread.

my question is: there appropiate method have such control of anonymous threads , in case, of non-closing socket ports, inside osgi paradigm?

thanks in advance.

if bundle told stop assume guy doing stopping knows doing. yes, protocol expects 'bye' shit happens, protocol has problems these things fragile real world. in general, tasks in osgi should have life cycle. code (using ds instead of activators).

@component public class protocolserver extends thread {   volatile serversocket server;   volatile socket connection;    public protocolserver() {     super("protocol server on 4100"); // identify thread   }    @activate void activate() {     setdaemon(true);     start();   }    @deactivate void deactivate() {      interrupt();       // best effort close (even if null)      try { server.close(); } catch(exception e) {}      try { connection.close(); } catch(exception e) {}       join(10000); // waits 10 secs until thread exits   }    public void run() {     // loop active component     while( !isinterrupted() )     try {       doserver();     } catch( exception e) {       log(e);        // bad error, accept failed or bind failed       // or server socket closed. if should remain       // active, sleep prevent overloading       // system trying often, sleep        if ( !isinterrupted() )          try { thread.sleep(5000); } catch(exception e) {}     }   }    private void doserver() throws exception {       server = new serversocket(4100)       try {          while( !isinterrupted() )            doconnection(server);       } {         server.close();       }   }    private void doconnection(serversocket server) throws exception {     connection = server.accept();     try {       domessages(connection);        // pseudo code exits here, seems       // kind of weird? if desired, interrupt       // object, exit thread      } catch( exception e) {        log(e); // connection failed, not uncommon     } {       connection.close();       connection = null;     }   }    private void domessages(socket connection) {     myscanner s = new myscanner(socket);     string msg;     while( !isinterrupted() && !"bye".equals( msg=s.getmessage()))       process(msg);   } } 

one important design consideration in osgi components keep working if there failures. in network have transient errors go away on own. if don't desirable server keeps on trying while fix problem. pseudo code nightmare in practice since disappear on error. system multiple such components tends becomes unstable.

one thing surprised me support 1 connection @ time. in general better not limit , handle messages in own thread. in case, must ensure each created handler connection closed appropriately.