Hi,
I'm building a simple web application with an embedded Magma database which will run on a headless Linux appliance.
A few times while developing the system, I've had a dialog window when starting Squeak which has asked me to OK a recovery of the Magma database.
Obviously I won't have a UI on this headless appliance. What do I need to do to make sure all of those types of interaction are handled by my application?
Thanks,
Jerry
Hi Jerry, yes Magma may signal warnings which you will need to handle if you want to run headless. Are you familiar with handling exceptions in Squeak? Here is the pattern:
[ ..do some squeak code.. ] on: Warning do: [ : warning | ..log the warning somewhere if you want... warning resume ]
Honestly, I'm curious why you would be receiving that particular warning..
On Fri, Sep 12, 2008 at 4:15 PM, Jerry Bell jdbell@oxfordmetamedia.com wrote:
Hi,
I'm building a simple web application with an embedded Magma database which will run on a headless Linux appliance.
A few times while developing the system, I've had a dialog window when starting Squeak which has asked me to OK a recovery of the Magma database.
Obviously I won't have a UI on this headless appliance. What do I need to do to make sure all of those types of interaction are handled by my application?
Thanks,
Jerry
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
After more thinking, there is a (fairly common!) scenario where developers will not feel the need to wrap the MagmaServerConsole in their own application-server wrapper. In other words, just a plain vanilla Magma server image.
In these cases, a Magma server image is simply saved and exited while its running, and this can even be performed remotely ("mySession serverSaveAndExit").
Under this case, when the server image is restarted, only Magma's own startUp: code re-establishes the files and sockets, your application code will not have the opportunity to handle any warnings if there are any.
I will fix that..
- Chris
On Fri, Sep 12, 2008 at 7:12 PM, Chris Muller asqueaker@gmail.com wrote:
Hi Jerry, yes Magma may signal warnings which you will need to handle if you want to run headless. Are you familiar with handling exceptions in Squeak? Here is the pattern:
[ ..do some squeak code.. ] on: Warning do: [ : warning | ..log the warning somewhere if you want... warning resume ]
Honestly, I'm curious why you would be receiving that particular warning..
On Fri, Sep 12, 2008 at 4:15 PM, Jerry Bell jdbell@oxfordmetamedia.com wrote:
Hi,
I'm building a simple web application with an embedded Magma database which will run on a headless Linux appliance.
A few times while developing the system, I've had a dialog window when starting Squeak which has asked me to OK a recovery of the Magma database.
Obviously I won't have a UI on this headless appliance. What do I need to do to make sure all of those types of interaction are handled by my application?
Thanks,
Jerry
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
My understanding of Magma so far is very superficial, there is a lot of 'magic' happening right now. I'm sure that will change as I get more experience with the system. I've only seen the error I described a couple of times so far but I wanted to make sure I could handle it in a headless application, if it was not handled already.
I have not worked in Squeak very much, and I've never seen that warning idiom. It looks simple enough. But, I'm using the Magma seasideHelper (specifically, I'm using WAMagmaSoloAuto.) , so I'm not sure where to put the warning handlers. Any suggestions are welcome!
I believe I'd prefer to have my image start from a clean state with no existing Magma sessions. I believe that is happening now, but I'm not sure. I don't save the server image, I always either quit without saving the image, or the server might possibly be shutdown "dirty" without any warning.
Another question: I have a few "long running" operations which should be triggered from the web application, but which should run in their own background process without blocking the web interface. For example, I generate RSS feeds for some of my database contents. What's the best way to handle this? Currently i make a deepCopy of my target object, and fork the operation as a separate process with that copy. If I need to access the database in that forked process, I use
(WAMagma forApp: 'appName') rootAs: MyServerRoot
Without the deepCopy, I believe I was attempting to access a Magma proxy outside of the Seaside session, and I would sometimes get magma proxy errors.
I think it might be better if I passed the unique ID of my target object to the new process, and let it use that ID to find the target object and access everything from the database through "direct access" instead of using a deepCopy.
Also, how should I handle the "direct access"? Is it ok to do a
myDB := (WAMagma forApp: 'appName') rootAs: MyServerRoot
the first time I need it, and then use it over and over again? If so, do I need to do an abortSession on it from time to time to keep it up to date with changes from the web interface? Perhaps I should do an abortSession before each time I use it? Do I need to do anything to close that session when the Squeak image quits?
Thanks,
Jerry
On Sep 14, 2008, at 11:04 AM, Chris Muller wrote:
After more thinking, there is a (fairly common!) scenario where developers will not feel the need to wrap the MagmaServerConsole in their own application-server wrapper. In other words, just a plain vanilla Magma server image.
In these cases, a Magma server image is simply saved and exited while its running, and this can even be performed remotely ("mySession serverSaveAndExit").
Under this case, when the server image is restarted, only Magma's own startUp: code re-establishes the files and sockets, your application code will not have the opportunity to handle any warnings if there are any.
I will fix that..
- Chris
On Fri, Sep 12, 2008 at 7:12 PM, Chris Muller asqueaker@gmail.com wrote:
Hi Jerry, yes Magma may signal warnings which you will need to handle if you want to run headless. Are you familiar with handling exceptions in Squeak? Here is the pattern:
[ ..do some squeak code.. ] on: Warning do: [ : warning | ..log the warning somewhere if you want... warning resume ]
Honestly, I'm curious why you would be receiving that particular warning..
On Fri, Sep 12, 2008 at 4:15 PM, Jerry Bell <jdbell@oxfordmetamedia.com
wrote: Hi,
I'm building a simple web application with an embedded Magma database which will run on a headless Linux appliance.
A few times while developing the system, I've had a dialog window when starting Squeak which has asked me to OK a recovery of the Magma database.
Obviously I won't have a UI on this headless appliance. What do I need to do to make sure all of those types of interaction are handled by my application?
Thanks,
Jerry
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
Hi Jerry,
I believe I'd prefer to have my image start from a clean state with no existing Magma sessions.
Well, a "clean slate" would mean you start from a base image every time and reload all the code too. They're just objects like everything else. It's not any cleaner.
I believe that is happening now, but I'm not sure. I don't save the server image, I always either quit without saving the image, or the server might possibly be shutdown "dirty" without any warning.
Magma can handle the server image being shutdown in a variety of ways, 1) saving and exiting, exiting without saving, killing the VM or pulling the plug on the host computer.
Another question: I have a few "long running" operations which should be triggered from the web application, but which should run in their own background process without blocking the web interface. For example, I generate RSS feeds for some of my database contents. What's the best way to handle this? Currently i make a deepCopy of my target object, and fork the operation as a separate process with that copy. If I need to access the database in that forked process, I use
(WAMagma forApp: 'appName') rootAs: MyServerRoot
Without the deepCopy, I believe I was attempting to access a Magma proxy outside of the Seaside session, and I would sometimes get magma proxy errors.
Not sure, I'm not familiar with WA stuff. But the #deepCopy doesn't sound like a good approach to me.
I think it might be better if I passed the unique ID of my target object to the new process, and let it use that ID to find the target object and access everything from the database through "direct access" instead of using a deepCopy.
Well, what's the purpose of the unique ID in an ODBMS? An ID has the same "weight" as any object; one object pointer, so maybe you can just pass the object iself..
Also, how should I handle the "direct access"? Is it ok to do a
myDB := (WAMagma forApp: 'appName') rootAs: MyServerRoot
the first time I need it, and then use it over and over again?
Umm, sure.
If so, do I need to do an abortSession on it from time to time to keep it up to date with changes from the web interface?
Well, that can sometimes be useful, depending on the application..
Perhaps I should do an abortSession before each time I use it? Do I need to do anything to close that session when the Squeak image quits?
Connected sessions when you save the image, are reconnected automatically when you return to the image.. See MagmaSession class>>#connectedSessions.
Thanks,
Jerry
- Chris
On Sep 14, 2008, at 11:04 AM, Chris Muller wrote:
After more thinking, there is a (fairly common!) scenario where developers will not feel the need to wrap the MagmaServerConsole in their own application-server wrapper. In other words, just a plain vanilla Magma server image.
In these cases, a Magma server image is simply saved and exited while its running, and this can even be performed remotely ("mySession serverSaveAndExit").
Under this case, when the server image is restarted, only Magma's own startUp: code re-establishes the files and sockets, your application code will not have the opportunity to handle any warnings if there are any.
I will fix that..
- Chris
On Fri, Sep 12, 2008 at 7:12 PM, Chris Muller asqueaker@gmail.com wrote:
Hi Jerry, yes Magma may signal warnings which you will need to handle if you want to run headless. Are you familiar with handling exceptions in Squeak? Here is the pattern:
[ ..do some squeak code.. ] on: Warning do: [ : warning | ..log the warning somewhere if you want... warning resume ]
Honestly, I'm curious why you would be receiving that particular warning..
On Fri, Sep 12, 2008 at 4:15 PM, Jerry Bell jdbell@oxfordmetamedia.com wrote:
Hi,
I'm building a simple web application with an embedded Magma database which will run on a headless Linux appliance.
A few times while developing the system, I've had a dialog window when starting Squeak which has asked me to OK a recovery of the Magma database.
Obviously I won't have a UI on this headless appliance. What do I need to do to make sure all of those types of interaction are handled by my application?
Thanks,
Jerry
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
Jerry Bell wrote:
My understanding of Magma so far is very superficial, there is a lot of 'magic' happening right now. I'm sure that will change as I get more experience with the system. I've only seen the error I described a couple of times so far but I wanted to make sure I could handle it in a headless application, if it was not handled already.
I have not worked in Squeak very much, and I've never seen that warning idiom. It looks simple enough. But, I'm using the Magma seasideHelper (specifically, I'm using WAMagmaSoloAuto.) , so I'm not sure where to put the warning handlers. Any suggestions are welcome!
I think that the warnings happen on the server side, when the image is restarting. So there is no way to wrap them on the client side. Chris says that he has sorted this.
I believe I'd prefer to have my image start from a clean state with no existing Magma sessions. I believe that is happening now, but I'm not sure. I don't save the server image, I always either quit without saving the image, or the server might possibly be shutdown "dirty" without any warning.
The "Magma" control panel, lists all of the open sessions. Do you have that working?
Another question: I have a few "long running" operations which should be triggered from the web application, but which should run in their own background process without blocking the web interface.
WAMagma (and subclasses) have a hook (in theory) which runs after the seaside query has been serviced. I.e. it is non-blocking.
#postProcessRequest: aRequest returned: aResponse
Alternatively if you wish to spawn a background process, then it should/could be spawned in the context of a dummy WASession+Configuration. (WAMagma forApp: 'myapp') is provided for this purpose.
For example, I generate RSS feeds for some of my database contents. What's the best way to handle this? Currently i make a deepCopy of my target object, and fork the operation as a separate process with that copy. If I need to access the database in that forked process, I use
(WAMagma forApp: 'appName') rootAs: MyServerRoot Without the deepCopy, I believe I was attempting to access a Magma proxy outside of the Seaside session, and I would sometimes get magma proxy errors.
This is my guess - I think you are taking an object from one session and using it in another, in the middle of this the first session may be discarded, leaving the second thread with un-referenced object ids. Your work around is to deep copy it in the context of the first session, before forking.
The correct approach is to obtain your object from the database from the correct managing session, i.e.
newMagmaSession := WAMagma forApp: 'appName'.
[ (newMagmaSession rootAs: MyServerRoot) getTheObjectIWant writeToRss ] fork.
Alternatively, if you are using a WAMagmaShared helper in your application. You could use
newMagmaSession := WAMagmaShared forApp: 'appName'.
This would use the same shared magma session as seaside is using, so the data may already be cached in memory, but #aborts and #commits are controlled with a semaphore.
I think it might be better if I passed the unique ID of my target object to the new process, and let it use that ID to find the target object and access everything from the database through "direct access" instead of using a deepCopy.
Also, how should I handle the "direct access"? Is it ok to do a
myDB := (WAMagma forApp: 'appName') rootAs: MyServerRoot
the first time I need it, and then use it over and over again? If so, do I need to do an abortSession on it from time to time to keep it up to date with changes from the web interface?
Yes, unless you use a shared session.
Perhaps I should do an abortSession before each time I use it? Do I need to do anything to close that session when the Squeak image quits?
In theory it can simply restart where it left off.
Thanks for checking this out, I admit it is a bit experimental in parts.
best regards
Keith
Thanks,
Jerry
On Sep 14, 2008, at 11:04 AM, Chris Muller wrote:
After more thinking, there is a (fairly common!) scenario where developers will not feel the need to wrap the MagmaServerConsole in their own application-server wrapper. In other words, just a plain vanilla Magma server image.
In these cases, a Magma server image is simply saved and exited while its running, and this can even be performed remotely ("mySession serverSaveAndExit").
Under this case, when the server image is restarted, only Magma's own startUp: code re-establishes the files and sockets, your application code will not have the opportunity to handle any warnings if there are any.
I will fix that..
- Chris
On Fri, Sep 12, 2008 at 7:12 PM, Chris Muller asqueaker@gmail.com wrote:
Hi Jerry, yes Magma may signal warnings which you will need to handle if you want to run headless. Are you familiar with handling exceptions in Squeak? Here is the pattern:
[ ..do some squeak code.. ] on: Warning do: [ : warning | ..log the warning somewhere if you want... warning resume ]
Honestly, I'm curious why you would be receiving that particular warning..
On Fri, Sep 12, 2008 at 4:15 PM, Jerry Bell jdbell@oxfordmetamedia.com wrote:
Hi,
I'm building a simple web application with an embedded Magma database which will run on a headless Linux appliance.
A few times while developing the system, I've had a dialog window when starting Squeak which has asked me to OK a recovery of the Magma database.
Obviously I won't have a UI on this headless appliance. What do I need to do to make sure all of those types of interaction are handled by my application?
Thanks,
Jerry
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
magma@lists.squeakfoundation.org