普元启动服务失败的解决方法.doc

普元启动服务失败的解决方法 当多个人同时使用一个数据库的时候，启动普元控制台会一直停留在rcall，然后显示一个超时的警告，那样就需要修改一下普元的一个定时器配置项。安装目录下PrimetonPlatformapps_configdefaultconfig 中的一个user-config.xml文件 将下列代码中高亮字段中的true改为false即可 true default 当EOS启动调试服务时，控制台停留在 RCALL后无反应一般是因为定时任务的表被锁住的原因，可在plsqldeveloper中执行以下语句：select alter system kill session |b.SESSION_ID|,|c.SERIAL#| immediate;from v$locked_object b,v$session cwhere b.SESSION_ID = c.SID将查询结果复制到新的SQL窗口执行，执行完成后再启动服务- 解决EOS连接失败无法启动的问题 - 查看有没有被锁的对象select * from v$locked_object - 查看被锁的对象是哪张表select * from dba_objects where object_id in(select t.OBJECT_ID from v$locked_object t)-select * from dba_objects where object_id=73713 - 从菜单栏进入Tools/Sessions，将Status=ACTIVE and Sid=被锁对象id的记录，点击右键菜单中的Kill跟操作系统的兼容性有关，建议去下看ideeclipseplugins目录下org.eclipse.swt.win32.win32.x86_3.2.0.和org.eclipse.swt_3.2.0两个jar的版本，更换成高版本试试。提供清理eos开发过程中缓存清理的方法摘要：提供清理eos开发过程中缓存清理的方法。在eos开发过程中，经常遇到新开发的代码无法使用，右键部署之后依然使用原来的老旧代码，非常影响开发速度。这里提供下清理缓存的方式，确定我们的最新代码能够被使用。对于分组开发过程中，各人代码版本差异无法实现同样的运行效果有特效。1.删除%EOS_HOME%apps_configdefaultwork_temp下的所有文件和文件夹。如需使用平台的各种日志请酌情备份logs下的内容。2.删除%EOS_HOME%apache-tomcat-7.0.54work下的所有内容，情况tomcat的缓存。3.删除%EOS_HOME%apache-tomcat-7.0.54webappsdefaultWEB-INF_srvworkuser下我们自己项目的内容。慎重，别删错了，我们自己开发的。ESB修改默认端口61616windows操作系统下的默认的ICS服务（Internet Connection Sharing）默认占用了61616端口，因此要解决jms端口冲突的情况有两种方式。方式一： 停止ICS服务。 命令行执行 “services.msc”,找到ICS服务，右键停止，并设置为以后手动启动。方式二：修改ESB下JMS默认端口。 找到D:PrimetonESBstudioserverEOS_srvconfig下的esb-mq-config.xml和fts-server-config.xml文件，分别修改如下内容： （esb-mq-config.xml)(fts-server-config.xml) tcp:/:61616 5 1 如何修改Platform发布Webservice服务的命名空间摘要：如何修改Platform发布Webservice服务的命名空间（）为自己指定的名字。问题描述:Platform发布Webservice服务，在浏览器上查看wsdl，客户想修改其中的命名空间，如下图红色框的内容，想更换成自己的命名空间。适用环境:PlatformV6及以上版本处理经验:可以修改user-config.xml中的配置，将DefultNameSpace这行的注释放开，修改为自己指定的值。!-/-应用被拦截，调用报错无法访问摘要：应用被拦截，调用报错无法访问场景描述：test.html放在Tomcat的webapps/ROOT目录下，或者其他非default应用下该静态HTML页面中有一个超链接EOS test在资源管理器中直接双击该文件，在浏览器打开后（file:/协议），点击该超链接可以正常访问。但如果我通过:8080/test.html访问该页面（http:/协议），点击该超链接时，直接报错了，错误信息为：调用异常，请查看日志！而使用window.open没有问题。EOS test，function open_win()window.open(:8080/default/skins/default/index.jsp)情况分析：获取前后http头，referer为不同应用之间的请求，那么可能被default给拦截了。解决办法：去除拦截器：把apps_configdefaultconfig eoshandler-web.xml中的以下配置注释掉，看看是否还会不会有问题： 摘要：EOS工程部署到JBOSS后报错。分析日后初步确定为 jboss-6.1.0.Finalcommonlibslf4j-api.jar与jboss-6.1.0.Finalserverdefaultdeploydefault.eardefault.warWEB-INFlibslf4j-api-1.5.6.jar 冲突导致该问题已经解决。方案如下：修改 jbossserverdefaultdeployersjbossweb.deployerMETA-INFwar-deployers-jboss-beans.xml 添加org.slf4j，以过滤该包代码如下：1. 2. 3. -14. javax.servlet,mons.logging,org.slf4j5. 然后重启JBOSS服务器。原因分析： jboss加载jar包顺序问题。摘要：在最近修改SSO应用的时候，涉及到需要在jar包中读取工程配置文件的问题。在jar包中，读取配置文件，需要单独处理。项目中的一些配置文件，如perties log4j.xml 不想打包进jar。因为可能会修改其中的一些配置信息，打包进jar，就变得比较笨拙，不方便修改文件。可以用如下方式，实现在jar包中读取外部配置文件。方法一：关键代码。读取properties文件方法：InputStreamins=getClass().getResourceAsStream(/resource/perties);但是log4j.xml 又需要单独处理：PropertyConfigurator.configure(System.getProperty(user.dir)+/resource/log4j.xml);方法二：配置文件perties和jiar包在同一个目录下面：FileInputStreaminputStream1=newFileInputStream(perties); 配置文件perties在jar包内部：InputStreaminputStream2=a.class.getResourceAsStream(/perties);org.apache.axis2.AxisFault: WSDoAllReceiver:摘要：使用EOS7.2自动生成的客户端代码，在调用带有安全头部消息的webservice接口的时候，会经常出现 org.apache.axis2.AxisFault: WSDoAllReceiver: Incoming message does not contain required Security header的异常，可以照下文处理使用EOS7.2自动生成的客户端代码，在调用带有安全头部消息的webservice接口的时候，会经常出现 org.apache.axis2.AxisFault: WSDoAllReceiver: Incoming message does not contain required Security header的异常，表示传入的消息不包含所需的安全报头，经过分析发现是该方法在第一次被调用后，已经生成了一些安全校验数据，ListenerManager.defaultConfigurationContext不为空，无法对新的请求进行安全数据的封装，导致请求失败，应该清空ListenerManager.defaultConfigurationContext应用环境，重新生成对应的安全校验数据。可以照如下方式进行处理。在使用客户端代码的方法中，加入ListenerManager.defaultConfigurationContext = null;用于清空运行环境，以对新的请求，作出新的安全设置。示例代码片段：Bizletpublic Map sellOrderPriceUpdate(SellOrderImpl sellOrderImpl,SellOrderDetailImpl sellOrderDetailImpls) throws ExceptionListenerManager.defaultConfigurationContext = null; /重置axis2部分运行参数环境，用于新的请求ZCOP_SERVICEStub.ZifSoChange in=new ZCOP_SERVICEStub.ZifSoChange(); /输入ZifSoChangeResponse response=new ZCOP_SERVICEStub.ZifSoChangeResponse();/输出EOS在业务程序中获取逻辑构件执行的SQL语句文章文章详情EOS在业务程序中获取逻辑构件执行的SQL语句 发表于 3个月前 来自话题#应用开发平台（EOS Platform）#90浏览摘要：更改log4j的日志配置，使用类继承方式，方法重写，在程序中获取逻辑流执行SQL。 配置文件：应用配置目录 /log4j-sys.xml (可根据实际情况使用更改具体配置文件)；更改log4j的日志配置，使用类继承方式，方法重写，在程序中获取逻辑流执行SQL。配置文件：应用配置目录 /log4j-sys.xml (可根据实际情况使用更改具体配置文件)；配置文件说明：config/log4j-deploy.xml 部署日志 记录系统启动、停止、构件包部署、集群通知等信息的日志。config/log4j-trace.xml 跟踪日志 Server引擎的调试日志，用于系统维护人员定位系统运行问题使用。config/log4j-sys.xml 系统日志 大粒度的引擎运行的入口、出口的日志，用于调用栈分析，可以进行性能分析使用config/log4j-engine.xml 引擎日志 细粒度的引擎运行日志，可以打印上下文数据，用于定位业务问题。记录时机：页面流(P)执行、逻辑流(B)执行、服务(S)执行、Web服务(W)调用、定时任务(D)执行、JSP(J)执行、SQL(Q)执行（超过时限者记录）、运算逻辑(X)执行（超过时限者记录）；记录格式：有固定格式记录时间请求编号P|B|S|W|D|J|Q|X(类型)Begin|End|Exception|Run全名执行时长父全名IP地址登录用户ID登录用户名当前内存总量当前空闲内存量自定义信息。配置文件log4j-sys.xml ，找到log.sys.sql开关，off更改为all找到RollingFileAppender新建新类LimsLogOut继承RollingFileAppender，重写doAppend方法，方法参数LoggingEvent 内有属性可区分SQL。截图实例如下：由于该类记录SQL日志为超过时限者记录，时限默认设置为1000毫秒，很多sql执行时间可能不需要1000毫秒，需进行更改，找到sys-config.xml 配置文件，将属性LogSqlWhenTimeout设置为1。部署配置文件，在新建类LIMSLogOut中可以处理SQL日志。多个EOS连接同一个数据库出现定时器表锁定的问题解决方案文章bigdabao文章详情多个EOS连接同一个数据库出现定时器表锁定的问题解决方案bigdabao 发表于 4个月前 来自话题#应用开发平台（EOS Platform）#260浏览摘要：多个EOS连接同一个数据库出现定时器表锁定的问题解决方案问题描述：如果多个EOS连接同一个数据库，在server启动的时候，会出现EOS_QRTZ_LOCKS锁表的情况，导致Server启动不成功解决方案：多个环境连通过库，容易出现定时器锁表的问题，因为定时器默认情况下是启动，可尝试如下操作： true default 将颜色标记的true改为false（连同一个库的每个环境都需要改）用户session失效，ajax调用不能跳转的解决方案文章liucl文章详情用户session失效，ajax调用不能跳转的解决方案(Primeton EOS)liucl 发表于 9个月前 来自话题#应用开发平台（EOS Platform）#341浏览摘要：在某客户项目支持过程中发现session失效后，ajax还能继续调用，原因是在拦截器虽然能拦截到ajax调用，也做了跳转到index.jsp的操作，但由于是ajax调用，在index.jsp中并不能完成跳转，页面没有任何变化，所以不能正常跳转到登录页面，在abframe或其它项目可能也存在这种问题。场景一个基于Ajax技术的Web应用，采用的是多页面方式 ，每个页面内部使用Ajax实现复杂业务逻辑之间的无刷新切换，使用了Struts来实现MVC。问题对于Ajax请求，只有在通过用户验证无误之后才能对请求作出响应。如果用户长时间不做操作导致Session过时之后才发出请求，则此时应该跳转到出错页面，提示用户重新登录。对于非Ajax请求，可以自定义异常并针对此异常设置相应的出错页面。在用户信息验证失败的时候直接抛出此异常即可，web容器会自动捕捉到此异常并且显示出错页面；但是，对于Ajax请求，则不会如期待的那样自动跳转到出错页面。若不错特殊处理，Ajax请求的回调函数会得到意想不到的数据而导致程序出错。分析对于一个Ajax的应用，每一次客户端和服务器的数据交互，可以看成是在一个由客户端的XMLHttpRequest和服务器端的Servlet(这里假设用Servlet响应Ajax请求)组成的闭合管道。解决在Filter中，判断当前用户是否处理登录状态，如果session已经失效则调用response.getWriter.write(session_time_out);修改eos-ajax.js内容，判断返回的ajax.responseText的内容是否为session_time_out，如果相等，则认为session已经失效并调用top.location = auth/login.jsp；注意eos-ajax.js是平台js库文件，所以像auth/login.jsp这样的项目路径最后采用配置的方式。总结对于Ajax的请求，其数据流是封闭的，服务器发送给在客户端的数据都被XMLHttpRequest对象所获得。本文通过从Filter中发出javascript代码让其在客户端得到执行，从而可以在session过时验证用户信息失败之后，让客户端自动跳转到登录页面，与非Ajax请求时的客户体验相一致。对于Ajax请求，此方法进一步推广，可以直接在服务器端发出javascript让其在客户端得到执行。FTP大数据解决方案/articles/53c8c681e13823343b0000e3某客户系统EOS Platform流程数据丢失问题定位以及故障排除过程文章yang-yong文章详情某客户系统EOS Platform流程数据丢失问题定位以及故障排除过程yang-yong 发表于 9个月前 来自话题#应用开发平台（EOS Platform）#88浏览摘要：从解决问题的角度，我们不建议用户直接将Connection的autoCommit设置为false，理由就是这样破坏了数据库连接；如果用户需要将连接设置为false，则需要在用完连接后，将连接的状态设置回去；或者直接在外层使用事务。一.客户环境产品版本：EOS Platform 6.5服务器：Was7，4个节点的集群数据库：Oracle11gJDK版本：1.6浏览器：IE7二.问题描述客户环境上主要表现为通过逻辑流调用了BPS的服务，同时在逻辑流里面存在业务数据的操作，调用完逻辑流之后，流程数据和业务数据都丢失了，且整个过程没有抛出异常，问题只是偶然重现，而且只能在正式环境上重现，测试环境始终没有重现问题。三.问题分析定位过程1.熟悉客户系统，了解问题重现方式，发现流程数据丢失需要客户操作很多次才会出现一次，重现概率比较低；2.熟悉客户代码，发现客户的逻辑流里面存在嵌套事务，且业务操作和流程操作在同一个事务里面，对流程的操作在一个子事务里面，逻辑流里面事务设置都是接收外部事务，且同步join方式执行，没有新开事务的情况，也不存在事务图元不匹配的情况。3.分析报错后的错误日志，发现错误是从事务同步器里面抛出来的，原因是queryWorkItemDetail报错，即找不到工作项；正常的情况下，工作项不可能不存在，因为执行到事务同步器的时候，事务必定已经提交了，而此时查询工作项肯定可以查询到，但是目前的错误情况下，工作项不存在，即根据错误日志可以推断出：事务已经提交，但是数据没有入库。4.一开始对事务同步器理解不够深刻，以为用户调用了事务管理器的commit操作就会触发同步器的方法，所以一开始怀疑用户可能是事务使用不当，事务管理器的begin, commit不匹配之类的情况导致事务没有正真提交，数据没有入库，所以需要验证用户是不是正真做了事务提交；5.验证事务是不是正真做了提交：添加日志，在逻辑流里面的事务提交图元前后打印出事务状态，通过这个状态就能判断出事务管理器方法是不是存在不匹配的情况，同时在事务同步器里面打印出流程实例，活动实例，工作项实例的ID以及状态，线程ID，请求ID之类的信息，方便问题重现后定位问题；我们判断事务状态的目的是：如果用户正真做了提交，而数据没有入库，说明和产品存在一定关系，如果用户没有做事务提交，则是用户代码的问题，这样我们就可以根据这个状态进行2个大的方向定位。6.分析错误日志，对比正确情况和错误情况，发现打印出的事务状态2种情况是一样的，提交前是活动状态，提交后是无事务状态，说明用户正真做了事务提交，即用户使用的事务管理器begin，commit是匹配的；而且分析事务同步器里面打印出的流程实例，活动实例，工作项实例ID及状态也都是一样的，不存在异常情况，但是数据就是没有进入到数据库；7.由于事务管理器的使用方式没有问题，问题又回到原点；后续只能通过大量重现问题，仔细分析日志，看还能否找到其他的蛛丝马迹；由于这个问题是偶然重现，所以我们怀疑可能跟线程是否有关系，我们拿到大量的错误日志后，仔细查找这个问题是否和线程相关，发现他们存在一定的联系，我们分析日志得到规律是：如果一个线程出错后，后面所有由这个线程处理的逻辑流，流程数据都丢失，且有一个线程丢失的流程数据达8次之多；8.由于客户现场不能对正式环境进行远程调试，再加上测试环境一直重现不了，所以即使我们怀疑是线程问题，但是也无法进一步走下去。9.经过讨论会之后，我们开始定位数据库连接是否存在问题；后续我们还是通过打日志的方式来判断连接是否存在问题；我们在BPS获取连接的入口打印连接的实现类，连接的状态等信息；同时在事务管理器里面增加日志，在连接的setAutoCommit,close, commit方法上增加日志；10.分析日志：对比正确日志和错误日志可以发现，正确情况下，Connection的autoCommit状态是true，错误情况下，Connection的autoCommit状态是false；在正确情况下，Connection的autoCommit状态是true，我们怀疑用户的was环境存在问题，因为Connection受事务管理之后，autoCommit状态一定是false，所以我们验证用户的环境是否是正常的；我们使用JSP做了最简单的验证：开启事务，拿到连接，执行第一条sql，然后执行第二条sql，然后抛出异常，然后再执行第3条sql，最后提交，抛出异常则回滚，部署到用户的测试机器上验证，发现客户的服务器并没有回滚，前2条数据入库了；所以我们断定客户的环境出了问题。11.后面一天我们都在修改was服务的配置，以为是数据源配置错了，导致数据库连接不受事务管理；折腾了一天之后，最后发现was环境下，即使外部开了事务，Connection的autoCommit状态就是true，不像tomcat，Connection受事务管理之后，autoCommit是false；12.根据日志，如果说Connection的autoCommit状态是true是正确的，那么Connection的状态是false则可能就会存在问题；因为正确日志和错误日志只有这个地方存在区别；所以这个时候我们怀疑是连接坏了；继续分析日志，发现日志里面有在逻辑流里面调用了setAutoCommit的方法，用户代码将autoCommit属性设置了false，所以我们去走查用户代码，找到调用setAutoCommit的地方。四.解决问题1.找到用户代码之后，询问当事人为什么需要将Connection设置成false，当事人也说不出正确的理由，而且还说这个可以去掉，他只是复制的；所以我们将这行代码注释好之后，部署到测试服务器验证；同时验证打补丁之前和打补丁之后的测试环境，此时，则是环境能重现问题了，然后打上补丁之后，问题未能重现。第二天将补丁打到生产环境，问题也未能重现，问题即解决。2.在问题的验证过程中，有人提出，在was容器下，Connection的autoCommit状态无论是true或者false对事务管理器没有任何影响，因为通过走j2ee事务的标准接口，在was容器下，无论autoCommit的状态是true还是false，事务管理器都是正常的；3.第二天我们对这一问题进行了验证，发现在was环境下，通过j2ee事务的标准接口使用事务，Connection的autoCommit状态true或者false，标准接口的事务确实不受影响；所以从另一个方面来说，eos的事务管理器对Connection的autoCommit状态为false这种情况支持的不够完善；五.结论1.从解决问题的角度，我们不建议用户直接将Connection的autoCommit设置为false，理由就是这样破坏了数据库连接；如果用户需要将连接设置为false，则需要在用完连接后，将连接的状态设置回去；或者直接在外层使用事务。2.从产品的角度，由于标准接口true或者false2种情况都支持，所以也可以说是EOS的事务管理器支持的不完善，在特定的环境下，事务管理器应该支持这2种情况。EOS6中配置C3P0数据源自动重连方案文章hanning文章详情EOS6中配置C3P0数据源自动重连方案hanning 发表于 9个月前 来自话题#应用开发平台（EOS Platform）#116浏览【适用范围】 EOS6.0、Tomcat、Jboss、Oracle【问题描述和定位】 在使用EOS6.0的时候，启动了Server后，如果网络出现问题Connection reset异常，Oracle数据库连接断了后就不能进行操作了，需要重新启动Server。那么，怎样配置可以避免重启Server，特别对于生产环境而言，需要尽可能的避免重启。【解决方案和步骤】1、Tomcat：在EOS Governor控制台的配置-数据源中，选中某数据源，点击修改，将“连接重试次数”默认值-1修改为1，点击“确定”保存。重启Server。 或者直接修改目录D:primetonfor3207_platformeosserverworkingeos-defaultconfig下user-config.xml文件中DataSource的配置： -1修改为 12、JBoss：修改$JBOSS_HOMEserverdefaultdeploy下的EOSProductDataSource-ds.xml，将默认的数据源配置改成如下（与EOS5环境下配置类似）： EOSDefaultDataSource jdbc:oracle:thin:23:1521:psooracle.jdbc.driver.OracleDriver eos60 eos60 5 100 5000 15 org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker select 1 from dualselect 1 from dual 【备注】修改这个配置还可以解决如果系统中需要多数据源的话，在这个文件中增加一个local-tx-datasource 配置；上面的配置可能对系统访问数据库的性能有影响，有可能每次拿数据库连接的时候都会自动调用这个sql语句；Weblogic、Websphere等应用服务器也应该提供了类似的自动重连机制，可以进到它们的控制台查看。EOS异常处理方法异常获取EOS的异常获取分为两种，一种是在逻辑流中获取异常，另一种是在java代码中获取异常。1.在逻辑流中获取异常如上图所示，开发人员需要在特定的图元上通过添加异常线并添加异常抛出图元（在左侧工具面板中的高级中）的方式来获取特定的异常信息。异常抛出图元需要开发人员先在构件包的配置文件中加入自定义的异常信息，对图元进行配置是选择相对应的ERRORCODE和ERRORMESSAGE。ERRORMESSAGE可以定义变量，以0,1的方式来进行变量绑定。配置文件路径：配置/resources/exception/perties。该配置支持中文并自动转码，同样在也支持国际化的配置。对于异常处理图元更详细的说明可以在EOS Studio的帮助文档中找到，具体路径：EOS帮助文档-技术参考-EOS基础参考手册-逻辑流-逻辑流编辑器-异常抛出。2.在java代码中获取异常EOS提供了默认实现的EOSException。当特定的springbean或者运算逻辑图元需要抛出异常，可以直接在代码中通过new EOSException的方式来抛出异常。该异常提供了多种构造方法，常用的是EOSException(java.lang.String code, java.lang.Object params)。Code是在配置文件中已经配置好的，params参数包含了message中的变量绑定。异常处理这里只介绍ajax调用逻辑流返回异常处理的方式。首先，当ajax调用逻辑流时逻辑流发生异常，ajax仍然会执行成功。因此异常的捕获会在success事件中进行。另外exception对象中的message包含了所有的异常信息，所以需要对message进行处理。EOS抛出的异常默认会使用换行符分隔。处理示例如下：nui.ajax( url: co