This content has been marked as final. Show 11 replies
it is not possible to do it now (sure in the future), what is possible to do is to start two jboss on the same machine with the binding service that will configure the two jboss instances with different ports to avoid conflicts.
Should some services not be installed to get two jbosses running?
I get port conflicts on port 4444 and 1098 for JRMPInvoker and Namingservice.
you should not have to disable any services to get two instances up and running.
you may have accidently specified both instances use those ports, which is why you may be getting conflicts.
after some port tweaking and some input from
I got it right.
using one DefaultDS for both jbosses is not such a problem, I believe.
Cheers and thank you. I can't wait to have more instances of nukes on one jboss.
Could you point out what the main problem is? It should be simple when using J2EE to get it working with just the different descriptors and such...
what you can try is :
copy server/default as server/ports-01
copy server/default as server/ports-02
then you enable the binding manager :
edit ports-01/conf/jboss-service.xml and uncomment the binding manager service MBean which is named : jboss.system:service=ServiceBindingManager
the same for ports-02
then you launch the two instances :
the two installations should not conflict.
then the second step is to deploy in each configuration a datasource that links to a different database : this is the file deploy/nukes-ds.xml
with that you should be able to run 2 instances of nukes
on the same computer
thanks for the extended info.
I indead got the two instances on one computer, but two running JVMs takes away a lot of resources, so it would be better to have two nukes on one jboss...
This was what my question about the main problem was actually about: what's the main problem why it is not possible to put two nukes on one jboss server?
Is it a structural problem that would take a lot of refactoring?
i think this could be done by some repackaging the modules into one ear, scoping it, and config file changes. but since i'm still relatively new to the nukes code, i could be completely off base.
one draw back to this approach if it would work is that you'd loose the ability to introduce new components and release updates to individual modules w/o taking down the server. altho, it may be possible to work around this as well, but you're getting into pretty complex packaging.
I've gotten two nukes running on one server after editing the different deployment descriptors, but the problem is as far as I now could see (I'm also very new to nukes and jboss in general) that both instances use the same Entity beans to get their data.
If the primary key of those beans would be dependent on the site the nukes instance drives, it would work better...
Problem than still is that you use one datasource, while it is desirable to have a separate datasource for every nukes instance.... :-S
the option I would consider for the future at mbean level are :
1/ use multidomains domain.nukes.modules, etc...
2/ use a private MBeanServer for Nukes thus it avoid conflicts
for the EJBs CMP, that should be done at datasource level I think.
> the option I would consider for the future at mbean level are :
> 1/ use multidomains domain.nukes.modules, etc...
> 2/ use a private MBeanServer for Nukes thus it avoid conflicts
> for the EJBs CMP, that should be done at datasource level I think.
Is it difficult to assign a private mbean server for every Nukes instance? How would one do that?
The EJB CMP should be assigned in jbosscmp-jdbc.xml of nukes-ejb.jar?
(and of any module with it's own jbosscmp-jdbc.xml?)
it is not possible now, it should be in nukes code instead.
that would need one nukes public manager mbean that would manage private mbean servers and then all the nukes mbeans would be managed here.