Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

suncertify.properties conflict on single machine in network mode

 
Ronald Wouters
Ranch Hand
Posts: 190
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

in URLyBird we have to save the suncertify.properties file in the current working directory. Here is a scenario I would like your opinion on:
Start server in new shell/commandprompt window in directory containing runme.jar and existing suncertify.properties file.
Then start (remote) network client, on SAME host machine, second new shell/commandprompt window, same directory as server...
It seems to me that, whoever saves the properties last, client or server, will overwrite changes made by the other ... right ?
Anyone handled this scenario ?

Regards,
Ronald Wouters
 
Aruneesh Salhotra
Ranch Hand
Posts: 167
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why dont you segregate properties based on local, client and network.
Like RMI port in client and network.
 
Ronald Wouters
Ranch Hand
Posts: 190
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

separating properties won't do any good because in the end they have to be stored in the same file (suncertify.properties) in the same directory on the same host anyway...
Obviously when running client and server on different hosts this is no problem but on the same host ?
URLyBird only allows exactly one properties file, NOT a separate property file for the client and another one for the server.
You see the problem ?

Regards,
Ronald Wouters
[ February 18, 2006: Message edited by: Ronald Wouters ]
 
Kevin Conaway
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ronald,

The properties should never really conflict.

There are 3 scenarios:

A.) Server. Uses database location and port

B.) Standalone client. Uses database location which should be the same as A.)

C.) Network client. Uses hostname and port. The port will have to be the same as what the Server used, otherwise it couldn't connect.

I don't see a real conflict there. If you're still concerned about it, perhaps you should only allow the user to enter the configuration properties at the start of the program and then use those for the duration of the users session.

Kevin
 
Ronald Wouters
Ranch Hand
Posts: 190
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't think I made myself clear enough. Let me try to explain.
It is NOT the properties themselves that cause a conflict. It is the fact that when the properties are saved to disk, both the client and the server will write their respective properties to the SAME file, suncertify.properties.
So, when the client saves it's properties to disk the suncertify.properties file will ONLY contain client properties. If the server writes it's properties to disk, the same file, suncertify.properties, will then ONLY contain the server properties.
Again, it isn't the properties themselves that are the problem, it is the fact that they are written to the same file, same directory, same host that is the problem. Well, at least when network testing is done with the client and server run on the same host machine. As I stated before, running client and server on different machines will not be a problem because then we are dealing with two physically different properties files, one on the client host and another, with the same name (suncertify.properties), on the server host.
Writing to properties to disk is done using the Properties.store method. Obviously the store method only writes to disk what is contained in the Properties object itself, which will be either ONLY the client properties or ONLY the server properties.
Hopefully I explained the situation a bit clearer.
Maybe I am just being a bit overly concerned...

Regards,
Ronald Wouters
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ronald,

I suspect the problem you are thinking about is most likely to come about if you do not store the properties until just before the program exits (there is another case that I will describe below). But there is no need to do this - by the time the program is past the configuration stage (that is, the server is interacting with clients, or the client is interacting with the end user) then the basic configuration is set, and there should be no need to change the properties.

