You are viewing a plain text version of this content. The canonical link for it is here.
Posted to phoenix-dev@avalon.apache.org by Peter Royal <pr...@apache.org> on 2002/08/02 17:20:22 UTC
New DefaultKernel parameter
I added a (awkwardly named) new parameter to the DefaultKernel,
add-invalid-applications
Giving this element a value of true will cause applications that fail to
start() to still be added to phoenix. Why is this useful? Say you have a SAR
with incomplete config info (and you know this because you validated it
against your schemas), the app can be installed into phoenix but not started
and you can they use Phyre to fix the config (and save the missing bits on
disk with the FileSystemPersistentConfigurationRepository) and then start the
app back up :)
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: What is the preferred method of managing connections?
Posted by Berin Loritsch <bl...@apache.org>.
Ok.
> -----Original Message-----
> From: Peter Royal [mailto:proyal@apache.org]
> Sent: Tuesday, August 06, 2002 11:34 AM
> To: Avalon-Phoenix Developers List
> Subject: Re: What is the preferred method of managing connections?
>
>
> On Monday 05 August 2002 11:12 pm, Berin Loritsch wrote:
> > We currently have a ChannelManager, a ConnectionManager, and a
> > SocketManager. How do these work together.
>
> ChannelManager is for the NIO stuff in 1.4 (thats all I know
> on it. Kurt, the
> donator, said he was gonna send over some more but I haven't
> seen anything..)
>
> SocketManager just supports the creation of sockets. You can
> give it a type
> (plain/ssl), and then a port and IP and it will create a
> Socket/ServerSocket
> for you.
>
> ConnectionManager is used for ServerSocket's. You give it a
> ServerSocket and a
> ConnectionHandlerFactory, and whenever a connection is made
> it passes the new
> socket to the class that the ConnectionHandlerFactory creates. -pete
>
> --
> peter royal -> proyal@apache.org
>
> --
> To unsubscribe, e-mail:
> <mailto:avalon-phoenix-dev-> unsubscribe@jakarta.apache.org>
>
> For additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: What is the preferred method of managing connections?
Posted by Peter Royal <pr...@apache.org>.
On Monday 05 August 2002 11:12 pm, Berin Loritsch wrote:
> We currently have a ChannelManager, a ConnectionManager, and
> a SocketManager. How do these work together.
ChannelManager is for the NIO stuff in 1.4 (thats all I know on it. Kurt, the
donator, said he was gonna send over some more but I haven't seen anything..)
SocketManager just supports the creation of sockets. You can give it a type
(plain/ssl), and then a port and IP and it will create a Socket/ServerSocket
for you.
ConnectionManager is used for ServerSocket's. You give it a ServerSocket and a
ConnectionHandlerFactory, and whenever a connection is made it passes the new
socket to the class that the ConnectionHandlerFactory creates.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
What is the preferred method of managing connections?
Posted by Berin Loritsch <bl...@apache.org>.
We currently have a ChannelManager, a ConnectionManager, and
a SocketManager. How do these work together.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New DefaultKernel parameter
Posted by Peter Royal <pr...@apache.org>.
On Saturday 03 August 2002 07:43 pm, Peter Donald wrote:
> Perhaps an idea we can kick about is adding a section like the following
> into the SAR-INF/environment.xml file.
>
> <install>
> <start-on-install>false</start-on-install>
> <!--
> Insert other funky commands that only happen
> on install.
> -->
> </install>
>
> Then this section would be used only when you install app.
Good solution. We could also control SAR expansion from there too.
> > That way any errors could be detected before the app is started.
> > Unfortunately this does not mesh will with how Phoenix loads an app
> > currently, as it only attempt to retrieve configuration information if a
> > block implements Configurable. Perhaps we could augment the .xinfo
> > document to include whether or not a block has config?
>
> We could do that - or maybe just indicate which blocks have schemas to
> validate against. Not sure - I will have to have a look at the code again
> ;)
A block with a schema is already known, the BlockDescriptor has a m_schemaType
which is non-null for blocks with a schema.
I'll see about implementing a combination of the two above ideas.. the
environment block as well as the pre-validation before a startup attempt. It
may be a few days as my at-work time to hack phoenix has come to a close for
now, back to higher-level app-specific stuff.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New DefaultKernel parameter
Posted by Peter Donald <pe...@apache.org>.
On Sat, 3 Aug 2002 23:05, Peter Royal wrote:
> > However for backwards compatability we include a flag "quickdeploy" (or
> > something) that will automatically start an app when it is deployed
> > (effectively skippin [2]).
> >
> > Thoughts?
>
> I like the "start phoenix and start all apps behavior". I only need what
> you describe above for the very first installation of our application.
> Subsequent installations (upgrades) should just run the app if possible.
> (So when our users inevitable restart their win32 servers, when the phoenix
> service starts back up it will restart the app w/o manual intervention).
Perhaps an idea we can kick about is adding a section like the following into
the SAR-INF/environment.xml file.
<install>
<start-on-install>false</start-on-install>
<!--
Insert other funky commands that only happen
on install.
-->
</install>
Then this section would be used only when you install app.
> The ideal solution (in my eyes) would be to gather/validate all the
> configuration information for an application before starting any blocks.
thats a good idea.
> That way any errors could be detected before the app is started.
> Unfortunately this does not mesh will with how Phoenix loads an app
> currently, as it only attempt to retrieve configuration information if a
> block implements Configurable. Perhaps we could augment the .xinfo document
> to include whether or not a block has config?
We could do that - or maybe just indicate which blocks have schemas to
validate against. Not sure - I will have to have a look at the code again ;)
--
Cheers,
Peter Donald
-----------------------------------------------
"You can't depend on your eyes when your
imagination is out of focus." -Mark Twain
-----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New DefaultKernel parameter
Posted by Peter Royal <pr...@apache.org>.
On Saturday 03 August 2002 03:29 am, Peter Donald wrote:
> On Sat, 3 Aug 2002 01:20, Peter Royal wrote:
> > I added a (awkwardly named) new parameter to the DefaultKernel,
> > add-invalid-applications
> >
> > Giving this element a value of true will cause applications that fail to
> > start() to still be added to phoenix. Why is this useful? Say you have a
> > SAR with incomplete config info (and you know this because you validated
> > it against your schemas), the app can be installed into phoenix but not
> > started and you can they use Phyre to fix the config (and save the
> > missing bits on disk with the
> > FileSystemPersistentConfigurationRepository) and then start the app back
> > up :)
>
> It may be better to do it slightly differently.
> 1. Deploy/install app
> 2. Configure app if necessary
> 3. Manually Start App
>
> The difference being that you wont try to start an application and fail. I
> am nervous about that as some blocks may have unintended sideeffects even
> when they fail.
Valid concern :) I just did what was easiest to do in 30m :)
> However for backwards compatability we include a flag "quickdeploy" (or
> something) that will automatically start an app when it is deployed
> (effectively skippin [2]).
>
> Thoughts?
I like the "start phoenix and start all apps behavior". I only need what you
describe above for the very first installation of our application. Subsequent
installations (upgrades) should just run the app if possible. (So when our
users inevitable restart their win32 servers, when the phoenix service starts
back up it will restart the app w/o manual intervention).
My sole motivation for the switch was to allow for the modification of
configuration information on the initial installation (so we could ship the
app w/o a jdbc dburl configured plus a few other options that we can't really
default).
The ideal solution (in my eyes) would be to gather/validate all the
configuration information for an application before starting any blocks. That
way any errors could be detected before the app is started. Unfortunately
this does not mesh will with how Phoenix loads an app currently, as it only
attempt to retrieve configuration information if a block implements
Configurable. Perhaps we could augment the .xinfo document to include whether
or not a block has config?
Just more thoughts... I'm out and about this weekend so may be slow replying.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New DefaultKernel parameter
Posted by Peter Donald <pe...@apache.org>.
On Sat, 3 Aug 2002 01:20, Peter Royal wrote:
> I added a (awkwardly named) new parameter to the DefaultKernel,
> add-invalid-applications
>
> Giving this element a value of true will cause applications that fail to
> start() to still be added to phoenix. Why is this useful? Say you have a
> SAR with incomplete config info (and you know this because you validated it
> against your schemas), the app can be installed into phoenix but not
> started and you can they use Phyre to fix the config (and save the missing
> bits on disk with the FileSystemPersistentConfigurationRepository) and then
> start the app back up :)
It may be better to do it slightly differently.
1. Deploy/install app
2. Configure app if necessary
3. Manually Start App
The difference being that you wont try to start an application and fail. I am
nervous about that as some blocks may have unintended sideeffects even when
they fail.
However for backwards compatability we include a flag "quickdeploy" (or
something) that will automatically start an app when it is deployed
(effectively skippin [2]).
Thoughts?
--
Cheers,
Peter Donald
*----------------------------------------------------------*
The phrase "computer literate user" really means the person
has been hurt so many times that the scar tissue is thick
enough so he no longer feels the pain.
-- Alan Cooper, The Inmates are Running the Asylum
*----------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>