weblogic挖矿事件

Ⅰ weblogic应用的web.xml经常被覆盖，如何查到原因

应用的web.xml是不会被webllogic修改的，修改为固定的版本可以建议你看一下不是不有脚本在做更新，可以看一下什么时间修改的。

Ⅱ Jolt调用Tuxedo服务，该怎么处理

对于BEA的中间价产品TUXEDO，常采用C/C++语言编写后台服务程序，广泛应用于电信、金融等领域，因项目的需要，我们经常面临调TUXEDO服务的需求！

对于JAVA调TUXEDO服务，有三种方法：一是通过JNI，二是通过WTC，三是通过JOLT！这三种方式各有优劣，简单的描述为：

JNI

优--无需购买License；发布TUXEDO服务无需做额外限制；无需借助于任何J2EE容器

劣--JNI影响系统移植；防止过度JNI带来性能问题

WTC（WEBLOGIC为TUXEDO定制）

优--因定制，存在一套和TUXEDO API相对应的JAVA API；发布TUXEDO服务无需做额外限制；双向调用

劣--需要购买License；依赖于WEBLOGIC容器，不能移植到其它J2EE容器（如WEBSPHERE，JBOSS）

JOLT

优--可用于但不依赖于J2EE容器（如WEBLOGICWEBSPHERE，JBOSS）；提供的API用WTC类似但不同；

劣--需要购买License；发布TUXEDO服务有些额外的要求；不提供集成的 WebLogic Server-Tuxedo 事务的机制

由此可知，第一，在受限于License经济压力或无法要求UXEDO服务方发布服务的情况下，我们可以选择JNI方式调TUXEDO服务；

第二，当需要一般 Java 客户端或其他 Web 服务器应用程序且 WebLogic Server 不是解决方案的一部分时，用户应使用 Jolt（而不使用 WTC）作为解决方案。

对于jolt方式调TUXEDO服务，3个必须的JAR包：jolt.jar、joltjse.jar、joltwls.jar，下面信息也许对您有帮助：

[转贴]不涉及wls的jolt客户端实现

1、如果不使用wls，同样可以使用jolt提供的pool功能，而这又分为两种：一种是基于web容器的servlet jolt
pool，另一种则是普通java客户端的jolt
pool。前者在$TUXDIR/udataobj/jolt/examples/servlet/simpapp下有示例，后者则未提供。
2、如果不使用jolt产品自带的pool，也可以自己实现。套路为：创建Jolt Session >
基于此session构建JoltRemoteService对象并发起tuxedo调用 > 释放jolt
session。这里有个要点就是在使用session前需要用session.isAlive()来判断当前session是否可用，因为JSL的-T
参数及防火墙对idle连接的干扰都可能导致已有的session是无效的。
3、创建JoltRemoteSession时一定记得为三个超时属性（IDLETIMEOUT/RECVTIMEOUT/SENDTIMEOUT）进行
显式的设置。idle超时和tuxedo的JSL
-T属性对应，该设置将保证session.isAlive()返回正确的布尔值。RECV超时则控制client端自发起call至收到tuxedo
return这一过程的预期时常。
5、tuxedo侧在ubb里为相应的service配置了SVCTIMEOUT，所以service执行超时后会收到SIGKILL而被终止，这样一
来，客户端的call会收到TPESVCERR错，对应的异常为bea.jolt.ServiceException。客户端需要对此异常进行处理，此
外，客户端捕获此异常的时间点应当和ulog中该server被kill的时间点对应。
6、在客户端，时不时会发现由于达到RECVTIMEOUT而导致的客户端接收超时。客户的疑问是：当前RECVTIMEOUT设置为25s，而ubb中
相应SVCTIMEOUT设置为10s且scanunit为默认的10s，所以理论上不应发生25s的客户端RECVTIMEOUT超时。庹达人提出了一
种怀疑，即client端请求抵达tuxedo侧时，server出现排队情况，请求未被及时处理，这个排队时长决定了20s以外的时间差。对于此，建议
客户使用MSSQ，并监控pq的情况。

使用XMLink和Jolt实现IBM WebSphere与BEA Tuxedo的互连 第一部分

使用XMLink和Jolt实现IBM WebSphere与BEA Tuxedo的互连 第二部分

下面，我们重点关注下WTC，WebLogic Tuxedo Connector (WTC) 提供了 WebLogic Server 应用程序与
Tuxedo 服务之间的互操作性。WTC 允许 WebLogic Server 客户端调用 Tuxedo 服务，Tuxedo 客户端调用
WebLogic Server Enterprise Java Bean (EJB) 来响应服务请求，两者之间的简单关联关系如下图：

关于WTC的配置原则和最佳实践可参考下面的链接：

配置准则
最佳实践
为方便记，摘录过来：

配置准则