One thing that you did not mention in your description of the potential problem is the reason why the properties file exists: to provide a way to reload an old configuration. So with that in mind, a more likely sequence of events is:
  • Server reads properties file
  • User makes changes to configuration
  • Server saves properties file to disk
  • Server starts listening for client requests and processing them as necessary
  • A little while later we have:
  • Client reads properties file
  • User makes changes to configuration
  • Client saves properties file to disk
  • Client connects to server and starts interacting with end user to make bookings
  • So in this standard scenario, in it's first step the client application read the properties file thereby reading all the server properties. Then when the properties file is written back to the server, the server properties will be written back as well.

    So - for the standard scenario, there is no problem.

    However there is still a less likely event that you might want to think about - a race condition. For example:
  • Server starts
  • Client starts
  • Server configuration properties changed
  • Client configuration properties changed
  • (Or any variation in the above, as long as two applications are in the same state where they have read the properties file but not written it back concurrently.)

    The easiest solution is to acknowledge that the problem exists but declare it out of scope.

    You could try getting a java.nio.channels.FileLock on the file itself, thereby preventing the above scenario (but be aware that "Whether or not a lock actually prevents another program from accessing the content of the locked region is system-dependent and therefore unspecified." (from the API).

    You can also look at the java.io.File modified() method - check the time you originally read the properties; then when you are about to write the properties check the time again - if the time has changed you may have to re-read the saved properties and merge them with your changed properties.

    Perhaps a combination of the two previous techniques might help?

    By the way - only saving the properties file if a property has changed may go a long way to reducing the chances of two applications overwriting each other's properties.

    Regards, Andrew
     
    Ronald Wouters
    Ranch Hand
    Posts: 190
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Andrew,
    for the standard scenario, there is no problem

    I agree, if as you said the properties are saved at once and not when the program exits. I guess I should abandon the idea then of saving the properties in a shutdown hook.
    You could try getting a java.nio.channels.FileLock on the file itself

    I don't use NIO whatsoever exactly because of these "system dependencies" and mentioned that in my choices document.
    You can also look at the java.io.File modified() method ... you may have to re-read the saved properties and merge them with your changed properties.

    I had already planned of always re-reading the properties file and then merging with the changed properties. I believed this to be the only way of solving the problem if I stick with my original idea of saving the properties in a shutdown hook (which I don't think I will do now). Glad to hear someone else tought of this possibility too. I hadn't tought of using the lastModified() method to check the time the file was modified. Thanks for the tip. It will save an unnecessary IO operation.
    only saving the properties file if a property has changed may go a long way to reducing the chances of two applications overwriting each other's properties.

    I am already using the java.beans.PropertyChangeSupport firePropertyChange method. The API docs for the firePropertyChange method say "No event is fired if old and new are equal and non-null". So I guess that puts me in the clear there at least.

    Again, thanks for your help.

    Regards, Ronald.
    [ February 19, 2006: Message edited by: Ronald Wouters ]
     
    Hans Crol
    Greenhorn
    Posts: 12
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi all,

    In my requirements (B&S) there also stated that configuration properties should be kept in one file : suncertify.properties in the current working directory to save the program's current state between two runs. But IMO it is not clear if it means that the file should be used for both the client program and the server program.
    To me this looks like bad practice. The server program does not need the gui related client properties and the client does not need things like the serverside database file location. Using one file for both also causes a lot of trouble while running both programs from the same working directory.
    Would'nt it be better just to separate client and server properties in two different files (suncertify.properties for the client program en suncertify.server.properties for the server program) ?
    It is a simple and clean solution. May be it does not match the requirements, but if this was a real project, I would go and try to convince my client to change that requirement. It will cost money for no added value.

    Regards,
    Hans
     
    Ronald Wouters
    Ranch Hand
    Posts: 190
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Hans,
    Would'nt it be better just to separate client and server properties in two different files (suncertify.properties for the client program en suncertify.server.properties for the server program) ?
    It is a simple and clean solution.

    When running the application in network mode on a single host, that is client and server started on the same machine, I agree completely that this would be "cleaner".
    Remember though that when running client and server on different machines we already have two distinct and separate property files, one on the client machine and another one on the server machine. These two files will have the same name though, that's true, but in this case (two different hosts) I don't really find that to be a problem.
    May be it does not match the requirements...

    In my case it doesn't, my instructions clearly call for a single property file.

    Regards, Ronald.
     
    Hans Crol
    Greenhorn
    Posts: 12
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Ronald,

    Are you very sure this is a MUST requirement that could make you fail automatically ?
    In my instructions (B&S 2.1.1) I read this :

    "All configuration must be done via a GUI, and must be persistent between runs of the program. Such configuration information must be stored in a file called suncertify.properties which must be located in the current working directory."

    In my interpretation this is only meant for the client program since as far as I know we do not have to provide a GUI for the server program.
    So I felt free to use a separate *.properties file for the server program. Maybe I have understood this wrong ? Have you ever heard of anymone automatically failed because of using another properties file for the server program ?

    I have almost finished my assignment, and I would like to clear this out before I submit.

    Thanks and regards,

    Hans
     
    Ronald Wouters
    Ranch Hand
    Posts: 190
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Hans,

    my instructions (URLyBird) have the exact same phrase about the suncertify.properties file as your instructions.
    In my interpretation this is only meant for the client program since as far as I know we do not have to provide a GUI for the server program.

    In my URLyBird implementation, when starting the URLyBird server, the user is also shown a "server gui" where they must enter the location of the database file (JFileChooser, on the server machine) and also a port number on which the RMI registry will listen. These properties are also saved in the suncertify.properties file so the user doesn't have to enter them the next time they start the server.
    Doesn't B&S have these sort of requirements ?

    Have you ever heard of anymone automatically failed because of using another properties file for the server program ?

    No, I haven't, but why take the risk ?

    Hope this helps.
    Regards, Ronald.
    [ March 19, 2006: Message edited by: Ronald Wouters ]
     
    Hans Crol
    Greenhorn
    Posts: 12
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Ronald,

    In my URLyBird implementation, when starting the URLyBird server, the user is also shown a "server gui" where they must enter the location of the database file (JFileChooser, on the server machine) and also a port number on which the RMI registry will listen. These properties are also saved in the suncertify.properties file so the user doesn't have to enter them the next time they start the server.
    Doesn't B&S have these sort of requirements ?


    Yes indeed I have the same in B&S. I do this with my suncertify.server.properties file. I assumed there was no GUI needed for the server, so I provided the defaults for the RMI registry port and the database file location in a separate suncertify.server.properties file. As long as the server administrator runs the server from the defaults, he will not need to edit this file (which I think matches the 'must' requirement of no need to edit any properties files). If he wants something non-default, he will have to edit the properties file.
    I have always thought a server 'd rather not depend on a GUI and that it even should run on machines without any windowing system.

    On the other hand, as you said : why take the risk ? Maybe I'd better provide some simple server GUI and write some extra code to manage the one and only suncertify.properties when both programs run in the same current working directory.

    Regards,

    Hans
     
    Yupp Cook
    Ranch Hand
    Posts: 49
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by Ronald Wouters:


    In my URLyBird implementation, when starting the URLyBird server, the user is also shown a "server gui" where they must enter the location of the database file (JFileChooser, on the server machine) and also a port number on which the RMI registry will listen. These properties are also saved in the suncertify.properties file so the user doesn't have to enter them the next time they start the server.


    Hi

    2 Questions

    (1)
    I thought like Hans that no server gui is needed so my question is:
    What should happen to the server gui when configuration is finished?
    Closing it just keeping open the prompt window?

    (2)
    Rereading the spec of BS2.1.2 it says:
    All configuration must be done via a GUI...
    Could the character encoding also be considered to be part of the configuration? So far I define it in an interface called Constants.java

    Regards
    Yupp
     
    Ronald Wouters
    Ranch Hand
    Posts: 190
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi,

    What should happen to the server gui when configuration is finished?
    Closing it just keeping open the prompt window?

    In my implementation once the user has entered the configuration data, they click the "start server" button which then becomes disabled. The Server window simply stays visible on screen until the user is ready to shut down the server. The user can shut down the server by clicking on the Exit button in the server gui. Obviously this should only be done when you are sure no clients are connected. When testing yourself on a single machine this is easy, just shut down the client first, then hit the exit button in the server gui.
    Could the character encoding also be considered to be part of the configuration? So far I define it in an interface called Constants.java

    In my implementation I don't have the character encoding in the properties file nor do I have a field for it in either the server or the client configuration gui. I guess keeping the configuration gui to the bare minimum and as a result the content of the suncertify.properties file should be the deciding factor on deciding what to put where. Just don't go overboard

    Regards, Ronald.
     
    Long Ng
    Greenhorn
    Posts: 28
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi,
    I think, someone should asks Sun about this problem for sure, we shouldn't be failed because of it.
    For me, I think it's a bug of the assignment.

    Thanks,
    Long Nguyen

    [ March 20, 2006: Message edited by: Long Ng ]
    [ March 20, 2006: Message edited by: Long Ng ]
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic