I am accessing WildFly (22) via JMX to access one of its MBeans. It is the session information of an web application. This is generally working however I can only see one attribute changing over time which is the activeSessions attribute. All other attributes like expiredSessions, highestSessionCount, maxActiveSessions, rejectedSessions, sessionsCreated etc always remain 0.
Does anybody know the reason for this? Is some special activation for those values necessary?
Ok I found it. In order to gather statistics about HTTP sessions, you need to enable statistics on undertow subsystem. One possibility is to use the CLI as follows:
/subsystem=undertow:write-attribute(name=statistics-enabled,value=true)
or directly in the standalone.xml:
<subsystem xmlns="urn:jboss:domain:undertow:XX.0" default-server="default-server" statistics-enabled="true">
Related
We have setup weblogic 12.2.1.4 clustered environment with 2 nodes in a cluster. We use session ID as part of authentication mechanism to log our user session info to the database. When both managed servers are up, the server generates this session ID:
MrvgJEMe6NG95XNsflnhsWjspl52GXPdl33whbIfGkgaEQm7Rk0X!1974917613!-533469515!1605782630842
When we tried to test session replication, by bringing down the server that currently serves the HTTP request, we have noticed that the session ID has changed and contains NONE as part of the generated ID.
MrvgJEMe6NG95XNsflnhsWjspl52GXPdl33whbIfGkgaEQm7Rk0X!1974917613!NONE!1605782630842
This has caused session replication inconsistency. Has anyone encountered the same issue and how did you resolve it? Your inputs are highly appreciated.
Thank you in advance for the help.
Enable the Debug Flags to Track Session Replication Failures
To gather more logging information about session replication failures, you should enable the flags DebugCluster, DebugClusterAnnouncements, DebugFailOver, DebugReplication, and DebugReplicationDetails.
To Enable:
In WebLogic Server 9.x and higher, the reccommended approach is to use the admin console. For each server in the domain, navigate to Servers -> -> Debug and enable the desired flag(s).
You can use the weblogic.Admin command line utility to dynamically turn the debug options on and off.
For example, to turn on DebugCluster on all administration instances of ServerDebug Mbean (i.e., Admin Server or a Managed Server):
java weblogic.Admin -url t3://localhost:7001 -username system -password weblogic SET -type ServerDebug -property DebugCluster true
Alternatively, you can edit the config.xml and the Mbean element in the stanza for each server that you want to debug and set the value to "true" to enable or "false" to disable. Then you must restart the Admin Server. Managed Servers will reconnect to the Admin Server and the debug flags will then dynamically take effect. Example:
At the end, with all the flags set, in your config.xml the ServerDebug tag would like below:
Make sure the stdOutSeverity level of the server is INFO and StdoutDebugEnabled is set to "true". The debug information will be logged into the server log as well as to the standard out.
Validate the Weblogic.xml entries
Make sure weblogic.xml has all the parameters that need to be set for each Session Replication type. For example, when using in-memory replication the sample weblogic.xml would look like:
I implemented an authentication mechanism similar to CustomHeaderHttpAuthenticationMechanism in https://github.com/wildfly-security-incubator/elytron-examples/tree/master/simple-http-mechanism, using PasswordGuessEvidence and also the other Callbacks mentioned in the example. Reason for the custom mechanism is that beside a simple credential check we need also to validate more constraints to check if a user is validated.
Stepping through this authentication mechanism looks quite good, the authenticationComplete method is called and also the authorizeCallback is successful. However, when accessing an EJB via a resteasy endpoint (EJB is annotated with #SecurityDomain and #RolesAllowed...) the SimpleSecurityManager.authorize method fails because the securityContext.getUtil method neither provides a principal nor something else. If accessing a method annotated by #PermitAll it is successful.
I guess the principal should be created by the ServerAuthenticationContext when working through the different callbacks, right?
How do I manage that the SimpleSecurityManager can recognize the principal, would I need to create it in my authentication mechanism, and how?
In this case it sounds like your EJB deployment has not been mapped to the WildFly Elytron security domain so is still making use of PicketBox security in the EJB tier which is why you are not seeing the identity already established.
Within the EJB subsystem you can also add an application-security-domain mapping to map from the security domain specified in the deployment to the WildFly Elytron security domain.
FYI at some point in the future when we are ready to remove PicketBox from the server these additional mappings will no longer be required, they are just unfortunately needed at the moment whilst we have both solutions in parallel.
I have a server which is serving an index.html and bundle.js file (Server:JBoss-EAP/7, X-Powered-By:Undertow/1). I wish to turn off caching for the bundle.js file for my dev environment so that I can update it without having to clear the cache.
I understand that I do this by adding a filter to my web.xml file but I don't know what tilter-class I should be using. How can I learn more?
I think you don't need to configure filter in this case. There is the buffer cache is used to cache static resources in JBoss EAP undertow subsystem. The default size of a buffer cache is 10MB.
<subsystem xmlns="urn:jboss:domain:undertow:3.1">
<buffer-cache name="default"/>
....
</subsystem>
I think you can use this and change cache buffer size to zero like below or remove buffer-cache even though I didn't verify yet.
/subsystem=undertow/buffer-cache=default/:write-attribute(name=buffer-size,value=0)
:reload
You can refer details in the following docs:
https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.0/html/configuration_guide/configuring_the_web_server_undertow#undertow-configure-buffer-caches
https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.0/html/configuration_guide/reference_material#undertow-attribute-refs
Note that you can also refer this on clearing the browser cache.
How can JBoss requests/responses ONLY be logged using log4j?
For my 3-tiered application (client, web-service and database), I'm trying to gather request/response times.
For instance, timestamps before/after:
Client sends request
WS receives request
WS sends query to database
Currently, my log displays several thousand lines of text (DEBUG mode). But, I'm looking only for request/response information.
I suppose I could choose a different log level, but I'm not able to find my log4j.xml that most solutions are referring to (server/xxx/conf/jboss-log4j.xml). The log4j.properties file in my Eclipse for some reason is not allowing edits.
I'm new to JBoss; in fact inherited the current setup from somebody else, so I'm a little clueless about the entire JBoss thing.
Edit 1
Examples of log4j.properties can be found here.
Edit 2
My log4j.properties:
log4j.rootLogger=TRACE, file
log4j.appender.file=org.apache.log4j.RollingFileAppender
log4j.appender.file.File=C\:log4j.log
log4j.appender.file.MaxFileSize=1MB
log4j.appender.file.MaxBackupIndex=1
log4j.appender.file.layout=org.apache.log4j.PatternLayout
log4j.appender.file.layout.ConversionPattern=%d{ABSOLUTE} %5p %c{1}:%L - %m%n
log4j.category.org.springframework.beans.factory=DEBUG
It's probably best to configure logging through the logging subsystem. If you're looking to use your a log4j configuration file, see the instructions here.
It seems that the MainDeployer MBean doesn't work/is not implemented.
how to retrieve the list of deployed application in JBoss 5?
You might be interessted in the JMX MBean View of Web-Console which can be reached using this URL http://localhost:8080/web-console/ as well as JMX-Console http://localhost:8080/jmx-console/
If you bound your jboss using parameter -b to another interface, you need to replace localhost in the URL given above.