I installed an IBM WorkLight Server 6.2 20150129 on a WAS 8.5.5.2 ND on a Windows 2008 DataCenter VM with 4GB ram
min heap:512mb, max heap: 1536mb
I am deploying a *-all.wlapp of around 140mb and following error occurrs.
deploying an app of < 20mb is fine.
server1_exception.log
com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS
server1_(very long meaningless text).txt
[2/11/15 7:10:54:960 PST] FFDC Exception:javax.naming.ConfigurationException SourceId:com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS ProbeId:537 Reporter:java.lang.Class#e712aad3
javax.naming.ConfigurationException: A JNDI operation on a "java:" name cannot be completed because the server runtime is not able to associate the operation's thread with any J2EE application component. This condition can occur when the JNDI client using the "java:" name is not executed on the thread of a server application request. Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application. Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on "java:" names. [Root exception is javax.naming.NameNotFoundException: Name "comp/env/ibm.worklight.admin.lockTimeoutInMillis" not found in context "java:".]
at com.ibm.ws.naming.java.javaURLContextImpl.throwExceptionIfDefaultJavaNS(javaURLContextImpl.java:522)
at com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:552)
at com.ibm.ws.naming.java.javaURLContextImpl.lookupExt(javaURLContextImpl.java:481)
at com.ibm.ws.naming.java.javaURLContextRoot.lookupExt(javaURLContextRoot.java:485)
at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:370)
at org.apache.aries.jndi.DelegateContext.lookup(DelegateContext.java:161)
at javax.naming.InitialContext.lookup(InitialContext.java:436)
at com.ibm.worklight.admin.common.util.ContextPropertyUtil.getContextProperty(ContextPropertyUtil.java:184)
at com.ibm.worklight.admin.common.util.ContextPropertyUtil.getContextProperty(ContextPropertyUtil.java:164)
at com.ibm.worklight.admin.common.util.ContextPropertyUtil.getContextProperty(ContextPropertyUtil.java:65)
at com.ibm.worklight.admin.common.util.ContextPropertyUtil.getContextPropertyAsLong(ContextPropertyUtil.java:300)
at com.ibm.worklight.admin.actions.BaseCommitable.getLockTimeOutInMillis(BaseCommitable.java:415)
at com.ibm.worklight.admin.actions.CleanUnfinishedTransaction.cleanUnfinishedTransaction(CleanUnfinishedTransaction.java:94)
at com.ibm.worklight.admin.actions.BaseTransaction.internalRun(BaseTransaction.java:284)
at com.ibm.worklight.admin.actions.BaseTransaction$1.run(BaseTransaction.java:210)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:906)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:929)
at java.lang.Thread.run(Thread.java:796)
Caused by: javax.naming.NameNotFoundException: Name "comp/env/ibm.worklight.admin.lockTimeoutInMillis" not found in context "java:".
at com.ibm.ws.naming.ipbase.NameSpace.lookupInternal(NameSpace.java:1228)
at com.ibm.ws.naming.ipbase.NameSpace.lookup(NameSpace.java:1141)
at com.ibm.ws.naming.urlbase.UrlContextImpl.lookupExt(UrlContextImpl.java:1436)
at com.ibm.ws.naming.java.javaURLContextImpl.lookupExt(javaURLContextImpl.java:477)
... 15 more
In Microsoft IIS there is an attribute that controls this filesize limit. This attribute is called maxAllowedContentLength and it can be found in the <requestLimits> element of the IIS configuration file. Its default value is 30 000 000 bytes.
You should increase it to a filesize tha will contain the wlapp's filesize.
Uninstalled WAS 8.5.5.2 patch in IBM installation Manager to roll back to WAS 8.5.5.0 and restarted everything, then i can deploy adapters.
Related
Product name: Open Liberty
Product version: 20.0.0.7
Product edition: Open
is it possible to implement persistent ejbtimers on filesystem based default derby DB, using embedded.derby.DB
I installed derby in /tmp/derby, configured server.xml with the following, i don't see any file being created under /tmp when I start the OpenLiberty JVM, what am I missing in this approach?
<feature>ejbPersistentTimer-3.2</feature>
<library id="DerbyLib">
<fileset dir="/tmp/derby/lib" includes="derby.jar"/>
</library>
<dataSource id="DefaultDerbyDatasource" jndiName="jdbc/defaultDatasource" statementCacheSize="10" transactional="false">
<jdbcDriver libraryRef="DerbyLib"/>
<properties.derby.embedded createDatabase="create" databaseName="/tmp/sample.ejbtimer.db" shutdownDatabase="false"/>
<containerAuthData user="user1" password="derbyuser" />
</dataSource>
Check this book - http://www.redbooks.ibm.com/abstracts/sg248076.html?Open
In chapter "5.2.4 Developing applications using timers" you should find all stuff needed.
UPDATE based on comment:
If you look to the book and to the log it shows:
[INFO ] CNTR4000I: The ITSOTimerApp.war EJB module in the ITSOTimerApp
application is starting.
[INFO ] CNTR0167I: The server is binding the com.ibm.itso.timers.TimerBean
interface of the TimerBean enterprise bean in the ITSOTimerApp.war module of
the ITSOTimerApp application. The binding location is:
java:global/ITSOTimerApp/TimerBean!com.ibm.itso.timers.TimerBean
[INFO ] DSRA8203I: Database product name : Apache Derby
[INFO ] DSRA8204I: Database product version : 10.8.2.3 - (1212722)
[INFO ] DSRA8205I: JDBC driver name : Apache Derby Embedded JDBC Driver
[INFO ] DSRA8206I: JDBC driver version : 10.8.2.3 - (1212722)
[INFO ] CNTR0219I: The server created 1 persistent automatic timer or timers
and 0 non-persistent automatic timer or timers for the ITSOTimerApp.war module.
TimerBean initialized
It creates db 'as needed' so if you dont have any persistent timers beans, the service will not be started nor db created.
Liberty in general follows lazy model and doesn't start unneeded services.
So create sample application and then your DB will be created. There is no need to create database nor connection to database when no one is requesting for it.
In general, it is not advisable to use Derby Embedded database for persistent EJB timers due to limitations of Derby Embedded that all connections use the same class loader (implying the same JVM as well). This means you cannot leverage the failover capability (missedTaskThreshold setting) or even have multiple servers connected to the database at all. If you decide to use a Derby Embedded database, it means that you are limiting yourself to a single server. You can decide for yourself if that is acceptable based on what your needs are.
In the case of the example configuration you gave, it doesn't work because the EJB persistent timers feature in Liberty has no way of knowing that you dataSource, "DefaultDerbyDatasource" with jndiName "jdbc/defaultDatasource" is the data source that it ought to use. Also, it is incorrect to specify transactional="false" on the data source that you want EJB persistent timers to use because EJB persistent timers are transactional in nature.
I assume that what you are intending to do is configure the Java EE default data source and expecting EJB persistent timers to use it. That approach will work, except that you'll need to configure the Java EE default data source, you need to specify the id as "DefaultDataSource".
Here is an example that switches your configured data source to the Java EE default data source and removes the transactional="false" config,
<library id="DerbyLib">
<fileset dir="/tmp/derby/lib" includes="derby.jar"/>
</library>
<dataSource id="DefaultDataSource" jndiName="jdbc/defaultDatasource" statementCacheSize="10">
<jdbcDriver libraryRef="DerbyLib"/>
<properties.derby.embedded createDatabase="create" databaseName="/tmp/sample.ejbtimer.db" shutdownDatabase="false"/>
<containerAuthData user="user1" password="derbyuser" />
</dataSource>
By default, the EJB persistent timers feature should create database tables once the application runs and the EJB module is used.
However, you may be able to verify the configuration prior to that point by running the ddlgen utility (after correcting the configuration as above)
https://www.ibm.com/docs/en/was-liberty/base?topic=line-running-ddlgen-utility
which gives you the opportunity to see the DDL that it will use and optionally to run it manually (which is useful if you turned off automatic table creation via
<databaseStore id="defaultDatabaseStore" createTables="false"/> )
I'm using Apache Ignite entity framework Nuget as a second level cache in an ApsNetCore 2.0 web application under IIS(as reverse proxy).
On my development machine (VS2017 Windows 8.1) everything works well. Wen i deploy to WindowsServer 2012 the Ignite crash at startup with :
An error occurred while starting the application.
IgniteException: Failed to load jvm.dll (Please specify IgniteConfiguration.JvmDllPath or JAVA_HOME.)
Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.Load(string configJvmDllPath, ILogger log)
TargetInvocationException: Exception has been thrown by the target of an invocation.
System.RuntimeTypeHandle.CreateInstance(RuntimeType type, bool publicOnly, bool noCheck, ref bool canBeCached, ref RuntimeMethodHandleInternal ctor, ref bool bNeedSecurityCheck)
IgniteException: Failed to load jvm.dll (Please specify IgniteConfiguration.JvmDllPath or JAVA_HOME.)
Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.Load(string configJvmDllPath, ILogger log)
Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
Apache.Ignite.EntityFramework.IgniteDbConfiguration.GetOrStartIgnite(IgniteConfiguration cfg)
Apache.Ignite.EntityFramework.IgniteDbConfiguration..ctor()
I checked and re-chewed, installed the JDK , correct system variables....everything. The error don't goes away. What is interesting is the application run ok as console. When it runs under IIS(reverse proxy) it crashes at startup with the above error.
Any suggestions ?
Thank you
I managed to start the website. How ? Only with JDK 11 and explicit path to jvm.dll on app.config file:
If is not explicit in config then crashes.
The JAVA_HOME from system variable is correct set. Also the Path variable is
%JAVA_HOME%;%JAVA_HOME%\bin;%JAVA_HOME%\bin\server;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0;C:\Program Files\Microsoft\Web Platform Installer;C:\Program Files\dotnet;C:\Program Files (x86)\dotnet;C:\ProgramData\chocolatey\bin;C:\Program Files\Memurai;C:\Program Files\Java\jdk-15.0.1\bin\
Maybe is a conflict with C:\Program Files\Java\jdk-15.0.1\bin\ ? It carsh with jvm 15. But it works with jvm 11
Looks like the IIS worker process is running in 32-bit mode, so Ignite looks for a 32-bit JDK, which is not present.
And the console app runs in 64-bit mode, using 64-bit JDK, so it works.
Please check the app pool settings in IIS Manager -> Application Pools -> select the app pool you want and -> Advanced Settings.
Additionally, you can enable detailed logging to a file (since you can't see console logs in IIS) - Ignite logs all attempts to resolve the JDK path. For example, with Apache.Ignite.NLog package:
var nlogConfig = new LoggingConfiguration();
var fileTarget = new FileTarget
{
FileName = "/home/pavel/w/ignite_nlog.log"
};
nlogConfig.AddTarget("logfile", fileTarget);
nlogConfig.LoggingRules.Add(new LoggingRule("*", LogLevel.Trace, fileTarget));
LogManager.Configuration = nlogConfig;
var igniteConfig = new IgniteConfiguration
{
Logger = new IgniteNLogLogger()
};
Ignition.Start(igniteConfig);
I've checked the suggested points by Pavel Tupitsyn:
App pool aplication is 64bits (emable 32bits=false)
I've installed apache.Ignite.NLog
I'tested it on my machine and it logs well all java resolves.
I've deployed to windows server 2012 and under IIS i'm getting 'Process Failure'.
The log file looks like:
2020-12-07 19:39:38.3304|DEBUG||Starting Ignite.NET 2.9.0.50002
2020-12-07 19:39:38.3834|WARN||GC server mode is not enabled, this could lead to less than optimal performance on multi-core machines (to enable see http://msdn.microsoft.com/en-us/library/ms229357(v=vs.110).aspx).
2020-12-07 19:39:46.2534|DEBUG||Starting Ignite.NET 2.9.0.50002
so...just a warning (present on my machine too).
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info:
Apache.Ignite.Core.Common.IgniteException
at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.Load(System.String, Apache.Ignite.Core.Log.ILogger)
at Apache.Ignite.Core.Ignition.Start(Apache.Ignite.Core.IgniteConfiguration)
at Nop.Web.Program.Main(System.String[])
well...adding apache.ingite.nlog throws PROCESS FAILURE
Hosting is virtual machine with Windows Server 2012 64bits
Any other ideas please....
I configured cluster between two different JBoss server using Multicast method.
Both server will be connected , when I start both JBoss server.
After one days , I'm getting following messages
Errors start to show for the clustering in server.log
05:28:17,447 ERROR [org.hornetq.core.server] (Thread-11905 (HornetQ-client-global-threads-377807954)) HQ224037:
cluster connection Failed to handle message: java.lang.IllegalStateException:
Cannot find binding for d7c1004f-b1a1-4160-8888-c38175ac45d599cf0dfe-5f30-11e4-bd7e-556a35fb9ec6 on
ClusterConnectionImpl#538608327[nodeUUID=930dee51-5f30-11e4-9695-ef52e2a27831, connector=TransportConfiguration(name=netty,
factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?port=5445&host=172-29-250-191, address=jms,
server=HornetQServerImpl::serverUUID=930dee51-5f30-11e4-9695-ef52e2a27831]
at org.hornetq.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.doConsumerCreat
05:28:17,411 ERROR [org.hornetq.core.server] (Thread-11439
(HornetQ-remoting-threads-HornetQServerImpl::serverUUID=99cf0dfe-5f30-11e4-bd7e-556a35fb9ec6-136247994-702467456))
HQ224016: Caught exception: HornetQException[errorType=QUEUE_EXISTS message=HQ119019:
Queue already exists 7a8b46d5-a038-4efd-900e-4c041c2c121f]
At org.hornetq.core.server.impl.HornetQServerImpl.createQueue(HornetQServerImpl.java:1811)
[hornetq-server-2.3.1.Final-redhat-1.jar:2.3.1.Final-redhat-1]
How to ensure cluster between two servers. Is there any procedures or any work around available?
Red Hat provides a McastReceiverTest java client test utility- further information on its use can be located at https://access.redhat.com/solutions/123073
I need to monitor WAS liberty profiles i made some configuration changes in sever.xml
<feature>restConnector-1.0</feature>^M
<feature>jsp-2.2</feature>^M
<feature>appSecurity-1.0</feature>^M
<feature>ssl-1.0</feature>
<feature>monitor-1.0</feature>^M
but when i am connecting with rest port i am only getting following mbeans regarding websphere
WebSphere
WebSphere:feature=restConnector,type=FileService,name=FileService
WebSphere:service=com.ibm.websphere.application.ApplicationMBean,name=WLProject
WebSphere:feature=channelfw,type=endpoint,name=defaultHttpEndpoint-ssl
WebSphere:feature=restConnector,type=FileTransfer,name=FileTransfer
WebSphere:service=com.ibm.websphere.application.ApplicationMBean,name=kohls
WebSphere:service=com.ibm.ws.kernel.filemonitor.FileNotificationMBean
WebSphere:service=com.ibm.websphere.application.ApplicationMBean,name=worklightadmin
WebSphere:feature=channelfw,type=endpoint,name=defaultHttpEndpoint
WebSphere:service=com.ibm.websphere.application.ApplicationMBean,name=worklightconsole
WebSphere:name=com.ibm.ws.jmx.mbeans.generatePluginConfig
WebSphere:service=com.ibm.websphere.application.ApplicationMBean,name=_analytics
WebSphere:name=com.ibm.ws.config.serverSchemaGenerator
WebSphere:service=com.ibm.websphere.application.ApplicationMBean,name=_MobileBrowserSimulator
WebSphere:service=com.ibm.websphere.application.ApplicationMBean,name=nsecom
not able to get threadpool, webcontaineer mbeans , is there any configuration i have to do??
Maybe update to the latest Liberty version and try to test with jconsole. I'm running v8.5.5.3 and it works fine. I'm using the following command to start jconsole using rest connector (all in one line, formatted for readability):
jconsole
-J-Djava.class.path=C:\
IBM\WebSphere\LibertyIM\java\java_1.7_32\lib\jconsole.jar;C:\IBM\WebSphere\Liber
tyIM\java\java_1.7_32\lib\tools.jar;C:\IBM\WebSphere\wlp\clients\restConnector.j
ar
-J-Djavax.net.ssl.trustStore=C:/IBM/WebSphere/wlp/usr/servers/monitoringServe
r/resources/security/key.jks
-J-Djavax.net.ssl.trustStorePassword=password
-J-Djavax.net.ssl.trustStoreType=jks
-J-Duser.language=en
I can see ThreadPoolStats and ServletStats. For SessionStats or ConnectionPoolStats your application actually needs to use the feature (e.g. session or connection to db) to be visible in jconsole and have mbean.
I am currently trying to replace Hypersonic with MS-SQL 2008 R2 in JBoss AS 5.1.0GA.
I have followed the instructions in the JBoss Server Configuration Guide, however the server fails to load with this error:
2013-09-26 17:06:04,479 WARN [org.jboss.resource.adapter.jms.inflow.JmsActivation] (WorkManager(2)-3) Failure in jms activation org.jboss.resource.adapter.jms.inflow.JmsActivationSpec#8bb1eb(ra=org.jboss.resource.adapter.jms.JmsResourceAdapter#c54851 destination=queue/iam/im/jms/queue/wpUtilQueue destinationType=javax.jms.Queue tx=true durable=false reconnect=10 provider=DefaultJMSProvider user=null maxMessages=1 minSession=1 maxSession=15 keepAlive=30000 useDLQ=true DLQHandler=org.jboss.resource.adapter.jms.inflow.dlq.GenericDLQHandler DLQJndiName=queue/DLQ DLQUser=null DLQMaxResent=10)
javax.naming.NameNotFoundException: DLQ not bound
(I left out the stack trace for brevity; it isn't important.)
I have checked, and DLQ is defined in destinations-service.xml
I'm not sure where to proceed from here; every response I can find on Google seems to suggest that defining the queue in destinations-service.xml has solved the issue for almost everyone.
Any help would be appreciated.
It turns out that the instructions in the Configuration Guide aren't 100% complete. The issue was that a ChannelFactory was referenced in the mssql-persistence-service.xml; however, this environment is not clustered, and so there were no ChannelFactory objects defined.
Removing the reference to the ChannelFactory was sufficient to resolve the issue.