[JBoss JIRA] (LOGMGR-122) Syslog handler is not generating correct timestamp format
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-122?page=com.atlassian.jira.plugin... ]
James Perkins commented on LOGMGR-122:
--------------------------------------
Thanks for finding this! I've released a 2.0.1.Final version which is compatible with WildFly 9 so you could just replace the module.
> Syslog handler is not generating correct timestamp format
> ---------------------------------------------------------
>
> Key: LOGMGR-122
> URL: https://issues.jboss.org/browse/LOGMGR-122
> Project: JBoss Log Manager
> Issue Type: Bug
> Affects Versions: 2.0.0.Final
> Environment: Wildfly 9.0.1.Final, Oracle JRE 1.8.0_11, CentOS 6
> Reporter: Ricardo Kagawa
> Assignee: James Perkins
> Fix For: 1.4.4.Final, 1.5.5.Final, 2.0.1.Final, 2.1.0.Beta1
>
>
> The Syslog handler is outputting an extra zero before the month in the header timestamp for RFC5424, specifically for October.
> Checking [Github|https://github.com/jboss-logging/jboss-logmanager/blob/master/src/...], I have noticed that the month number is tested for double digit before being offset, so a zero is added for October (month 9 for java.util.Calendar), then offset for proper display (month "10" for ISO8601), resulting in a three-digit month ("010").
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (WFCORE-1025) ManagementRequestContext executeAsync hides RejectedExecutionException
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1025:
----------------------------------------
Summary: ManagementRequestContext executeAsync hides RejectedExecutionException
Key: WFCORE-1025
URL: https://issues.jboss.org/browse/WFCORE-1025
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 2.0.0.CR5
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 2.0.0.CR6
The impl of ManagementRequestContext executeAsync catches RejectedExecutionException and doesn't notify the calling thread. The handling itself seems ok (call failed on the result handler and send a failure response to the client), but not notifying the caller is problematic. There are a number of cases where the caller thread waits for a latch to be tripped, with the async task tripping. If the latch never trips, the caller thread will block forever. The testsuite hang at http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=71233&buildTyp... looks to be a case of this, with a server not stopping due to this:
{code}
"Remoting "master:main-one:MANAGEMENT" task-13" #55 prio=5 os_prio=0 tid=0xc6c3bc00 nid=0x19d9 waiting on condition [0xc215c000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xddbb4aa0> (a java.util.concurrent.CountDownLatch$Sync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.sendResponse(TransactionalProtocolOperationHandler.java:540)
at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestContext.failed(TransactionalProtocolOperationHandler.java:377)
- locked <0xddbb2300> (a org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestContext)
at org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl$2.handleFailed(ActiveOperationSupport.java:350)
at org.jboss.threads.AsyncFutureTask$Reg.run(AsyncFutureTask.java:60)
at org.jboss.as.protocol.mgmt.ActiveOperationSupport$1.execute(ActiveOperationSupport.java:55)
at org.jboss.threads.AsyncFutureTask.safeExecute(AsyncFutureTask.java:169)
at org.jboss.threads.AsyncFutureTask.setFailed(AsyncFutureTask.java:162)
at org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl.access$400(ActiveOperationSupport.java:295)
at org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl$1.failed(ActiveOperationSupport.java:315)
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2.executeAsync(AbstractMessageHandler.java:333)
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2.executeAsync(AbstractMessageHandler.java:315)
at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.handleRequest(TransactionalProtocolOperationHandler.java:144)
at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:270)
at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:252)
at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:123)
at org.jboss.as.protocol.mgmt.ManagementChannelReceiver$1.handleMessage(ManagementChannelReceiver.java:56)
at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:85)
at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:463)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
The RejectedExecutionException indicates a thread pool has been shutdown before the response has gone out. Ideally we would prevent that (for which I've recently filed a JIRA) but in any case we should make this more robust.
I think having executeAsync return a boolean should suffice.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (DROOLS-934) Persistence unit tests - DB2 default schema not specified
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-934?page=com.atlassian.jira.plugin... ]
Petr Široký reassigned DROOLS-934:
----------------------------------
Assignee: Petr Široký (was: Mark Proctor)
Resolution: Done
Fixed by Tibor and merged into 6.3.x and master branched.
> Persistence unit tests - DB2 default schema not specified
> ---------------------------------------------------------
>
> Key: DROOLS-934
> URL: https://issues.jboss.org/browse/DROOLS-934
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final
> Reporter: Tibor Zimányi
> Assignee: Petr Široký
> Priority: Minor
> Fix For: 6.4.x
>
>
> Unit tests in drools-persistence-jpa don't work on DB2 database system because there isn't specified DB schema in tests.
> Things needed to be done:
> - hibernate.default_schema property set in persistence.xml
> - schema should be set in PersistenceUtil, when creating data source
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (DROOLS-934) Persistence unit tests - DB2 default schema not specified
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-934?page=com.atlassian.jira.plugin... ]
Petr Široký edited comment on DROOLS-934 at 10/1/15 11:07 AM:
--------------------------------------------------------------
Fixed by Tibor and merged into 6.3.x and master branches.
was (Author: psiroky-redhat.com):
Fixed by Tibor and merged into 6.3.x and master branched.
> Persistence unit tests - DB2 default schema not specified
> ---------------------------------------------------------
>
> Key: DROOLS-934
> URL: https://issues.jboss.org/browse/DROOLS-934
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final
> Reporter: Tibor Zimányi
> Assignee: Petr Široký
> Priority: Minor
> Fix For: 6.4.x
>
>
> Unit tests in drools-persistence-jpa don't work on DB2 database system because there isn't specified DB schema in tests.
> Things needed to be done:
> - hibernate.default_schema property set in persistence.xml
> - schema should be set in PersistenceUtil, when creating data source
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (DROOLS-932) kie-server POST fails with org.kie.server.api.marshalling.MarshallingException: Can't marshall input object:
by Maciej Swiderski (JIRA)
[ https://issues.jboss.org/browse/DROOLS-932?page=com.atlassian.jira.plugin... ]
Maciej Swiderski commented on DROOLS-932:
-----------------------------------------
First of all, could you provide a reproducer or at least describe what sort of facts you're entering as use of org.drools.core.runtime.rule.impl.FlatQueryResults looks bit weird.
since jaxb is default marshaller you need to provide classes to jaxb context so they can be automatically marshalled. you can do that by defining dependencies on your kjar so they will be loaded.
Alternatively you can change the marshaller (when using kie server client) to XSTREAM to see if that deals with the problem.
{code}
KieServicesConfiguration configuration = KieServicesFactory.newRestConfiguration(....);
configuration.setMarshallingFormat(MarshallingFormat.XSTREAM);
{code}
> kie-server POST fails with org.kie.server.api.marshalling.MarshallingException: Can't marshall input object:
> -------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-932
> URL: https://issues.jboss.org/browse/DROOLS-932
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.3.0.Final
> Environment: kie-server 6.3.0.FINAL with JBoss EAP 6.4.0 or Widfly 8.1.0.FINAL
> Reporter: Stefano Picozzi
> Assignee: Maciej Swiderski
> Priority: Blocker
>
> The GET and PUT APIs work OK, e.g. to GET KIE-SERVER details or to PUT a new container.
> However a POST to e.g. send some facts to test actual rule reasoning fails as per this log snippet:
> 07:24:27,998 INFO [org.kie.server.services.impl.KieServerImpl] (http-/0.0.0.0:8080-1) Container watch (for release id com.redhat.demos:weightwatchers:1.0) successfully started
> 07:24:45,028 ERROR [org.kie.server.services.impl.KieContainerCommandServiceImpl] (http-/0.0.0.0:8080-1) Error calling container 'watch': org.kie.server.api.marshalling.MarshallingException: Can't marshall input object: org.drools.core.runtime.impl.ExecutionResultImpl@3c402d4b
> at org.kie.server.api.marshalling.jaxb.JaxbMarshaller.marshall(JaxbMarshaller.java:187) [kie-server-api-6.3.0.Final.jar:6.3.0.Final]
> at org.kie.server.services.impl.KieContainerCommandServiceImpl.callContainer(KieContainerCommandServiceImpl.java:114) [kie-server-services-common-6.3.0.Final.jar:6.3.0.Final]
> at org.kie.server.remote.rest.drools.CommandResource.manageContainer(CommandResource.java:73) [kie-server-rest-drools-6.3.0.Final.jar:6.3.0.Final]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_65]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_65]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_65]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:168) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:541) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:523) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:512) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:400) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
> Caused by: javax.xml.bind.MarshalException
> - with linked exception:
> [com.sun.istack.SAXException2: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.
> javax.xml.bind.JAXBException: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.]
> at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:326) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:251) [jaxb-impl-2.2.11.jar:2.2.11]
> at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:95) [jboss-jaxb-api_2.2_spec-1.0.4.Final-redhat-3.jar:1.0.4.Final-redhat-3]
> at org.kie.server.api.marshalling.jaxb.JaxbMarshaller.marshall(JaxbMarshaller.java:185) [kie-server-api-6.3.0.Final.jar:6.3.0.Final]
> ... 32 more
> Caused by: com.sun.istack.SAXException2: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.
> javax.xml.bind.JAXBException: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.
> at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:247) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:262) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:653) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:158) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:360) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:696) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.ArrayBeanInfoImpl.serializeBody(ArrayBeanInfoImpl.java:142) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:696) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:158) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:360) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsSoleContent(XMLSerializer.java:593) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeRoot(ClassBeanInfoImpl.java:341) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:494) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:323) [jaxb-impl-2.2.11.jar:2.2.11]
> ... 35 more
> Caused by: javax.xml.bind.JAXBException: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.
> at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getBeanInfo(JAXBContextImpl.java:582) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:648) [jaxb-impl-2.2.11.jar:2.2.11]
> ... 46 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months