[JBoss Remoting] - Remoting threads never get closed
by Dennis Kieselhorst
Dennis Kieselhorst [https://community.jboss.org/people/kieselhorst] created the discussion
"Remoting threads never get closed"
To view the discussion, visit: https://community.jboss.org/message/797283#797283
--------------------------------------------------------------
Hi,
I'm using a standalone remote client as https://docs.jboss.org/author/display/AS71/EJB+invocations+from+a+remote+... described in the wiki in combination with a ConfigBasedEJBClientContextSelector. Several worker threads named Remoting "endpoint name" read-1, write-1, task-1, task-2, task-3 and task-4 are created and never get destroyed. The read-1 and write-1 threads are in state RUNNABLE:
Stack trace:
sun.nio.ch.WindowsSelectorImpl$SubSelector.poll0(Native Method)
sun.nio.ch.WindowsSelectorImpl$SubSelector.poll(WindowsSelectorImpl.java:273)
sun.nio.ch.WindowsSelectorImpl$SubSelector.access$400(WindowsSelectorImpl.java:255)
sun.nio.ch.WindowsSelectorImpl.doSelect(WindowsSelectorImpl.java:136)
sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
- locked sun.nio.ch.Util$2@478f67d0
- locked java.util.Collections$UnmodifiableSet@17e8ad64
- locked sun.nio.ch.WindowsSelectorImpl@7c9aff86
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:84)
org.xnio.nio.WorkerThread.run(WorkerThread.java:153)
The task-* threads are in state WAITING.
Is it possible to create an idle timeout?
Current properties supplied in a PropertiesBasedEJBClientConfiguration:
Properties p = new Properties();
p.put("endpoint.name", "client-endpoint-for-"+userName);
p.put("remote.connectionprovider.create.options.org.xnio.Options."+org.xnio.Options.SSL_ENABLED.getName(), "false");
p.put("remote.connections", "default");
p.put("remote.connection.default.port", String.valueOf(port));
p.put("remote.connection.default.host", host);
p.put("remote.connection.default.username", userName);
p.put("remote.connection.default.password", password);
p.put("remote.connection.default.connect.options.org.xnio.Options."+org.xnio.Options.SASL_POLICY_NOANONYMOUS.getName(), "false");
p.put("remote.connection.default.connect.options.org.xnio.Options."+org.xnio.Options.SASL_POLICY_NOPLAINTEXT.getName(), "false");
p.put("remote.connection.default.connect.options.org.xnio.Options."+org.xnio.Options.SASL_DISALLOWED_MECHANISMS.getName(), "JBOSS-LOCAL-USER");
p.put("remote.connection.default.connect.options.org.xnio.Options."+org.xnio.Options.KEEP_ALIVE.getName(), "true");
p.put("remote.connection.default.connect.options.org.jboss.remoting3."+RemotingOptions.HEARTBEAT_INTERVAL, String.valueOf(heartbeatInterval));
Thanks in advance!
Regards
Dennis
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/797283#797283]
Start a new discussion in JBoss Remoting at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
12 years, 11 months
[jBPM] - Getting errors after login through jbpm-console
by snowstorm tech
snowstorm tech [https://community.jboss.org/people/snowstormuser] created the discussion
"Getting errors after login through jbpm-console"
To view the discussion, visit: https://community.jboss.org/message/797410#797410
--------------------------------------------------------------
Hi,
I am using jbpm5.4 on glassfish server3.1.2. I deploy “jbpm-human-task”, “gwt-console-server”,” jbpm-console” successfully on glassfish server 3.1.2. I am able to login through “jbpm-console” using admin/admin username/password respectively .But I am getting following errors
> 2013-02-13 14:59:01,908 [DEBUG] new subscription: appContext.model.listener -> org.jboss.bpm.console.client.task.AssignedTasksView$8@117
> 2013-02-13 14:59:01,911 [DEBUG] New Subscription: appContext.model.listener
> 2013-02-13 14:59:02,547 [DEBUG] GET: http://localhost:8282/gwt-console-server/rs/tasks/admin
> 2013-02-13 14:59:02,667 [ERROR] <ul><li>URL: 'http://localhost:8282/gwt-console-server/rs/tasks/admin'
> <li>Action: 'org.jboss.bpm.console.client.task.LoadTasksAction'
> <li>Exception: 'class com.google.gwt.http.client.RequestException'</ul>
>
> HTTP 500: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><title>GlassFish Server Open Source Edition 3.1.2 - Error report</title><style type="text/css"><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 500 - </h1><hr/><p><b>type</b> Exception report</p><p><b>message</b></p><p><b>description</b>The server encountered an internal error () that prevented it from fulfilling this request.</p><p><b>exception</b> <pre>org.jboss.resteasy.spi.UnhandledException: java.lang.RuntimeException: Session was not initialized, check previous errors in log</pre></p><p><b>note</b> <u>The full stack traces of the exception and its root causes are available in the GlassFish Server Open Source Edition 3.1.2 logs.</u></p><hr/><h3>GlassFish Server Open Source Edition 3.1.2</h3></body></html>
> com.google.gwt.http.client.RequestException:
> *HTTP 500: *
> *HTTP Status 500 -*
> * *
> ----
> * *
> *type Exception report*
> *message*
> *descriptionThe server encountered an internal error () that prevented it from fulfilling this request.*
> *exception*
> * *org.jboss.resteasy.spi.UnhandledException: java.lang.RuntimeException: Session was not initialized, check previous errors in log*
> *note The full stack traces of the exception and its root causes are available in the GlassFish Server Open Source Edition 3.1.2 logs.*
> * *
> ----
> * *
> *GlassFish Server Open Source Edition 3.1.2*
> at Unknown.$fillInStackTrace_1(JsArrayString.java:42)
> at Unknown.$RequestException(StackTraceCreator.java:366)
> at Unknown.onResponseReceived_5(AbstractRESTAction.java:93)
> at Unknown.$fireOnResponseReceived(Request.java:287)
> at Unknown.onReadyStateChange_0(RequestBuilder.java:393)
> at Unknown.anonymous(XMLHttpRequest.java:258)
> at Unknown.entry0(Impl.java:146)
> at Unknown.anonymous(Impl.java:56)
>
> [#|2013-02-13T14:59:02.634+0530|WARNING|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=26;_ThreadName=Thread-2;|StandardWrapperValve[Resteasy]: PWC1406: Servlet.service() for servlet Resteasy threw exception
> * org.jboss.resteasy.spi.UnhandledException: java.lang.RuntimeException: Session was not initialized, check previous errors in log
> at org.jboss.resteasy.core.SynchronousDispatcher.unwrapException(SynchronousDispatcher.java:345)
> at org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:321)
> at org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:214)
> at org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:190)
> at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:534)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:496)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:119)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
> at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1542)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
> at org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:393)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
> at org.jboss.bpm.console.server.util.GWTJsonFilter.doFilter(GWTJsonFilter.java:59)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
> at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
> at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317)
> at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
> at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849)
> at com.sun.grizzly.comet.CometEngine.executeServlet(CometEngine.java:444)
> at com.sun.grizzly.comet.CometEngine.handle(CometEngine.java:308)
> at com.sun.grizzly.comet.CometAsyncFilter.doFilter(CometAsyncFilter.java:87)
> at com.sun.grizzly.arp.DefaultAsyncExecutor.invokeFilters(DefaultAsyncExecutor.java:171)
> at com.sun.grizzly.arp.DefaultAsyncExecutor.interrupt(DefaultAsyncExecutor.java:143)
> at com.sun.grizzly.arp.AsyncProcessorTask.doTask(AsyncProcessorTask.java:102)
> at com.sun.grizzly.http.TaskBase.run(TaskBase.java:193)
> at com.sun.grizzly.http.TaskBase.execute(TaskBase.java:175)
> at com.sun.grizzly.arp.DefaultAsyncHandler.handle(DefaultAsyncHandler.java:145)
> at com.sun.grizzly.arp.AsyncProtocolFilter.execute(AsyncProtocolFilter.java:210)
> at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
> at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
> at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
> at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
> at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
> at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
> at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
> at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
> at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: java.lang.RuntimeException: Session was not initialized, check previous errors in log
> at org.jbpm.integration.console.StatefulKnowledgeSessionUtil.getStatefulKnowledgeSession(StatefulKnowledgeSessionUtil.java:89)
> at org.jbpm.integration.console.SessionInitializer.<init>(SessionInitializer.java:25)
> at org.jbpm.integration.console.TaskManagement.<init>(TaskManagement.java:52)
> at org.jbpm.integration.console.ManagementFactory.createTaskManagement(ManagementFactory.java:26)
> at org.jbpm.integration.console.ManagementFactory.createTaskManagement(ManagementFactory.java:19)
> at org.jboss.bpm.console.server.TaskListFacade.getTaskManagement(TaskListFacade.java:72)
> at org.jboss.bpm.console.server.TaskListFacade.getTasksForIdRef(TaskListFacade.java:101)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140)
> at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:255)
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:220)
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:209)
> at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:519)
> ... 45 more
> |#]
>
Thanks in advance
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/797410#797410]
Start a new discussion in jBPM at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
12 years, 11 months
[JBoss Tools] - Tagging/branching of JBoss Tools Core subcomponents
by Nick Boldt
Nick Boldt [https://community.jboss.org/people/nickboldt] modified the document:
"Tagging/branching of JBoss Tools Core subcomponents"
To view the document, visit: https://community.jboss.org/docs/DOC-48350
--------------------------------------------------------------
Our recent move to git caused some confusion on how we tag/branch components in JBoss Tools core components.
h1. Current Tag/Branching strategy
To avoid future confusion here are the short version of the current approach:
1. Each component has its own version in manifest.mf/pom.xml/feature.xml* This can be set quickly using mvn -Dtycho.mode=maven org.sonatype.tycho:tycho-versions-plugin:set-version -DnewVersion=1.2.3-SNAPSHOT
2. The git repositories should use tag/branches based on jbosstools version:* Branches: jbosstools-<version>*x* ("x" used to differentiate a branch from a tag)*
*Tags: jbosstools-<version> (no "x" suffix)
3. In Jira use the jbosstools version for reporting/targeting issues.
The advantage of the above is that git & jira use the same version. i.e. with a unified tag like "jbosstools-4.1.0.Alpha1" you can find which version is used of a specific component for a specific jboss tools release easily.
This means from git you always know which branch/tag to checkout for a component to get matching version to a specific jboss tools core build/release.
With Jira we would need to introduce a project for each individual component since Jira does not support version per components and thus jira queries for knowing current status of JBIDE suddenly gets very complex.
h1.
Discussion about improvements/future tagging can be found https://community.jboss.org/docs/DOC-48351 https://community.jboss.org/wiki/FutureStrategyForTaggingJBossToolsCore
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-48350]
Create a new document in JBoss Tools at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
12 years, 11 months
Re: [jboss-user] [JBoss Tools] - Future strategy for Tagging JBoss Tools core
by Denis Golovin
Denis Golovin [https://community.jboss.org/people/dgolovin] commented on the document
"Future strategy for Tagging JBoss Tools core"
To view all comments on this document, visit: https://community.jboss.org/docs/DOC-48351#comment-11563
--------------------------------------------------
"Branches in git are very lightweight: A branch in git is only a reference to a single commit. With its parental commits, the full branch structure can be constructed." So it takes nothing to have it and gives consistency throughout components. We have to build unchanged components anyway as a step to be sure it still compilable and especially for components in the middle of dependency tree.
Actually all components are changed between releases, but changes not always affects eclipse related code, so it is good to have those changes branched/tagged.
--------------------------------------------------
12 years, 11 months
[jBPM] - Task deadline issue
by tom sebastian
tom sebastian [https://community.jboss.org/people/tomsebastian] created the discussion
"Task deadline issue"
To view the discussion, visit: https://community.jboss.org/message/796985#796985
--------------------------------------------------------------
Hi all
,
I am using jbpm 5.2 and jbpm humantask implementation 5.2. We currently upgrade the designer.war to configure reassignment, notification through UI. We could successfully ser task deadlines. Reassigments and notifications are working at correct time with unexpected behaviour. For eg: suppose I configured "not-started" reassignment and notification with expiration time 2 min. Then even if I started the task(set status to inProgress) deadline triggers and reassignments, notifications happen.
Is it the default feature/implementations ?
I want to know whether we need to check this(is task started/ completed) befor reassigning/ sending notifications by writing our own EscalatedDeadline handler?
Please help
Thanks & regards
Tom
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/796985#796985]
Start a new discussion in jBPM at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
12 years, 11 months