adequate
adequate
adequate
adequate
Home
About
Download
Documentation
Forums
May 20, 2013, 02:16:48 AM
Welcome,
Please
login
or
register
.
1 Hour
1 Day
1 Week
1 Month
Forever
Login with username, password and session length
News
:
Registered users, your contribution is requested! Please participate in our
JDK support poll
New users, please read
this message
. Thank you!
Home
Help
Search
Login
Register
« previous
next »
Pages: [
1
]
Go Down
Print
Author
Topic: preliminary information (Read 3713 times)
pepe
JPPF Padawan
Posts: 3
preliminary information
«
on:
December 05, 2006, 12:53:23 PM »
Hello.
I am actually investigating the use of your API for some fault tolerant/rmi-like needs of us.
The company i work for creates software to handle cinema ticketing. We need to have the network setup so as if the server/lan/wan fail, we have a way to keep on working without any data loss.
Customer ticket generation would be done on thin client machines, all operations would occur on servers that would hold drivers and nodes.
What i was thinking about was to setup even the thin machines to each have a driver, but at a lower priority than the master one (as a peer?) so that if the master one fails, or the network fails, everything would still work normally.
There are numerous questions raised by this:
Can we assign priorities to drivers, so that local one is used only if all others can't be reached?
Is there a need for a real master server, or can the peering occur without any needed to statically be first to init peering?
thanks a lot.
Logged
lolo
Administrator
JPPF Council Member
Posts: 1431
preliminary information
«
Reply #1 on:
December 05, 2006, 03:34:05 PM »
Hello pepe,
I would like to have a clarification on the thin machines configuration you are envisioning: you are considering having a driver on it so the client can fall back to it, should the main driver fail. I am assuming that there would also be at least one node running on that thin machine, connected to the corresponding driver, is that correct?
This is definitely a point that we have not worked on so far, we only have discussed it. Currently, clients can only connect to one driver, which creates a single point of failure from the client's point of view. This is not acceptable, and I am making it one of our priorities for the short term, which means I am committing to implement a set of features that will take care of this, and include it in our next release.
Now, let's create the major requirements, as a foundation for this feature:
a client should be able to connect to multiple drivers
a client should be able to prioritize the drivers it is connected to, the priority constituting an ordering for the drivers the client falls back to.
example: if a driver with an assigned priority of 2 fails, the client should fall back to the available driver with the highest priority
drivers with the same priority should be used as a pool to further parallelize and distribute the work submitted by the client
Please let me know if that would fulfill your requirements, and feel free to add to or correct what we said.
For the record, I have added the following feature request:
"
Clients only connect to one driver
"
Feel free to consult or update it.
Sincerely,
-Laurent
Logged
pepe
JPPF Padawan
Posts: 3
preliminary information
«
Reply #2 on:
December 05, 2006, 05:54:42 PM »
Hello, Laurent.
Well, yes, you assumed it right, the machines would also run a node so that it can be independent (while this can cause legal problems at the moment, so it might not occur)
You also perfectly understood the requirements about drivers priorities.
May i ask what is "short term", for you?
If we are to use jppf for our system, i will certainly also be able to commit features and bug corrections. What is the requirement for me to become developper if needed?
Logged
lolo
Administrator
JPPF Council Member
Posts: 1431
preliminary information
«
Reply #3 on:
December 05, 2006, 06:12:35 PM »
Pepe,
I commited to have this feature in the next release, and it will be in December of this year. As I do not have yet a clear idea of the level of effort required, I can't guarantee anything more precise. So let's make it end of December for now at the latest, earlier if we can.
-Laurent
Logged
pepe
JPPF Padawan
Posts: 3
preliminary information
«
Reply #4 on:
December 06, 2006, 10:02:23 AM »
I did not mean to hurry you or anyone, please pardon me if it sounded like i was asking something along those lines.
I am waiting with great impatience to start playing with your API, as soon as it matches our needs.
I will be watching here and on the bug report for any advancement and will test any preview you will publish.
Thanks.
Logged
lolo
Administrator
JPPF Council Member
Posts: 1431
preliminary information
«
Reply #5 on:
December 06, 2006, 02:51:09 PM »
Thank you pepe,
No problem here. I appreciate you requesting new features and improvements to the framework. JPPF can only be alive if people like you use it. Otherwise, we're just writing code.
I sent you a PM about your contributing to JPPF. If you want to join us, please send me an email at
lcohen at free dot fr
with your Sourceforge.net user id and let me know how you see yourself contributing now and in the future.
-Laurent
Logged
Print
Pages: [
1
]
Go Up
« previous
next »
JPPF Forums
>
JPPF Help
>
Installation and Configuration
>
preliminary information
Loading...