Is there a way to get Invocation Statistics using twiddle command line tool
I tried
twiddle.sh get "jboss.j2ee:jndiName=jaas/foo/bar/MyBean,service=EJB" InvokeStats
but I get java.io.NotSerializableException: org.jboss.invocation.InvocationStatistics.
Is jboss web-console the only way to collect statistics?
After googling a bit I found an answer. Actually, the correct command is
twiddle.bat --user="user" --password="pwd" get "jboss.management.local:name=jaas/foo/bar/MyBean,J2EEServer=Local,EJBModule=my_ejb.jar,J2EEApplication=my_ear.ear,j2eeType=StatelessSessionBean" stats
It's necessary to add jboss-management.jar to the classpath as well, twiddle forgot to do this.
Related
When I run command "shimmercat devlove" it gives following error:-
Please find devlove.yaml file:- https://www.dropbox.com/s/6xhk3lq497zw8y2/devlove.yaml?dl=0
Good question #Atul Rai. I'm not completely sure, but I think it could be related with what is written here. It says:
...ShimmerCat probes the port to determine if the application is using HTTP/1.1 or FastCGI. The probing operation shows in ShimmerCat's logs, and may also show in the error log of the application.
Of course if you are not using an API domain (you don't have a subkey port on your devlove.yaml config file) I don't think that ShimmerCat has to do these probes, but I can't see another explanation for these error logs. Perhaps it would be useful if you update your question with your devlove.yaml file?
I have read the documentation concerning falling back to environment variables at https://github.com/typesafehub/config/blob/master/HOCON.md#substitution-fallback-to-environment-variables. My understanding was that it would pickup any envars. So for instance, if from the shell I was able to do echo $HOSTNAME and see a non-empty response then HOCON should do that as well.
In my application.conf I have a line
akka.remote.netty.tcp.hostname = ${HOSTNAME}
However, my app is not happy with this and fails to start with.
/conf/application.conf: 9: Could not resolve substitution to a value: ${HOSTNAME}
Is this a user issue? A shell issue? I am able to login as the user and echo $HOSTNAME
Tagging this scala and akka since that userbase probably has the most exposure to HOCON
The reason for HOCON not picking up the envar is that my app runs as a linux service (Centos 6.5) which clears away most environment variables.
See https://unix.stackexchange.com/questions/44370/how-to-make-unix-service-see-environment-variables for a relevant description of the issue
this is a shot in the dark, but are you using an older version of typesafe-config? maybe its a newer-ish feature? the feature seems to be advertised as you describe, but if you are pulling in typesafe-config as a transient dependency (say from akka), maybe you are getting an older version.
what happens if you remove the substitution in your .conf file (so parsing is successful) and then print out the contents of ConfigFactory.systemEnvironment()? for reference: http://typesafehub.github.io/config/latest/api/com/typesafe/config/ConfigFactory.html#systemEnvironment--
HOSTNAME isn't an environment variable. It's a bash internal variable. See https://superuser.com/questions/132489/hostname-environment-variable-on-linux for more details.
I am using Jboss 7.1 Final. I have setup remote ejb using jboss-ejb-client.properties and standalone.xml accordingly. But after the server running for sometime it will throw this exception while trying to lookup the remote ejb. Is there anything I need to set in the jboss-ejb-client.properties in order for it to work. Note that I already defined the HEARTBEAT_INTERVAL, is that not enough?
Here is the properties file:
endpoint.name=client-endpoint
remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
remote.connections=default
remote.connection.default.host=222.222.23.222
remote.connection.default.port=4447
remote.connection.default.username=us
remote.connection.default.password=ps
remote.connection.default.connect.options.org.jboss.remoting3.RemotingOptions.HEARTBEAT_INTERVAL=60000
Since no takers to this question, I found some possible solutions by googling. It might be that I have been opening too many connections by calling new InitialContext() -- I might be calling it every few minutes!!! See this link:
https://developer.jboss.org/thread/222883
In there someone mentioned GC and the connection closing etc. That might be helpful.
How do you lookup to your EJB from your EJB Client ? Incase you are using java:/ namespace the problem will happen.
Please use ejb:/ namespace to eliminate the problem.
I've found documentation for the different configuration options, but how can I check which options are being used on a live system?
Is there a way to see which options were set, or at minimum which configuration file is being used?
Found the answer: https://stackoverflow.com/a/9361047/947305
There's a getCmdLineOpts command in the mongo shell. Run the following:
db._adminCommand( {getCmdLineOpts: 1})
to get live settings, you can use
db.adminCommand({getParameter:"*"})
previously called _adminCommand with underscore in front, so if you
have old mongo running, try that one.
https://docs.mongodb.com/manual/reference/command/getParameter/
To know the current configuration file, you can try:
cat(db._adminCommand({getCmdLineOpts: 1}).parsed.config);
The method returns with output relative to the current shell session
and does not impact the server.
I've set up multiple vhosts under apache2 / mod_perl. I used the ErrorLog directive to get a separate error log for each vhost. This only worked as expected when I used Apache2::Log. 'warn' would only log to the regular error log.
So that's all working. Finally. But there's one issue remaining: When I log via $r->log_error, I find that newlines are replaced with \n
Any idea why this happens, and how it can be fixed?
Thanks.
This is not a mod_perl problem, but an Apache one. Apparently there are some security concerns with printing unescaped output to the error logs (I'm not entirely sure why) so you have to explicitly enable this in Apache when building/configuring it using this:
CFLAGS=-DAP_UNSAFE_ERROR_LOG_UNESCAPED ./configure
If you're using an already installed apache, there's not much you can do to change this.
If you have a pre-built install, you can use this line of code to fix the issue but it must be included in every page execution within your vhost, say in a header.php or config.php file.
ini_set('error_log','/var/log/apache2/error.log');
i know this is very old thread, but still coming on top on google results, so just to help all, the following changes in mod_perl.pl did helped me:
comment out below:
BEGIN { *CORE::GLOBAL::warn = \&Apache2::ServerRec::warn; }
the above is for:
Make warnings go to the virtual host's log and not the main server log.
i hope this helps anyone out there like me :)