不需要 Glassfish 4.1 re-deployment
Glassfish 4.1 unnecessary re-deployment
如标题所示,GlassFish 4.1 服务器决定用一些随机的 re-deployment 来扰乱我的 web-application,这会删除我在 session 中的所有属性,但不知何故保留了session ID 完整。
这个问题主要发生在我尝试 select 一个 combo-box 触发表单提交时,它将被发送到 Servlet 以从数据库中收集必要的信息来填充必要的信息相同形式的文本字段(由 JSP 完成),我无法解决问题的原因是它发生在第三次或第四次 select 尝试中,有时它甚至不会发生在全部.
服务器日志根本帮不上什么忙,因为这些是它决定重新部署时唯一弹出的消息。
服务器日志:
Info: visiting unvisited references
Info: visiting unvisited references
Info: visiting unvisited references
Info: WebModule[null] ServletContext.log():filter_user:Initializing filter
Info: Loading application [IMS_Test] at [/IMS_Test]
Info: IMS_Test was successfully deployed in 558 milliseconds.
Servlet 代码:
List<String> list = new ArrayList<String>();
rs = stmt.executeQuery("SELECT scp_id FROM ims_db.ims_scp_list WHERE scp_name = '" + t_scp_name + "'");
if (rs.next()) {
scp_id = rs.getString("scp_id");
}
rs = stmt.executeQuery("SELECT epicor_id FROM ims_db.ims_parts_plan "
+ "WHERE scp_id = '" + scp_id + "'");
while (rs.next()) {
list.add(rs.getString("epicor_id"));
}
RequestDispatcher rd = request.getRequestDispatcher("new_entryform.jsp");
session.setAttribute("epicor_list", list);
session.removeAttribute("scp_name");
session.setAttribute("scp_name", t_scp_name);
rd.forward(request, response);
所以问题是,我做错了什么最终迫使 GlassFish 在操作过程中重新部署我的 web-app?请帮帮我:(
更新 1:
出于绝望,我创建了一个 SessionListener 来查看问题所在。在调试期间它显示所有代码都按预期执行,但有时它会在之后立即跳转到 "attributeRemoved",这真的没有意义。
更新 2:
不得已,将原始表单拆分为两个单独的表单,其中一个使用 GET 方法,而主表单使用 POST 方法。它暂时解决了这个问题。
更新 3:
每当我尝试将表单提交到服务器时,这些问题仍然困扰着我,但它只发生在 POST 方法中。尝试升级到 GlassFish 5.0(每晚构建),但问题似乎并没有消失。任何指导/建议将不胜感激。 :(
经过数周的努力,我终于找到了答案。显然,随机重新部署是由我尝试访问的 servlet 中的 @MultipartConfig 注释设置不当引起的。
将其更改为以下内容解决了问题:
@MultipartConfig(location="\fileDest", fileSizeThreshold=1024*1024,
maxFileSize=1024*1024*5, maxRequestSize=1024*1024*5*5)
如标题所示,GlassFish 4.1 服务器决定用一些随机的 re-deployment 来扰乱我的 web-application,这会删除我在 session 中的所有属性,但不知何故保留了session ID 完整。
这个问题主要发生在我尝试 select 一个 combo-box 触发表单提交时,它将被发送到 Servlet 以从数据库中收集必要的信息来填充必要的信息相同形式的文本字段(由 JSP 完成),我无法解决问题的原因是它发生在第三次或第四次 select 尝试中,有时它甚至不会发生在全部.
服务器日志根本帮不上什么忙,因为这些是它决定重新部署时唯一弹出的消息。
服务器日志:
Info: visiting unvisited references
Info: visiting unvisited references
Info: visiting unvisited references
Info: WebModule[null] ServletContext.log():filter_user:Initializing filter
Info: Loading application [IMS_Test] at [/IMS_Test]
Info: IMS_Test was successfully deployed in 558 milliseconds.
Servlet 代码:
List<String> list = new ArrayList<String>();
rs = stmt.executeQuery("SELECT scp_id FROM ims_db.ims_scp_list WHERE scp_name = '" + t_scp_name + "'");
if (rs.next()) {
scp_id = rs.getString("scp_id");
}
rs = stmt.executeQuery("SELECT epicor_id FROM ims_db.ims_parts_plan "
+ "WHERE scp_id = '" + scp_id + "'");
while (rs.next()) {
list.add(rs.getString("epicor_id"));
}
RequestDispatcher rd = request.getRequestDispatcher("new_entryform.jsp");
session.setAttribute("epicor_list", list);
session.removeAttribute("scp_name");
session.setAttribute("scp_name", t_scp_name);
rd.forward(request, response);
所以问题是,我做错了什么最终迫使 GlassFish 在操作过程中重新部署我的 web-app?请帮帮我:(
更新 1: 出于绝望,我创建了一个 SessionListener 来查看问题所在。在调试期间它显示所有代码都按预期执行,但有时它会在之后立即跳转到 "attributeRemoved",这真的没有意义。
更新 2: 不得已,将原始表单拆分为两个单独的表单,其中一个使用 GET 方法,而主表单使用 POST 方法。它暂时解决了这个问题。
更新 3: 每当我尝试将表单提交到服务器时,这些问题仍然困扰着我,但它只发生在 POST 方法中。尝试升级到 GlassFish 5.0(每晚构建),但问题似乎并没有消失。任何指导/建议将不胜感激。 :(
经过数周的努力,我终于找到了答案。显然,随机重新部署是由我尝试访问的 servlet 中的 @MultipartConfig 注释设置不当引起的。
将其更改为以下内容解决了问题:
@MultipartConfig(location="\fileDest", fileSizeThreshold=1024*1024,
maxFileSize=1024*1024*5, maxRequestSize=1024*1024*5*5)