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