在配置 WebLogic Tuxedo Connector 时请使用以下准则：

最佳实践

以下部分提供了使用 WTC 时的最佳实践：

请参阅“WebLogic Tuxedo Connector 编程人员指南”中的应用程序错误管理。
请参阅“WebLogic Tuxedo Connector 管理指南”中的系统级调试设置。
将 Security 的值设置为 DM_PW。请参阅“WebLogic
Tuxedo Connector 管理指南”中的远程访问点的身份验证。
启用链接级加密并将 min-encrypt-bits 参数设置为
40，将 max-encrypt-bits 设置为 128。请参阅“WebLogic Tuxedo Connector 管理指南”中的链接级加密。
在 WebLogic Server 群集的所有节点上配置 WTC 实例。
每个群集节点中的每个 WTC 实例都必须具有相同的配置。
请参阅“WebLogic Tuxedo Connector 管理指南”中的如何管理群集环境中的
WebLogic Tuxedo Connector。

在配置连接策略时，请使用 ON_STARTUP 和 INCOMING_ONLY。
ON_STARTUP 和 INCOMING_ONLY 总是成对出现。例如，如果使用 ON_STARTUP 配置了
WTC 远程访问点，则必须将远程访问点的 Tuxedo 域配置的 DM_TDOMAIN 部分配置为 INCOMING_ONLY。在此情况下，WTC
总是充当会话发起方。请参阅“WebLogic Tuxedo Connector 管理指南”中的配置访问点之间的连接。

避免使用连接策略 ON_DEMAND。首选连接策略是 ON_STARTUP 和 INCOMING_ONLY。这样会减少因路由ON_DEMAND 的语义而引起的服务请求失败。请参阅“WebLogic
Tuxedo Connector 管理指南”中的配置访问点之间的连接。
在设计应用程序时，请考虑使用以下 WTC 功能：链接级故障转移、服务级故障转移和负载平衡。请参阅“WebLogic Tuxedo Connector 管理指南”中的配置故障转移和故障回复。
请考虑使用 WebLogic Server 群集提供额外的负载平衡和故障转移。要在 WebLogic Server 群集中使用 WTC，请执行下列操作：

如果 WTC 到 Tuxedo 的连接使用了 Internet，则要使用以下安全设置：

应用程序逻辑应该提供机制来管理和解释应用程序中的错误条件。

避免在 TypedFML32 缓冲区内使用嵌入的 TypedFML32 缓冲区。请参阅“WebLogic
Tuxedo Connector 编程人员指南”中的将 FML 用于 WebLogic Tuxedo
Connector。
如果应用程序处理重负载，请考虑配置更多的远程 Tuxedo 访问点并让 WTC 平衡访问点之间的工作负载。请参阅“WebLogic Tuxedo Connector 管理指南”中的配置故障转移和故障回复。
在使用事务应用程序时，尽量让同一事务中涉及的远程服务能够从同一远程访问点访问。请参阅“WebLogic Tuxedo Connector 编程人员指南”中的 WebLogic
Tuxedo Connector JATMI 事务。
从网关调度服务时，可用的客户端线程数可能会限制运行的并发服务数。没有任何 WebLogic Tuxedo Connector 特性可以增加可用线程的数量。在调用服务时请使用合理的线程模型。请参阅“配置
WebLogic Server 环境”中的线程管理和使用工作管理器优化调度的工作。
WebLogic Server 9.2 及更高版本提供了改进的路由算法，这增强了事务性能。具体说就是，当 2 阶段提交 (2PC) 事务中具有不止一项 Tuxedo 服务请求时，性能就会相应提高。如果应用程序仅向
Tuxedo 域执行单个服务请求，则可以通过设置以下 WebLogic Server 命令行参数来禁用此功能：
通过在缓冲区中使用最大数量的对象来调用构造方法 TypedFML32。即使是很难预测最大数量，提供合理的数量也可以提高性能。可以通过将字段的数量乘以
1.33 得到近似的最大数量。

注意：
注意，此性能提示不应用于 TypedFML 缓冲区类型。

例如：

如果在 TypedFML32 缓冲区类型中有 50 个字段，那么最大数量就是
63。调用构造方法 TypedFML32(63, 50) 比 TypedFML32() 执行得更好。

如果在 TypedFML32 缓冲区类型中有 50 个字段，并且每个字段最多可以有
10 个事件，则调用构造方法 TypedFML32(625, 50) 将会有比 TypedFML32() 更好的性能。

当配置 Tuxedo 应用程序（这些应用程序可以作为与 WTC 客户端互操作的服务器）时，请考虑平行问题，这一点可以通过在不同 Tuxedo 计算机上仔细配置不同服务器来实现。
要知道在 Tuxedo 应用程序中可能会存在数据库访问死锁现象。可以通过认真配置 Tuxedo 应用程序来避免死锁现象。
如果正在使用 WTC 负载平衡或服务级故障转移，BEA 建议不要禁用 WTC 事务关系。
针对负载平衡出站请求，为导入服务配置使用不同密钥的多个条目。导入服务将使用复合密钥来确定每个记录的唯一性。复合密钥的构成：服务名称 + 本地访问点 + 远程访问点列表中的主要路由。
下面是一个如何为 service1 在 TDomainSession(WDOM1,TUXDOM1) 和TDomainSession(WDOM1,TUXDOM2) 之间正确配置负载平衡请求的示例：

ResourceName

LocalAccessPoint

RemoteAccessPointList

RemoteName

service1

WDOM1

TUXDOM1

TOLOWER

service1

WDOM1

TUXDOM2

TOLOWER2

下面是一个错误配置负载平衡请求的示例。下面的配置会导致 service1 具有相同的复合密钥：

ResourceName

LocalAccessPoint

RemoteAccessPointList

RemoteName

service1

WDOM1

TUXDOM1

TOLOWER

service1

WDOM1

TUXDOM1

TOLOWER

在建立连接/会话前更改该会话/连接配置（本地 AP、远程 AP、密码和资源）：
接受更改并在新的会话/连接中实现这些更改。

在建立连接/会话后更改该会话/连接配置（本地 AP、远程 AP、密码和资源）：
接受更改，但是要到连接断开并重新连接后，才在现有的连接/会话中实现这些更改。请参阅“管理控制台联机帮助”中的定位
WTC 服务。

更改导入和导出服务配置：
接受更改并在下一个入站或出站请求中实现这些更改。BEA 建议不要使用此做法，因为这会让正在进行的请求处于未知状态。

更改 tBridge 配置：
对已部署的 WTC 服务进行任何更改都会导致异常。在进行任何 tBridge 配置更改前都必须先取消对 WTC 服务的定位。在取消定位和进行配置更改后，必须定位 WTC 服务以便实现更改。

在配置中可以有多种 WTC 服务。
只能将一种 WTC 服务定位到服务器实例。
WTC 不支持连接缓冲池。WTC 通过单个物理连接多路传输请求。
配置更改可按照如下方式实现：

Ⅲ weblogic 如何进行连接回收

一、gc回收 web应用 → 连接池回收
weblogic jconnector Garbage Collector Method:(wls api)
WebLogic Server automatically detects connection leaks by leveraging its Java Virtual Machine
(JVM) garbage collector mechanism. When an application component terminates and the
connections it uses become dereferenced, the garbage collector calls the connection object’s
finalize() method.
When the garbage collector calls the finalize() method, if WebLogic Server determines the
application component has not closed the connection, the server automatically closes the
connection by calling the resource adapter’s ManagedConnection.cleanup() method;
WebLogic Server behaves as it would had it received a CONNECTION_CLOSED event upon proper
closure of the application component connection.
通过JVM垃圾回收机制，wls服务器能自发探测连接泄露，当应用终止而其所使用的连接变为孤儿时，
垃圾回收器就调用连接对象的finalize方法
垃圾回收器调用finalize方法时，如果wls服务器确定是应用没有关闭连接，
wls服务器将调用资源适配器的ManagedConnection的cleanup方法自动关闭连接，
weblogic服务器表现得就像它本来应该接收 应用组件连接的其中某个连接上的一个CONNECTION_CLOSED事件

二、程序显式回收 web应用→连接池
Connection.close()方法调用后，weblogic监控到该动作，由连接池回收并管理连接

三、weblogic的无效链接回收
inactive connection timeout 经过设定时间，回收无效链接

四、weblogic的连接池自动收缩
Allow Shrinking: 允许自动收缩。如果连接池的初始容量和最大容量不相等，那么当池中的连接大于初始容量时，经过Shrink Frequency时间，如果连接池中的活动连接不高于初始容量个，那么连接池中连接的数量会减少到初始容量大。

Ⅳ 我搜索了一些资料，为什么说Tomcat是一个容器，而weblogic是一个应用服务器呢他们不都是一个级别的么

