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
