I have a JAVA application deployed on Websphere. This application is looking for a local WSDL file to do a SOAP request. However whenever the Websphere reboots which is nightly scheduled, this below line throws a NullPointer as it couldn't find the path of the WSDL. When we cycle the JVM everything works fine until the next reboot.
Url baseUrl = MyJavaClass.class.getClassLoader().getResource("MyInterface.wsdl");
I will need this baseUrl later to continue with my SOAP request.
service = new ServiceInstance(baseUrl, new QName("http://myinterface.blah","ServiceInstance"));
Of course with the baseUrl being Null this throws error. But once the JVM cycles everything works fine until it breaks again randomly. I have the WSDL inside my src/main/resources folder which I set it as a Source folder.
Below is how my classLoading options are set in Websphere to make this work. I have tried every other possibility which fails.
Any ideas?
I can't tell for sure, but... if this doesn't happen on JVM recycle, but does happen on reboot, it serves as a hint that some files went missing on reboot.
On most non-Windows platforms, temporary directories are mounted on memory-backed storage, which is why the contents of directories such as /tmp are discarded on reboot.
WebSphere keeps a cache of compiled WSDL artifacts. It keeps them in a directory called wstemp inside the profile directory. It is possible (though I'm not sure) that wstemp holds pointers to files in /tmp. In that case, a reboot is certain to cause your issue.
(Or, maybe, your system administrator made a configuration change whereby the wstemp directory itself points to memory-backed storage?)
What you can try is this: next time when the machine reboots, delete the wstemp directory completely, before restarting WebSphere. Then try your application. If it works, then it means that there's some truth in what I wrote above. If it doesn't, then maybe it's time to open a PMR with IBM.
Related
This is an old application and we have trouble to have the application changed.
During the deploy of a CRM like application, migrated from a 6.1.35 environment to a 8.5.5.17 websphere application server environment, the startup time of the application changed from 10 seconds to 12 minutes.
We made sono troubleshooting and we found that the problem is a remote filesystem which has 1.200.000 files. This remote filesystem is "mounted" in a path that is part of the WAR cell. This is done after the deploy of the application.
What make the application startup so slow is that on 8.5.5.17, all the files present in the path of the application are traversed (thus it tries to traverse the 1.200.000 file in the remote filesystem, which takes, as you may guess, 12 minutes...).
Anybody knows if this changed behaviour from WAS 6.1.x to WAS 8.5.5.x is intended?
Is there any workaround to block this?
WebSphere Application Server creates a list of files in the application when starting the application. It's a bit overzealous when creating the list in that it includes files that it does not need to look at during application start. For large applications, the file list can consume a lot of memory and can take a long time to generate. Since it is a Java EE application server, it should only be concerned with files in Java-EE-defined locations when starting the application. The list is not used during application run time. Therefore, the application server should only look in the directories:
/
META-INF/*
WEB-INF
WEB-INF/classes/*
WEB-INF/lib/*
APAR PH09294, included in 8.5.5.16 and 9.5.0.1, provides a way for you to limit the file list to the above locations. You can specify a setting either in the application or in the application server. (If you are using a version prior to 8.5.5.16 or 9.5.0.1, you should look at PM37942, which is a bit more cumbersome but still works.)
To enable the setting in the application, add the following to the MANIFEST.MF of either the EAR or the WAR. (Remember when editing MANIFEST.MF, obey the formatting rules. MANIFEST.MF must end with a blank line.) Adding the setting to a WAR limits the file list for just that WAR. Adding the setting to an EAR limits the file list for all WARs in that EAR.
IBM-Enable-File-List-Include-Filter: true
You can apply the setting to the server by setting a JVM custom property.
The following JVM custom property applies the setting to all applications on the server:
Property: org.eclipse.jst.j2ee.commonarchivecore.EnableFilesListIncludeFilter
Value: true
You can also apply the setting to all servers in a profile by adding the following line to the <WAS_PROFILE_HOME>/properties/amm.filter.properties file:
IBM-Enable-File-List-Include-Filter = true
Finally, to apply the setting to all profiles, add the above line to the <WAS_HOME>/properties/amm.filter.properties
Where should you set it? If you set it in the application, then wherever you deploy the application, the file list will be limited in scope. You do not depend on any setting in the application server. So for any large application, a developer should always include the setting in the application. An administrator might consider applying the setting to the entire WebSphere Application Server installation.
I'm writing a Spring application where users may upload files which will later be served again.
However the directory in which the files will be stored is always a temporary location (per default), such as /tmp/tomcat-docbase.XYZ. So whenever the application is restarted, another path will be chosen and all the files uploaded before are lost.
I can't figure out how to set the server's root manually.
I tried setting the server.tomcat.basedir in my application.properties but this didn't do it (guess it is just the wrong property)..
So what did I miss? Thanks in advance :)
I am new to symfony and am responsible for a site that I didn't build. For some reason the site is on a live server but running in dev mode. - Im not sure why??
That aside - The website keeps writing _sess files to my /tmp directory. The contents of each _sess file is exactly the same. See below:
_symfony2|a:3:{s:10:"attributes";a:0:{}s:7:"flashes";a:0:{}s:6:"locale";s:2:"en";}
Do I really need all of these files? Can anyone suggest a way of disabling this feature?
Thanks in advance
The default session storage of Symfony2 writes the session information to file(s). The location these files are written to is determined by the config parameter framework.session.save_path. The default value for this is %kernel.cache.dir%/sessions. This means that in a default installation of symfony the session files would be written to the cache directory for the environment.
However, this can be a problem as the cache directory has to be cleared each time an app is deployed, thus logging all the users out. Therefore presumably your app has been configured (most likely in config.yml) to store the session files in /tmp.
As I understand it, sessions that have expired should be garbage-collected at some point. Symfony also has some config params that affect this - see the FrameworkBundle Configuration. I don't know how much traffic your website has but obviously you do need the session files for active sessions. If you think you have a lot of expired sessions you could try tweaking the gc config params.
Alternatively, if having the session files in /tmp is specifically the problem you could relocate them (by changing the value of the framework.session.save_path) or use PDOSessionHandler to store sessions in the database.
I have this problem with symfony 1.4.20 on a web site I inherited.
It is writing files to
/var/lib/php/sessions
every second, until the server runs out of iNodes.
I've tried changing settings in settings.yml. app.yml and PHP session variables.
Nothing sees to be working though, the only way I can stop it is to change the ownership of /var/lib/php/sessions to root and that prevents any session files being created.
Normally, after we create profiles both DMGR and Node, we have folder applications under path $DMGRPROFILE_HOME/config/cells/$cellName and installedApps under path $NODEPROFILE_HOME/.
All the applications to be deployed will be put into folder installedApps. And we can also see the same contents under the folder applications above. So my question is what's the difference between them? why does the websphere application server put such apps into folder applications besides installedApps?
what's more, for example, if i need to update one file named web.xml of my deployed application war file, do i have to update file under both path above?
Thanks in advance
The applications path under the Dmgr profile contains the files that have been deployed in the admin console.
The installedApps path under the Node profile contains those files after they've been synchronized out to each node. In most cases, this will be immediately after the deployment as well.
Deploying a single file
The safest practice would be to deploy a single file using the admin console, rather than editing it in-place on the filesystem:
The downside is that you have to enter the entire path to the server-deployed file name. e.g. webapp.war/WEB-INF/classes/com/yourcompany/project/package1/YourClass.class.
If you have a typo, it will deploy, but not where you wanted, and you might not notice it until your expected changes didn't take effect.
Direct edit on the filesystem
That said, it is faster to edit on the filesystem, so we do that at times especially for like JSPs. To do that, you need to edit the copy under the Node's installedApps directory. (The location is controlled by WebSphere variable APP_INSTALL_ROOT, which defaults to ${USER_INSTALL_ROOT}/installedApps.)
web.xml
web.xml, however, is different. If you edit that in installedApps, the changes won't take effect. Instead, you'll need to edit the one in a path something like:
$NODEPROFILE_HOME/config/cells/cellName/applications/earName.ear/deployments/applicationName/warName.war/WEB-INF
Or do it in the $DMGRPROFILE_HOME and then synchronize the node (either through syncNode.sh or through the admin console).
Either way, you'll then need to restart the enterprise application.
When I run my Eclipse RCP application, it creates a whole lot of directories in my $HOME/.eclipse directory. What is this?
I don't want the files there, how can I hinder them from getting there? The rational for this: the application must run very clean and only leave files at one specific location (not $HOME/.eclipse).
I'd figured it was controlled by osgi.instance.area so tried to set this to different values (a directory, #none, #noDfault etc...) but can't stop the application from creating directories in $HOME/.eclipse. -data and other arguments works as expected.
On my system the only thing that is stored in .eclipse is the Equinox Secure Storage. Here is the blurb on the doc page for that:
By default, secure storage is located in your home directory. On Windows that typically resolves to "C:\Documents and Settings\.eclipse\org.eclipse.equinox.security". This location is selected to allow multiple Eclipse-based applications to share the same secure storage.
If you would like to modify the location of the default secure storage, you can use the "-eclipse.keyring " runtime option. The is a path to the file which is used to persist the secure storage data.
Here is the online reference.