hey,
first (OT) here is a ref for a good classloader research paper
http://dev.acm.org/pubs/articles/proceedings/oops/286936/p36-liang/p36-liang
.pdf
then..
|Just out of curiosity, what's the real concern here? Load on the
|server due
|to redeployment of a large application or application downtime.
redeployment of the the large application and the fact that we want inVM
optimization with it (if possible).
right now I am investigating "exotic" CLs just for fun but I suspect that
really really large apps will have to do without CL integration...
marc
|If the real
|concern is application downtime, it may be possible to create a new jndi
|namespace and deploy the new version to that namespace. Old clients would
|continue to hit the old version while any new connections would be handled
|by the new. I put some thought into hot redeployment a while back (though
|admitedly, I didn't delve too deeply) and it struck me then that there's
|about a billion things that can go wrong when attempting to juggle
|classloaders. Not that namespace-switching is trivial; there's still quite
|a bit that must be worked out, but just a little food for thought...
|
|Mike
|
|----- Original Message -----
|From: "marc fleury" <[EMAIL PROTECTED]>
|To: "jBoss Developer" <[EMAIL PROTECTED]>
|Sent: Thursday, December 21, 2000 11:25 AM
|Subject: RE: [jBoss-Dev] The Dumbo problem (Big EARs)
|
|
|> |> if a,b,c are independently deployed EARs
|> |>
|> |> such that
|> |>
|> |> a
|> |> / \
|> |> b c
|> |
|> |Note that although this is a tree depiction, the real model is a set
|> |since all EAR's can relate to any other EAR.
|>
|> The real EJB-REF looks like
|>
|> a d e
|> / \ / |
|> b c f
|>
|> |You mean c or b is root? Actually the classloader chains from a can be
|> |(left is leaf, right is root):
|> |Ca-Cc (c holds all interfaces, including b. b has chain Cb-Cc, so b is
|> |also leaf)
|>
|> rickard please read my first line (hypothesis)... that the Ears are
|deployed
|> *independently*
|>
|> so Cb and Cc already exist in the runtime and are package indenpendently
|of
|> the a module being deployed.
|>
|> |Ca-Cb-Cc
|> |Ca-Cc-Cb
|> |Ca (a is root and contains interfaces for b and c)
|> |
|> |So, the ejb-ref dependency set and classloader tree are quite decoupled.
|> |Actually, if you keep ALL interfaces of the ENTIRE application in one
|> |EAR, then you can have n number of EARs with dependencies to all other
|> |n-1 EARs by simply letting all EARs have the EAR with the interfaces as
|> |classloader parent. I.e. a maximally shallow tree.
|>
|> Rickard, we deploy A b and c indenpendently.
|>
|> |> Also I don't really know how we can do that since Cb already
|> |exists and we
|> |> can't "setParent" on it outside construction time... (neither on
|> |Cc for the
|> |> second)
|> |
|> |Classloaders are recreated on redeploy, hence parent is passed as
|> |constructor argument.
|>
|> I think you missed the point, at the first deploy of A since Cb already
|> exists and we set Cc Cb we need to undeploy/redeploy Cb...
|>
|> in other terms Cb being already part of an application we need
|to stop the
|> other applications for CL considerations. (this is very fucked up)
|>
|> In clear we cannot link to other EARS independent in runtime.
|You need to
|> instanciate different containers to share entities and our container
|really
|> isn't built for that.
|>
|> Do you understand this point?
|>
|> |> here we see one of the first "arbitrary" problems introduced by the CL
|> |> delegation in that we need to order CL somehow and it is
|> |"arbitrary" and in
|> |> one case we need to redeploy applications just because they
|> |happen to be in
|> |> the line... (clearly not an optimal structure).
|> |
|> |The CL delegation tree needs to be explicit, which is why I introduced
|> |an XML notation that describes this tree. With new terminology we have:
|> |<application>
|> | <ear>
|> | <name>a</name>
|> | <url>...</url>
|> | <parent>b</parent>
|> | </ear>
|> | <ear>
|> | <name>b</name>
|> | <url>...</url>
|> | <parent>c</parent>
|> | </ear>
|> | <ear>
|> | <name>c</name>
|> | <url>...</url>
|> | </ear>
|> |</application>
|> |
|> |With this information there is no arbitrary decisions to make.
|>
|> LOL, you are putting in XML THE CLASSLOADER DEPENDENCY!!!!!!!!!
|>
|> no way... that is totally linked to the CL delegation model!!!!
|>
|> LOL you made my morning
|>
|> |> Also this "redeploy parts of it" assumes that the run-time is
|shut down
|> |> otherwise you are going to have live references with one old type and
|new
|> |> references with the new type. -> ClassCast at runtime just
|> |because you are
|> |> keeping references somewhere.
|> |
|> |Well, your above reasoning isn't correct so no, this will not happen
|>
|> what above "reasoning"... the fact that I don't put in XML the
|> dependencies?...
|>
|> please... understand the hypothesis, understand what hypothesis you are
|> proposing. and that the reasoning would be "hypothesis "let's put all CL
|> dependencies in XML" --> complete nightmare for administration --> stupid
|> idea"", that is a reasoning (implications).
|>
|> |> you know just thinking as I go... I believe we need a custom
|> |CL... something
|> |> more powerful than the URLCL with Delegation... that won't work
|> |
|> |UCL is just fine.
|>
|> There has to be a simpler way something with a flat CL ...
|>
|> |You are missing some points of this. You are not seeing the distinction
|> |between the ejb-ref dependencies and the classloader dependencies. They
|>
|> ??? what makes you think that?
|>
|> |are not really related (as I have outlined in earlier posts).
|> |
|> |During partial application redeploy you must consider the effects of
|> |BOTH when deciding what EAR's to redeploy. However, once you have
|> |understood that you will see that there is no arbitrary decisions to
|> |make, and that the whole thing is *very* deterministic in terms of
|> |behaviour.
|>
|> huh... where? by specifying the CL dependencies in XML????
|>
|> rickard, back to the drawing board...
|>
|> marc
|> |
|> |/Rickard
|> |
|> |--
|> |Rickard �berg
|> |
|> |Email: [EMAIL PROTECTED]
|> |
|> |
|>
|
|
|
