When I run wildfly 8.2.0.Final on Windows 8.1 I get the following warnings in the log when starting the standalone-full profile:
WARN [jacorb.codeset] (MSC service thread 1-8) Warning - unknown codeset (Cp1252) - defaulting to ISO-8859-1
WARN [org.jboss.as.messaging] (MSC service thread 1-2) JBAS011600: AIO wasn't located on this platform, it will fall back to using pure Java NIO. If your platform is Linux, install LibAIO to enable the AIO journal
Everything seems to work fine, but I was wondering if someone can explain what these warnings are about and how to configure wildfly so these warnings are cleared.
For the first warning you can take a look in this issue: Windows: Unknown codeset (Cp1252), defaulting to ISO-8859-1.
A possible work around is add to JAVA_OPTS
-Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8
or
-Dfile.encoding=ISO-8859-1 -Dsun.jnu.encoding=ISO-8859-1
depending your file encoding.
For the second, you can add in the messaging subsystem <journal-type>NIO</journal-type>
<subsystem xmlns="urn:jboss:domain:messaging:2.0">
<hornetq-server>
<journal-file-size>102400</journal-file-size>
<journal-type>NIO</journal-type>
<!-- ... -->
</hornetq-server>
</subsystem>
journal-type
Valid values are NIO or ASYNCIO.
Choosing NIO chooses the Java NIO journal. Choosing AIO chooses the
Linux asynchronous IO journal. If you choose AIO but are not running
Linux or you do not have libaio installed then HornetQ will detect
this and automatically fall back to using NIO.
Ref: Configuring the message journal
You can ignore those warnings.
Regarding the first warning:
[Cp1252] character encoding is a superset of ISO 8859-1, but differs
from the IANA's ISO-8859-1 by using displayable characters rather than
control characters in the 80 to 9F (hex) range [...] It is known to Windows by the code page number 1252 (source:
http://en.wikipedia.org/wiki/Windows-1252)
Regarding the second warning:
It's not possible to use the AIO journal under other operating systems
or earlier versions of the Linux kernel.
(source: http://hornetq.sourceforge.net/docs/hornetq-2.1.2.Final/user-manual/en/html/persistence.html#installing-aio)
Related
I'm trying to use CRC for testing Openshift 4 on my laptop (Ubuntu 20). CRC version 1.17 doesn't support Virtualbox virtualizazion so following the setup instructions
https://access.redhat.com/documentation/en-us/red_hat_codeready_containers/1.17/html/getting_started_guide/installation_gsg
i'm using libvirt, but when i start the cluster with crc start it launch following error
INFO Checking if oc binary is cached
INFO Checking if podman remote binary is cached
INFO Checking if goodhosts binary is cached
INFO Checking minimum RAM requirements
INFO Checking if running as non-root
INFO Checking if Virtualization is enabled
INFO Checking if KVM is enabled
INFO Checking if libvirt is installed
INFO Checking if user is part of libvirt group
INFO Checking if libvirt daemon is running
INFO Checking if a supported libvirt version is installed
INFO Checking if crc-driver-libvirt is installed
INFO Checking if libvirt 'crc' network is available
INFO Checking if libvirt 'crc' network is active
INFO Checking if NetworkManager is installed
INFO Checking if NetworkManager service is running
INFO Checking if /etc/NetworkManager/conf.d/crc-nm-dnsmasq.conf exists
INFO Checking if /etc/NetworkManager/dnsmasq.d/crc.conf exists
INFO Starting CodeReady Containers VM for OpenShift 4.5.14...
ERRO Error starting stopped VM: virError(Code=55, Domain=18, Message='Requested operation is not valid: format of backing image '/home/claudiomerli/.crc/cache/crc_libvirt_4.5.14/crc.qcow2' of image '/home/claudiomerli/.crc/machines/crc/crc.qcow2' was not specified in the image metadata (See https://libvirt.org/kbase/backing_chains.html for troubleshooting)')
Error starting stopped VM: virError(Code=55, Domain=18, Message='Requested operation is not valid: format of backing image '/home/claudiomerli/.crc/cache/crc_libvirt_4.5.14/crc.qcow2' of image '/home/claudiomerli/.crc/machines/crc/crc.qcow2' was not specified in the image metadata (See https://libvirt.org/kbase/backing_chains.html for troubleshooting)')
I have not experiences with libvirt so i'm stuck on that and online i'm not finding anything...
Thanks
There is an issue with the crc_libvirt_4.5.14 image. The easiest way to fix it is to do a
qemu-img rebase -f qcow2 -F qcow2 -b /home/${USER}/.crc/cache/crc_libvirt_4.5.14/crc.qcow2 /home/${USER}/.crc/machines/crc/crc.qcow2
Now, if you try to do a crc start, you going to face a "Permission denied" error, which is related to Apparmor, unless you whitelisted your home directory. If you don't want to hack around with Apparmor settings, the /var/lib/libvirt/images supposed to be whitelisted. Move the image to there:
sudo mv /home/${USER}/.crc/machines/crc/crc.qcow2 /var/lib/libvirt/images
then edit the virtual machine settings pointing to the new image location: virsh edit crc , then replace the <source file='/home/yourusername/.crc/machines/crc/crc.qcow2'/> to <source file='/var/lib/libvirt/images/crc.qcow2'/>.
Then do the crc start and... that's it.
The relevant Github issues to follow:
https://github.com/code-ready/crc/issues/1596
https://github.com/code-ready/crc/issues/1578
We configured the latest version (7.2) SMSC-GW to work on on our server with the environment (cassandra and such). However, after setting up everything. Some failures are appearing (which did not appear in previous versions).
Firstly, when connecting the simulators and the gateway using the default settings (JSS7 <-> SMSCGW <-> SMPP)
JSS7 is connected and sending, but no response is received.
SMPP is connected to SMSC-GW and the EMSE is bound. SMPP tries to send to SS7 but receives a response PDU packet failure from the SMSC-GW
I tried configuring DB routing rules, but that did not work.
Also, the log in the SMSC-GW server is frequently displaying the following message:
16:00:28,504 INFO [SchedulerResourceAdaptor] (pool-56-thread-1) Not all SBB are running now: ServicesDownList=[smscTxSmppServerServiceState, smscRxSmppServerServiceState, smscTxSipServerServiceState, smscRxSipServerServiceState, smscTxHttpServerServiceState, moServiceState, homeRoutingServiceState, mtServiceState, alertServiceState, chargingServiceState, ]
And the JSS7 management console GUI is displaying this (which looks wrong):
So are these the source of the SMSC-GW failures?
UPDATE: I found this error in the server.log
2017-02-02 10:57:42,005 WARN [org.mobicents.slee.container.deployment.jboss.SleeContainerDeployerImpl] (SLEE-InternalDeployer-thread-1) SLEE DUs not deployed, due to missing dependencies: file:/home/coreteam/kitchensink/restcomm-smsc-7.2.109/jboss-5.1.0.GA/server/simulator/deploy/smsc-services-du-7.2.109.jar/
Followed by:
EventTypeID[name=org.mobicents.smsc.slee.services.smpp.server.events.SS7_SEND_MT,vendor=org.mobicents,version=1.0]
ResourceAdaptorTypeID[name=PersistenceResourceAdaptorType,vendor=org.mobicents,version=1.0]
ResourceAdaptorTypeID[name=SchedulerResourceAdaptorType,vendor=org.mobicents,version=1.0]
SipRA
EventTypeID[name=org.mobicents.smsc.slee.services.smpp.server.events.SS7_SEND_RSDS,vendor=org.mobicents,version=1.0]
SchedulerResourceAdaptor^M
PersistenceResourceAdaptor^M
EventTypeID[name=org.mobicents.smsc.slee.services.smpp.server.events.SMPP_SM,vendor=org.mobicents,version=1.0]
EventTypeID[name=org.mobicents.smsc.slee.services.smpp.server.events.SS7_SM,vendor=org.mobicents,version=1.0]
EventTypeID[name=org.mobicents.smsc.slee.services.smpp.server.events.SIP_SM,vendor=org.mobicents,version=1.0]
2017-02-02 14:41:17,450 WARN [org.mobicents.slee.container.deployment.jboss.DeploymentManager] (main) Unable to INSTALL smsc-services-du-7.3.0-SNAPSHOT.jar right now. Waiting for dependencies to be resolved.
Solved it quite a while ago, but thought I would share. I just simply installed the SipRA missing dependency by adding the following in the deploy-config.xml file:
<ra-entity
resource-adaptor-id="ResourceAdaptorID[name=JainSipResourceAdaptor,vendor=net.java.slee.sip,version=1.2]"
entity-name="SipRA">
<properties>
<property name="javax.sip.PORT" type="java.lang.Integer" value="5060" />
</properties>
<ra-link name="SipRA" />
In the $JBOSS_HOME/server/profile_name/deploy/restcomm-slee directory.
I set the port to some other value since that number was already taken by some other service.
The smsc-services-du-7.2.109.jar then installed automatically the next time I ran the SMSC-GW.
I have a war that has being working just fine under EAP 6.4.x (x currently 8, but also under 6 and 4 and so on down to 6.4.0).
The WAR has some simple JMS client features to adding a message to a queue on a remote machine. The target QBroker is ActiveMQ 5.8.0.
I use the 5.8.0 RAR to set up an adapter/connector to the remote broker and then just normal JMS client stuff to push a message into a q. All is fine with this.
Beginning the "port" from 6.4.x to 7.0.1; and I am hung up on the amq 5.8.0 RAR stuff. For starters -- not going to use any of the AMQ Artemis stuff that is part of EAP 7 (yet). Initially I want to get my WAR working under 7.0 with as few changes as possible -- so leaving RAR in place is important.
Under 6.4.x, I use the standalone profile and just deploy the RAR via CLI kinda like this:
./jboss-cli.sh --connect -c "deploy --name=${AMQ_DEPLOY_NAME} --runtime-name=${AMQ_RAR_FNAME} ${_TMPDIR}/${AMQ_RAR_FNAME}"
I then use cli to set up resource adapter, connection def/factory and admin-object for the queue.
Following the same process with EAP 7.0.1, if I use the standalone profile I get
java.lang.NoClassDefFoundError: javax/jms/JMSException
issues while trying to enable the WAR that uses the RAR. Ok so when I used standalone-full I get all sorts of variations of this sort of error:
2016-07-18 15:48:10,867 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "messaging-activemq"),
("server" => "default")
]) - failure description: {
"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.messaging-activemq.default is missing [jboss.http-upgrade-registry.default]"],
"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
"Services that were unable to start:" => ["jboss.messaging-activemq.default.jms.manager"],
"Services that may be the cause:" => [
"jboss.http-upgrade-registry.default",
"jboss.naming.context.java.JmsXA"
]
}
}
The above messages suggest something is wrong with the messaging-activemq stuff (or the built in artemis stuff).
In both cases, I do set my EJB default resource adapter to the RAR created above.
So what am I missing on this set up?
Some particulars about my Environment:
War doesn't have any jboss/wildfly specific DDs in it.
I do not have the AMQ RAR deployed as a static module (nor do I want to) -- it is just a jar I have deployed - like other JAR (for DB drivers) or WARS, EJB jars, etc.
cat version.txt
Red Hat JBoss Enterprise Application Platform - Version 7.0.1.GA
java -version
java version "1.8.0_92"
Java(TM) SE Runtime Environment (build 1.8.0_92-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.92-b14, mixed mode)
uname -a
Linux wellandf3 4.6.4-301.fc24.x86_64 #1 SMP Tue Jul 12 11:50:00 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Is this NoClassDefFoundError caused by a ClassNotFoundException? If thats the case I would try to add javax.jms.api as global module.
I have installed libaio on ubuntu, and running HornetQ embedded, with programmatic config, I am doing this to use AIO on journal, but I see on startup, it's not getting AIO, always using NIO. Any way to determine why it would be failing?
Configuration configuration = new ConfigurationImpl();
boolean supportsAIO = AIOSequentialFileFactory.isSupported();
if (supportsAIO) {
configuration.setJournalType(JournalType.ASYNCIO);
log.info("** using AIO **");
} else {
configuration.setJournalType(JournalType.NIO);
log.info("** using NIO **");
}
You have to define -Djava.library.path=PathToYourBinaries
and you should have these files at PathToYourBinaries:
libHornetQAIO32.so
libHornetQAIO64.so
if you still can't load it then it will be a matter of recompiling the natives at your system, but most likely you just need to define java.library.path.
I am having web application running in JBOSS AS 4.2.2.
Observed that jboss server automatically shuts down, and the following exception is observed in server.log
14:20:38,048 INFO [Server] Runtime shutdown hook called, forceHalt: true
14:20:38,049 INFO [Server] JBoss SHUTDOWN: Undeploying all packages
I want to enable TRACE for org.jboss.system.server.Server in jboss-log4j.xml, to hopefully get some more info when the server shuts down.
Please let me know how to enable TRACE for org.jboss.system.server.Server in jboss-log4j.xml.
I was able to add trace for server log and i could see the following output when JBOSS AS shuts down automatically:
2010-06-09 19:07:46,631 DEBUG [org.jboss.wsf.stack.jbws.RequestHandlerImpl] END handleRequest: jboss.ws:context=hpnp_lqs,endpoint=APIWebService
2010-06-09 19:07:46,631 DEBUG [org.jboss.ws.core.soap.MessageContextAssociation] popMessageContext: org.jboss.ws.core.jaxws.handler.SOAPMessageContextJAXWS#3290a11e (Thread http-0.0.0.0-8080-1)
2010-06-09 19:07:55,895 INFO [org.jboss.system.server.Server] Runtime shutdown hook called, forceHalt: true
2010-06-09 19:07:55,895 TRACE [org.jboss.system.server.Server] Shutdown caller:
java.lang.Throwable: Here
at org.jboss.system.server.ServerImpl$ShutdownHook.shutdown(ServerImpl.java:1017)
at org.jboss.system.server.ServerImpl$ShutdownHook.run(ServerImpl.java:996)
2010-06-09 19:07:55,895 INFO [org.jboss.system.server.Server] JBoss SHUTDOWN: Undeploying all packages
If anybody, has any clue, on what might be cause for automatic shutdown, pls help me.
Thanks!
There's a JBoss wiki page listing log output for various shutdown causes. It looks like yours was caused by a Ctrl-C. I assume you would have known if you hit Ctrl-C, though.
On unix-type servers, Ctrl-C generates a TERM signal, which could also come from someone or some script running as your jboss user or as root executing "kill <jboss pid>". If you're on linux I'd take a look at this question about the OOM killer.
One possible cause for this behaviour is console logout. We have observed this with our own server.
In brief, by default the Sun JVM listens to the event of the console user logging out, and shuts itself down automatically when that happens. To disable this, start the JVM with the -Xrs parameter.
See here for more details (look for Mysterious shutdowns).
One possible cause for a forced shutdown is if the virtual machine is out of memory.
I had this problem several years ago when a colleague implemented some very nasty bulk loading of objects from a database which caused jboss to shutdown on certain requests.
Try searching for "memory" or similar keywords in the log file and/or monitor the memory usage of the server.