应该对你有帮助的!Tomcat是jsp、servlet的容器 WebLogicServer9.x为SOA实现提供了一个完善的企业级基础 l支持面向服务架构的开发和部署 l通过可靠消息传递基础架构为业务提供事件平台 l通过简化、可靠的管理功能降低客户的拥有总成本 l为核心应用提供真正的“零宕机”服务 性能：WLS业界性能评测最好的J2EE服务器 规范支持： lWLS全面支持J2EE的标准规范和其他标准规范（WebService,SSL,xml等），同时BEA为众多规范组织的制定者之一，积极参与规范的制定 lTomcat只支持部分J2EE标准，应用局限性强,不能够安全稳定的支持大并发 技术服务支持： lBEA：完善的售后支持 lTomcat：没有售后支持 客户群体： lBEA：全球13000＋企业级用户的证明 lTomcat：很少企业级用户 可扩展性 lWLS：集群机制，支持分布式的应用；Tomcat：不支持 可靠性 lWLS：支持Failover；Tomcat：不支持 管理 lWLS：Web控制台进行组件、JDBC、管理和配置；Tomcat：不支持 部署 lWLS：开发模式下，不用重起部署新Web,EJB应用；Tomcat：不支持 开发工具： lWLS：有自己的开发工具Workshop，并且主流IDE支持；Tomcat：没有自己的开发工具 扩展性 lWLS：可以轻松扩展为支持Portal、Integration的WebLogicPlatform上；Tomcat不支持

求采纳

Ⅳ sitescope如何监控

Mercyry SiteScope是一款无代理监测解决方案，可确保分布式IT基础架构——如服务器、操作系统、网络设备、网络服务、应用和应用组件的可用性和性能。这款主动的、基于Web界面的基础架构监测解决方案是非常简洁的，而且完全根据客户度身定制，无需在您的上线系统中增加额外的代理。
SiteScope为上线系统提供24×7的监控服务，为维护工程师及时发现问题提供帮助，确保系统架构内一切组建的正常运作。SiteScope在大量增加检测周期的同时也降低了维护人员的工作成本 。
SiteScope能够监控UNIX服务器资源、windows服务器资源、weblogic应用服务器、IIS应用服务器、Oracle数据库、SQLServer数据库、F5、URL地址、Ping、内存、CPU、磁盘空间、服务等等系统架构内各种组建的运行状况；监控器按照指定频率对目标进行检测，一旦发现异常会及时向管理员发送意外事件的报警，警报可以通过声音提醒、email、短信等方式发送；另外，SiteScope还可以生成监测活动的汇总报告，该对象从日志文件中读取历史信息，接着总结、筛选信息，并生成图表格式的报告。 SiteScope常用监控器配置说明： 一、输入license
在SiteScope树下Preferences—General Preferences，输入许可证号、选项许可证。 二、启动监控历史记录视图
在SiteScope树下Preferences—General Preferences，“控制面板监控历史记录视图选项”中选择。 三、Unix资源监控
1． 首先在Preferences—Unix Remote Preferences 增加要监控的unix服务器
2． 然后新建unix资源监控器
四、weblogic应用程序服务器
1．输入服务器IP、weblogic应用服务的端口号、登录weblogic console的用户名/密码。
2.从weblogic服务器的weblogic安装目录（如：c:\bea\weblogic81\server\lib）拷贝weblogic.jar到SiteScope服务器，建立一个单独的目录（如：c:\weblogic）存放weblogic.jar.
3.在“WebLogic Jar”文件输入框输入weblogic.jar文件所在目录的全路径（如：c:\weblogic\weblogic.jar）。
注意：不要把weblogic.jar存放在SiteScope服务器的\SiteScope\java\lib\ext目录，如果存放在\SiteScope\java\lib\ext目录会导致SiteScope运行失败。
五、监控Oracle数据库
1． 拷贝 Oracle JDBC database driver 文件 (classes12.zip) 到SiteScope服务器， <SiteScope install path>\SiteScope\java\lib\ext 目录下. 不解压缩文件.拷贝完毕之后停止并重新启动SiteScope服务.
( classes12.zip 文件可以在oracle安装目录下得到<oracle install path> \oracle\ora92\jdbc\lib \classes12.zip)
2． 新建类型为“数据库查询”或”oracle数据库”的监控器，输入如下图信息。
数据库连接Url: jdbc:oracle:[email protected]:1521:etsora9
数据库驱动程序： oracle.jdbc.driver.OracleDriver （大小写敏感） 六、使用Oracle Database 9i and 10g 模板

变量“OracleAlertLogPath”路径，例如： \\200.200.200.166\d$\oracle\admin\etsora9\bmp

变量“OracleListenerLogPath”路径，例如：\\200.200.200.166\d$\oracle\ora92\network\log

七、监控Sql server
1．Windows Remote Preferences 选项中增加sql server服务器
2．被监控的sql服务器必须启动The Remote Registry 服务

Ⅵ Linux里weblogic服务里 /tmp/watch-smartd -B 占用99%CPU，求大神什么解决

我们遇到同样的问题，貌似是被攻击了。
与
watch-smartd
进程同在的还有一个 Carbon

Ⅶ weblogic 12C版本 大并发时死机

能把你的配置发上来看看吗？
怀疑你是单核的CPU

WIN2003.。。我也是2003+weblogic+SLQ 2005 没有你说的那种问题。。。你说的大并发 是指多少。。。 连接数多少