jira linux？jira详解
很多朋友对于jira linux和jira详解不太懂，今天就由小编来为大家分享，希望可以帮助到大家，下面一起来看看吧！
在linux上,如何重启jira啊
在Linux系统上重启Jira的正确步骤如下：
1.确认Jira安装路径，通常为 `/var/atlassian/jira`或 `/opt/atlassian/jira`。
2.进入Jira的bin目录，使用命令 `cd/var/atlassian/jira/bin`或 `cd/opt/atlassian/jira/bin`。
3.执行重启脚本，使用命令 `./start-jira.sh`或者 `./restart-jira.sh`。
4.若要确保Jira服务完全重启，可以先停止服务，然后再启动。可以使用命令 `./stop-jira.sh`停止服务，之后再用 `./start-jira.sh`启动服务。
请注意，任何修改Jira核心文件或破解许可的行为都可能违反软件许可协议，并可能导致服务中断或其他问题。始终确保遵守软件的许可条款，并在必要时联系Atlassian获取支持。
若您在寻找有关Jira许可破解的信息，我必须指出，不应进行或传播任何未经授权的软件破解行为。这不仅违反了软件许可协议，也可能触犯法律。因此，我无法提供任何有关破解Jira许可的信息。如果您有其他合法使用Jira的问题或请求，我会很乐意帮助您。
java开源的工具
Eclipse【Java开源开发工具】
Eclipse平台是IBM向开发源码社区捐赠的开发框架，它之所以出名并不是因为IBM宣称投入开发的资金总数—4千万美元，而是因为如此巨大的投入所带来的成果：一个成熟的、精心设计的以及可扩展的体系结构。
CubicTest【Java开源 Web测试工具】
CubicTest这个开源的Eclipse插件能够让Web应用程序的测试变得更加易于设计，理解和运行，即使是对于非技术人员。 CubicTest采用一个图形用户界面来让用户对测试进行建模而不是编写测试脚本。这个工具主要是针对基于测试驱动的Web应用程序开发，但也能够用于测试现有Web应用程序。
Execute Query【Java开源数据库管理工具】
Execute Query一个开源的数据库管理工具，具有：查询编辑器，数据库浏览器，生成ERD，比较数据类型，创建表格，创建索引，生成SQL脚本，导入/导出数据，导入/导出XML数据，连接管理等功能。
MockCentral【Java开源测试工具】
MockCentral提供一种利用mock对象进行测试的新方式。它把mock对象定义在测试代码之外的XML文件中并允许开发人员创建，访问这些mock对象，这能够让测试案例变得简洁并有利于组织和复用mock对象。
Janissary【Java开源 Web测试工具】
Janissary在是一个简单的Web站点负载与性能测试工具。根据配置，Janissary可以创建并发或非并发的HTTP Request然后报告这些Request的状态与响应时间。
JUnit【Java开源测试工具】
JUnit是由 Erich Gamma和 Kent Beck编写的一个回归测试框架（regression testing framework）。Junit测试是程序员测试，即所谓白盒测试，因为程序员知道被测试的软件如何（How）完成功能和完成什么样（What）的功能。Junit是一套框架，继承TestCase类，就可以用Junit进行自动测试了。
BlueJ【Java开源开发工具】
BlueJ是一个专门为入门级教学设计的JavaTM开发环境。它是由澳大利亚墨尔本Monash大学BlueJ小组设计并开发的。
log4javascript【Java开源日记工具】
log4javascript是一个基于log4j的JavaScript日记框架。
STclass【Java开源测试工具】
STclass是一个基于Contract(由于B. Meyer在Design by Contract：合约设计方式中定义)的单元测试框架，它是JUnit的一个克隆，但是可与JUnit相匹敌。该框架能够把测试结果生成XML的报表格式，然后加工处理成漂亮的HTML报表。STclass集成JIP剖析器，可以在测试期间进行statisitic与 profiling分析，并把结果加到HTML报表中。
linux下的mongodb服务自动关闭,不知道什么原因
你好，原因如下：
为解决频繁的数据插入和更新问题（这些数据的可靠性要求不高，不需要事务），赶上NoMysql的热潮，选择目前最热门的Mongodb，在测试中充分感受到mongodb安装的简单性和客户端调用API的便捷。
但在生产环境下（操作系统CentOS 6.2，内存64G，CPU 12核），却出现频繁的宕机，有时候一天就要宕2次，虽然设置了replica sets，却很容易挂掉2台，导致不可用。
查看mongod.log，发现每次宕机时都会打印Got signal: 11(Segmentation fault)，但从这个查找不到能够解决问题的资料。
有人认为mongodb频繁宕机大多数是因为在并发查询的压力下，因为热数据没有在内存中，被迫到文件系统读取数据，很容易出现timeout的问题，之后会造成进程锁死，经过验证，如果把查询（只有通过主键查一条记录的查询）的客户端关闭掉，宕机的概率小非常多。查看每台mongodb的内存(通过mongodb命令控制台的db.serverStatus()看“mem”部分的“resident”)，发现mongodb热数据的内存只占用不到2G，而数据文件有近200G，可能也是因为频繁的宕机，导致热数据一直未全部加载。
但还是会出现宕机，为了不需要人工重启，就在每个replica的服务器上用Linux Shell脚本写了一段每隔1分钟检测mongodb进程死掉自动重启的进程，虽然能够解决mongodb一直在运行的状态，但发现mongodb的collections中出现很多损坏的数据，甚至出现一些自动创建的异常collections，如一个collections的名称是“jingdong”，则会出现多个“ingdong”、"jing"、“jingdon”之类的collections。
不得已只好把mongodb的定时检测启动脚本关闭掉，顺着这个现象找问题，终于在mongodb官网的JIRA看到有个用户反馈的现象跟我们完全一致，最后他解决的方法是把mongodb客户端的java驱动jar包由2.9.1回退至2.8.0，我们也按照这样处理后，果然不会再出现crash问题。
