Home » websphere application server
EJB timers are not removed when the application is removed. Some options:
WAS_HOME/bin/cancelEJBTimers command to remove them@Schedule) in 8.0+. In this case, the server automatically creates the timer when the application is first started, and it will attempt to remove them when the application is uninstalled. See the InfoCenter for more information:
ADMU7704E: Failed while trying to start the Windows Service associated with server: server1;
probable error executing WASService.exe: Starting Service: [service name]
Timed out waiting for service to respond to command, after 60 seconds.Failed to start service, or
timed out while waiting for start to complete. Check the logs for details.Alternatively, you can do the following:
“IBM WebSphere Application Server V6.1 – [service_name]”.
WASService.exe -remove [service_name]
You should see a message “Successfully removed service”.
Restart RAD and you should now be able to successfully start your WASv6.1.x server.
To start or stop the WebSphere Application Server node agent:
To start or stop the WebSphere Application Server node agent:
$install_root/profiles/$profile_name/logs/$server_name. The default profile name is AppSrv01 and the default server name is server1. Example:/usr/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1. SystemOut.log is the file containing everything that was logged to standard out. Logs can also be viewed from the admin console by navigating to Troubleshooting/Logging and Tracing/server_name/Runtime.Server/Server Types/WebSphere application servers). Otherwise you have to do it from command line. Go to install_root/bin and run./startServer.sh server_name, e.g., ./startServer.sh server1 (this assumes that your installation has only one profile defined, otherwise you may need to “cd” to the profile_name/bindirectory). Make sure that you run all commands using the appropriate system account. To stop the server, run ./stopServer.sh server_name -username user_name -password password. user_name and password is the credentials of an admin account, typically the same one you use to login to the console.Applications/Application Types/WebSphere enterprise applications, click on “Install new application”, select “Fast path”, accept all the defaults except that on “step 2” make sure that you targeted correct servers (if you have multiple servers/clusters in your environment). Note that you can deploy a WAR file directly, you don’t have to build an EAR. In this case, make sure that you set a context root on “step 4” screen of the wizard.Applications/Application Types/WebSphere enterprise applications/application_name/Context Root For Web Modules in the console. Re-start the application after the change.Applications/Application Types/WebSphere enterprise applications/application_name/Manage Modules/module_name and make the appropriate selection in the “Class loader order” drop-down (this assumes you’re doing it for a WAR module).Server/Server Types/WebSphere application servers. You’ll find the host name in the Host Name column. To find a port, click on your server, and expand Ports. WC_defaulthost is the HTTP port and WC_defaulthost_secure is the HTTPS port.install_root/profiles/profile_name/logs/server_name, and kill the process ID contained in the file server_name.pid. On Unix, you can simply do kill -9 `cat server1.pid` (assumingserver1 is your server name). Use task manager of taskkill /PID on Windows.Buses/Your bus name/Destinations/Your destination/Queue points/Your queue point/Runtime/Messages.$install_root/profiles/$profile_name/config/cells/$cell_name.http://myarch.com/websphere-application-server-for-developers-in-5-minutes-or-less
It’s actually quite easy, but a little tricky. This is how i do it,
1. Start the administrative console.
2. In the topology tree, expand Servers and click Application Servers.
3. Click the name of the application server for which you want to set the time zone.
4. On the application server page, click Process Definition.
5. On the Process Definition page, click Java Virtual Machine.
6. On the Java Virtual Machine page, click Custom Properties.
7. On the Custom Properties page, click New.
8. Specify user.timezone in the Name field and timezone in the Value field, where timezone is the supported value for your time zone.
9. Click Apply.
10. Save the configuration
In this example, i’m setting my timezone as Asia/Jakarta
user.timezone=Asia/Jakarta |
http://edwin.baculsoft.com/2011/08/how-to-set-timezone-on-websphere-application-server/
When defining the usage of an authentication alias in a resource in the administration console of WebSphere Application Server, there are two places the data can be specified:
Component Managed Authentication is used when the resource configured in the EJB’s deployment descriptor res-auth property is set to ‘Application’.
Container Managed Authentication is used when the resource configured in the EJB’s deployment descriptor res-auth property is set to ‘Container’.
All application servers have an Admin Service. The Admin Service does just what the name implies. In most application servers, the admin service does a really good job of system administration for one application server. When you try to run five or ten application servers in parallel, things get flakey. WebSphere Application Server is really a network of servers connected by a network of management. This is what IBM means by “network deployment” or the initials ND. At any moment, some servers will be running, some servers will be stopped, and some servers will be in some in between state. Large, distributed networks are like that. If the network is large enough — we are talking tens of thousands of computers spread across several continents — just knowing what is running on any given part of your network becomes a chore. The admin service for WebSphere Application Server is meant to control everything in an extended network of thousands of servers. It is possible to control a network that large from one laptop computer located anywhere in the world. Everything means
In order to understand how IBM administers the large network of servers that compose WebSphere Application Server, you have to understand some terms
IBM goes to great lengths to separate the actual code that executes from the settings that configure and control how that code behaves. Anything information that influences the way WebSphere Application Server behaves is isolated in something that IBM calls a profile. There is one profile for every node in the network of servers that we call WebSphere Application Server. Every time you create a profile, you have created a node. That node and the servers it contains might stand alone or it might be part of a collection of nodes that IBM calls a cell.
A node contains a collection of application servers and web servers that all happen to live on the same physical computer. One physical computer can contain many nodes as long as it has enough memory and enough CPU to power all the servers in all the nodes it contains. Every server in a node is guaranteed to live on the same physical computer.
An application server in the network of servers and services that we call WebSphere Application Server is Java Enterprise Edition platform code running on a Java Virtual Machine. That code produces dynamic content. This article describes how WebSphere Application Server produces dynamic content. Each application server has its own separate Java Virtual Machine. Sometimes, application servers are just called servers. Notice that any one application server is just a very small part of the product we call WebSphere Application Server. In the competing products, that application server is the entire product. Notice the difference in scale
A web server is a computer program that serves up static content. Sometimes, web servers are just called servers.
A cell is a collection on nodes. All the nodes could be on the same physical computer, but more likely, they will be on a network of physical computers
Configuration determines how all the application servers, web servers, message queues, and various internal services of WebSphere Application Server come to life. The configuration information that system administrators are allowed to modify is stored in a collection of XML files and properties files in the config directory of a profile.
XML files and properties files in the config directory of a profile define how the various servers and services in a node come to life. But those configuration files only get read once. They get read when a server or service is initializing. The moment initialization is complete, the XML files and the properties files are ignored. The only way to get a server to pay attention to changes you make in an XML file or a properties file is to stop the server and then start it again.
A network of JMX beans called MBeans control the way the network servers and services behave once they are running. Those same JMX beans also monitor the behavior of the servers and services while they execute.
Two kinds of specialized application servers enable us to configure, control, and monitor the behavior of the distributed network of servers and services that IBM calls WebSphere Application Server
A deployment manager is an application server that runs exactly one application — an application that manages the configuration and behavior of an entire cell. There is only one deployment manager in any cell. The deployment manager holds the official configuration records for every server and service in the entire distributed network that is part of a cell. When a deployment manager orders a node agent to change the configuration of its servers and services to match this master record, we say the deployment manager has performed a synchronization. Deployment managers only talk to node agents
A node agent controls, configures and monitors all the servers and services in a node. Node agents talk to a deployment manager and node agents talk to the servers in their node. They relay administrative traffic from the deployment manager to the individual servers in their node. They relay status from the servers in their node to the deployment manager.
MBeans do several things
This thing we call WebSphere’s admin service is really a network consisting of the various MBeans, the node agents, and the deployment manager. There are three fairly thin facades to the admin service
If you have never used WebSphere Application Server before, the web browser based admin console is a very good way to learn basic setup and administration. There are limits to what you can do from the admin console. Depending on what you want to do, navigation can either be very easy or very hard. The admin console page that allows you to change JVM heap size is burried deep in the navigation tree of each server. If you want to change heap size for ten servers, you must navigate that tree for each of your ten servers. That can be a lot of tedious mouse clicks.
Once you know what you are doing, wsadmin becomes more attractive than the admin console for many administrative tasks. For one thing, the script language of wsadmin allows you to automate tasks. Once your network reaches a certain size, the admin console becomes a source of errors because of the large number of mouse clicks you must make and the amount of text entry you must provide. Again, the script language provides ways to automate tasks
The most powerful way to control the network of servers and services we call WebSphere Application Server is to write a JMX client. JMX clients have complete unfettered access to the entire admin service and everything that happens across the entire network.
out of my memory 
