Clustering tests
by Kabir Khan
Hi,
I've had a vague thought. I'm not familiar with the clustering tests bit from a glance there seems to be a lot of stopping and starting of servers going on? These tests run very slowly, so if all this stopping/starting is contributing to the slowness, it could be an idea to explore changing the container so that
stop -> executes a reload on the server so that it is reloaded in admin-only mode
start -> executes a reload on the server so that is is reloaded in 'normal' mode
Radoslav, do you see any issues with this?
12 years, 9 months
purpose of jboss.node.name and how to set.
by Wolf-Dieter Fink
I'm a bit confused about the purpose of 'node-name' and how to set it.
I found out that the nodes name is required for UserTransaction and also
a notice:
https://docs.jboss.org/author/display/AS71/Clustered+EJBs
If it's on the same machine, the two things you have to make sure is
that you pass the port offset for the second instance and also make sure
that each of the server instances have a unique jboss.node.name system
property
==== standalone ====
In this mode the only way to set is to use '-Djboss.host.name='.
I try to use
<server name="MyNode" xmlns="urn:jboss:domain:1.1">
OR
<system-properties>
<property name="jboss.node.name" value="MyNode"/>
</system-properties>
but both won't work (I check with EJBClient.getUserTransaction(
node-name ) ) but get the error "No EJBReceiver available for node name
MyNode".
If I set <server name=> getUserTransaction still need the default-host-name.
But if I check inside my bean with
"System.getProperty("jboss.node.name") the name is set and if not
default to my host name.
The mngmt console show the server name and if I set both the console
show the server-name and the property inside of an application the
system-property.
==== domain ====
I try to check whether the <server name=""> work and use also the
system-properties element inside each server.
But both attempts won't work (with EJBClient.getUtx).
The server name from the configuration is shown always by mgnmt console
and not reflect the system-properties setting, but the property inside
the application is set by the system-properties element.
==================
I'm confused because I expect that I can see the node name (as server
name) in the console and use the <server name=> also for getUserTransaction.
My Questions about:
- what is the purpose of node-name (except user identifier for console),
only a identifier for clustering?
- Should the node-name in mngmt console and the property jboss.node.name
get by an application getProperty the same?
- am I right that it a bug that the node-name in standalone.xml or
host.xml won't work for getUserTransaction and I should raise a JIRA?
- is it possible that other functions are affected by this?
- Wolf
12 years, 9 months
As 7.1.0 (EAP 6.0) and Oracle RAC
by Vimal Kansal
Hi Guys,
Ability to FCF with Oracle RAC from middle tier has been a very common
requirement. I would like to pose 2 questions :
* Are we testing AS 7.1.0(EAP 6.0) for Oracle FCF
* Doing Oracle FCF has not been formally documented in EAP 5.x docs
(off course we have bits scattered on wiki here and there), can we
come up with something at least for JBoss AS 7.1.0(EAP 6.0)
Thx
Vimal
12 years, 9 months
h2 database - purpose and production environment
by Wolf-Dieter Fink
AFAIK there is no longer a need to have a default datasource.
- JMS is based on HornetQ and did not use a DB
- EJBtimers are using local filesystem for persistence
So I removed the module without any error.
My question is whether h2db is still not recommended for production
environment and if not the reason. Still bugs or only the
memory-consumption and cluster issues?
- Wolf
12 years, 9 months
Class.getResource returns wrong URL ?
by Bartosz Baranowski
Hi
Ive found something weird in AS7 resource lookup - to be precise, below code executed in AS7 gives output like:
Class c = this.getClass();
URL u1 = c.getResource("../");
URL u2 = c.getResource("../../");
12 years, 9 months
Re: [jboss-as7-dev] Wrong SecurityManagement/AuthenticationManager
by Dieter Tengelmann
Hi,
is there still no fix or workaround for the AuthenticationManager
problem I reported on November?
Best regards,
Dieter
Message: 3
Date: Wed, 07 Dec 2011 13:01:27 -0600
From: Anil Saldhana <Anil.Saldhana(a)redhat.com>
Subject: Re: [jboss-as7-dev] Wrong
SecurityManagement/AuthenticationManager
To: jboss-as7-dev(a)lists.jboss.org
Message-ID: <4EDFB807.8060509(a)redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
This may be due to EJB3 security using the SimpleSecurityManager class
that Carlo coded.
https://github.com/anilsaldhana/jboss-as/blob/master/security/src/main/ja...
There may be a missing link to the JBossCachedAuthenticationManager
inside the security subsystem.
On 11/28/2011 10:05 AM, Anil Saldhana wrote:
> Ok, we will check this out.
> We want the JBossCachedAM in all cases.
>
> On 11/27/2011 01:21 PM, Dieter Tengelmann wrote:
>> Hi,
>>
>> I've configured my security-domain with cache-type="default" in the
>> standalone.xml, an instance of JBossCachedAuthenticationManager is
>> initialized correctly via JNDIBasedSecurityManagement, but my
>> application is permanently authenticating via the JAAS login module. I
>> realized that "JBossAuthenticationManager" is used in all EJB parts,
>> only the JBOSS web realm is using the
>> JBossCachedAuthenticationManager...
>>
>> JBossSecurityContext.getAuthenticationManager() delivers via
>> "DefaultSecurityManagement" an instance of
>> JbossAuthenticationManager
>>
>> Is there a workaround for me to receive/set the correct
>> AuthenticationManager till you fix this bug? Not using the cache
>> causes some serious problems in my application...
>>
>> Best regards,
>> Dieter Tengelmann
12 years, 9 months
Re: [jboss-as7-dev] [infinispan-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
by Paul Ferraro
----- Original Message -----
> From: "Galder Zamarreño" <galder(a)redhat.com>
> To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
> Cc: hibernate-dev(a)lists.jboss.org, "jboss-as7-dev(a)lists.jboss.org Development" <jboss-as7-dev(a)lists.jboss.org>
> Sent: Tuesday, March 6, 2012 2:27:13 PM
> Subject: Re: [infinispan-dev] [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level
> cache
>
> So, to summarise all of this. What I suggest is this:
>
> - Short term:
> The "quick fix" I suggest in
> http://lists.jboss.org/pipermail/infinispan-dev/2012-March/010317.html
>
> - Medium term:
> Have a way to pass in marshalling configurations per cache manager
> and per-cache (or an abstraction of it), which allows the right
> class resolver to be passed in. (***)
> https://issues.jboss.org/browse/ISPN-1367
>
> - Long term:
> https://issues.jboss.org/browse/ISPN-1413
>
> (***) I still don't fully understand how web apps don't have the same
> issue as 2LC of not seeing Infinispan classes (Reminder: we're not
> talking about the contents of the cache, but about the Infinispan
> classes themselves).
To reiterate: in the case of web sessions, the cache instance for an application is associated with the classloader of the org.jboss.as.clustering.web.infinispan module. The AS clustering code shields Infinispan from direct interaction with application objects by storing sessions as MarshalledValues which are eagerly marshalled into byte[] and lazily unmarshalled using an application-specific MarshallingConfiguration.
This has been the case since AS5, if not earlier (albeit using JBoss Serialization + JBoss Cache + TCCL manipulation).
> On Mar 6, 2012, at 8:19 PM, Galder Zamarreño wrote:
>
> >
> > On Mar 6, 2012, at 8:06 PM, David M. Lloyd wrote:
> >
> >> On 03/06/2012 01:02 PM, Galder Zamarreño wrote:
> >>> On Mar 6, 2012, at 6:31 PM, Paul Ferraro wrote:
> >>> </snip>
> >>>> To work around this, we typically store MarshalledValues in the
> >>>> cache - which are marshalled/unmarshalled using a marshalling
> >>>> configuration specific to the application (e.g. via a
> >>>> ModularClassResolver using the ModuleLoader of the deployment
> >>>> unit).
> >>>> https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
> >>>> https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
> >>>> https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
> >>>
> >>> Isn't a class resolver and a class loader, functionality wise,
> >>> doing the same thing? I wonder if a custom classloader could not
> >>> be built that delegates to a ModularClassResolver...
> >>
> >> No, not really. A class loader loads a class, given a name. But
> >> a
> >> class resolver loads a class given a name *and* stream
> >> information. The
> >> modular class resolver reads the stream information to know which
> >> class
> >> loader houses the class in question. This is critically important
> >> because it's possible (common even) for more than one class to
> >> exist in
> >> an AS instance with the same name. And there is no single class
> >> loader
> >> which has visibility to all classes which could potentially be
> >> stored in
> >> a cache.
> >>
> >> Yes, accepting a class loader to use is a powerful feature.
> >> However it
> >> *should* just be a convenience abstraction over a more fundamental
> >> feature which allows a class resolver to be set.
> >
> > Thanks for the clarification, makes sense.
> >
> > So, if I understand this correctly, Infinispan should really be
> > enhanced to accept global and per-cache class resolvers, or more
> > globally, as paul suggested below, marshalling configuration
> > instances (or abstractions of them).
> >
> > I think https://issues.jboss.org/browse/ISPN-1367 should be
> > reporpoused to do this.
> >
> >>
> >>>> So, essentially Infinispan itself only ever has to
> >>>> marshal/unmarshal a byte[] wrapper - so the AS has full control
> >>>> over the marshalling process.
> >>>>
> >>>> I would recommend that the 2LC do something similar, and include
> >>>> a mechanism for providing a MarshallingConfiguration per
> >>>> persistence unit.
> >>>
> >>> Possibly…
> >>>
> >>> --
> >>> Galder Zamarreño
> >>> Sr. Software Engineer
> >>> Infinispan, JBoss Cache
> >>>
> >>
> >>
> >> --
> >> - DML
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> > --
> > Galder Zamarreño
> > Sr. Software Engineer
> > Infinispan, JBoss Cache
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
12 years, 9 months
TS: Bad approach used as fallback mechanism for gathering IP address
by Pavel Janousek
Hi,
I've investigated some issue now and seen there are several places in TS where we can see similar code like this:
static final String someIPproperty = System.getProperty("<some key>", "localhost");
or
static final String someIPproperty = System.getProperty("<some key>", "127.0.0.1");
As you can see above, this fallback mechanism is bound in this case (key value isn't found) to IPv4 only IP address at all. This approach is bad because we can run in other network stack - IPv6 is presented in these days - and in this case the such testcase fails with some strange error due to this issue.
I think we have two option how to resolve this issue:
1) Don't use fallback mechanism at all and fix (= remove) them in present testcases
2) Create auxiliary class which return 127.0.0.1 or ::1 string (but not string "localhost" because we can't be sure how it is translated (*))
(*) common setup in Linux is to translate localhost -> 127.0.0.1 and localhost6 -> ::1
Ad 1) I prefer this option because some forget/miss setting is very easy to catch
Ad 2) This auxiliary class should need to make some magic decision in which IP network stack mode we are now running and return IPv4 or IPv6 lookpack address accordingly.
WDYT about this?
--
Pavel Janousek
Senior JBoss QA Engineer
12 years, 9 months
