start stop processes can be a method with an id argument... threads can be stored in a list, hash or similar ... It should be better than a bundle for each process ... in my opinion it is a little weird what you comment ..
Miguel On Tue, Mar 2, 2010 at 1:15 PM, Abhishek kapoor < [email protected]> wrote: > Hi Chris, > > Thread pooling can sort some of the issues but we need the facility to > start and stop the process independently. > Also it will be great to reload the process again with some change and not > to mention versioning between bundles with changes etc.. > > Thanks > San > > Thanks > > > On Tue, Mar 2, 2010 at 5:13 PM, Christopher Armstrong < > [email protected]> wrote: > >> Why not move the code into the same process, and run each as a separate >> thread? There are plenty of thread pooling technologies about. >> >> Bundles don't run in OSGi like processes, they have a "start" and "stop" >> method, but if they are to run an active task, they will need to start up a >> thread for themselves anyway (which is effectively what happens when you >> create a process in the operating system - it starts your process with one >> thread ( the main thread) and executes your code on it until the thread >> exits). >> >> Cheers >> Chris >> >> On 02/03/2010, at 22:20 PM, Abhishek kapoor wrote: >> >> Hi Chris, >> >> Thanks for your time and comments. >> What I meant by single process per JVM is. At the moment we use, lets say >> process A which fetch data from DB and process accordingly. We initiate a >> JVM for the respective process [that is a instance of JVM is booted for that >> process]. We do similar thing for atleast 30 process, that create 30 >> instance for JVM, so in-order to avoid one instance of JVM per process, i >> thought why not incorporate in osgi framework by creating bundle per process >> instead new JVM instance. >> >> Application is back middle system so i don't understand the need J2EE >> stack for it. >> >> Hope this time I am much clear. >> >> Thanks >> San >> >> >> On Tue, Mar 2, 2010 at 4:15 PM, Christopher Armstrong < >> [email protected]> wrote: >> >>> Hi >>> >>> I don't know what you are looking for from this list, but you are >>> unlikely to find it. >>> >>> At a quick glance, the requirements you mention below could be easily >>> fulfilled by a enterprise J2EE stack or written into a lightweight container >>> framework like Spring. >>> >>> Why do you need OSGi? >>> >>> You are also unclear on what you mean by "a separate process per JVM". >>> All Java applications, including a running OSGi framework, use one process >>> per JVM instance. If you mean a single process per requirement, that still >>> is not unusual - using something like JMS for integration would fit well >>> with such an architecture. >>> >>> Cheers >>> Chris >>> >>> On 02/03/2010, at 20:59 PM, Abhishek kapoor wrote: >>> >>> Dear Member, >>> >>> Thanks for reading this email. I need your kind help regarding convincing >>> my manager to adopt OSGI in our future development. >>> >>> Below is the current application architecture >>> >>> We are telecom company and at the moment we use separate JVM per process >>> for our middleware for Order management system. >>> >>> Below are the general overview of the all the process >>> 1) Fetch data [ JDBC]from DB do some processing insert the >>> processed data into DB >>> 2) One of the process send data outside our system through >>> webservice >>> 3) One of the process receive data from outside and pushes into DB >>> so that our internal process can work accordingly >>> 4) Each process polls the data at given specified time for it >>> processing >>> >>> 5) Each process also use extensive logging >>> >>> Since it is a legacy system I do understand the above mentioned process >>> flow is horrible. I guess in past developers decided single process per JVM >>> to achieve modularity. >>> >>> >>> Any Help is appreciated >>> >>> Any case history related to telecom to convince my manager will highly >>> beneficial >>> >>> >>> Thanks >>> >>> San >>> _______________________________________________ >>> OSGi Developer Mail List >>> [email protected] >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >>> >>> -------- >>> Christopher Armstrong >>> [email protected] >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> [email protected] >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> >> >> -------- >> Christopher Armstrong >> [email protected] >> >> >> >> >> >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev >
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
