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 < carmstr...@fastmail.com.au> 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 < > carmstr...@fastmail.com.au> 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 >> osgi-dev@mail.osgi.org >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> >> >> -------- >> Christopher Armstrong >> carmstr...@fastmail.com.au >> >> >> >> >> >> >> _______________________________________________ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > -------- > Christopher Armstrong > carmstr...@fastmail.com.au > > > > > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev >
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
