[JBoss JIRA] (WFLY-3164) Create customized Audit Logger
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3164?page=com.atlassian.jira.plugin.... ]
Kabir Khan reassigned WFLY-3164:
--------------------------------
Assignee: Kabir Khan (was: Brian Stansberry)
> Create customized Audit Logger
> ------------------------------
>
> Key: WFLY-3164
> URL: https://issues.jboss.org/browse/WFLY-3164
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Labels: EAP
> Fix For: 9.0.0.CR1
>
>
> Some users want to have a single line audit log formatter. I think it would be better to have the ability to add your own formatter from a module, something along the lines of:
> {code}
> <custom-formatter code="org.blah.MyCustomFormatter" module="org.blah/mymodule">
> <property name="layout">...</property>
> <property name="propB">...</property>
> </custom-formatter>
> {code}
> We'd need an SPI, and a slight reworking of the audit log internals. In any case doing this will put us in a better position to provide the single line logger if this proposal is not acceptable to our users.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (WFLY-3170) system properties are trim()'d and loose whitespace
by Tom Fonteyne (JIRA)
[ https://issues.jboss.org/browse/WFLY-3170?page=com.atlassian.jira.plugin.... ]
Tom Fonteyne commented on WFLY-3170:
------------------------------------
yup, that's it indeed.
I'll get a pull request done for WildFly, but I understand the high risk /postponing for EAP
> system properties are trim()'d and loose whitespace
> ---------------------------------------------------
>
> Key: WFLY-3170
> URL: https://issues.jboss.org/browse/WFLY-3170
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.1.Final
> Reporter: Tom Fonteyne
> Assignee: Brian Stansberry
>
> When a system property was defined as:
> /system-property=foo:add(value=" spaces ");
> it gets written with the correct spaces around it to the configuration file.
> When the configuration is read the value gets trimmed and the prefix/suffix of spaces is lost.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (WFLY-3170) system properties are trim()'d and loose whitespace
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3170?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-3170:
----------------------------------------
Ah, I see. So you a proposing limiting the "no trim" behavior to types that store a string, STRING and the elements in in PROPERTY (perhaps just the value.)
I'd be open to trying this in WF 9, but it should not go into EAP 6 until it has been in the wild for a long time. Not in 6.3.x.
> system properties are trim()'d and loose whitespace
> ---------------------------------------------------
>
> Key: WFLY-3170
> URL: https://issues.jboss.org/browse/WFLY-3170
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.1.Final
> Reporter: Tom Fonteyne
> Assignee: Brian Stansberry
>
> When a system property was defined as:
> /system-property=foo:add(value=" spaces ");
> it gets written with the correct spaces around it to the configuration file.
> When the configuration is read the value gets trimmed and the prefix/suffix of spaces is lost.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (WFLY-3173) Default number of DIST owners is too conservative
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3173?page=com.atlassian.jira.plugin.... ]
Radoslav Husar reassigned WFLY-3173:
------------------------------------
Assignee: Radoslav Husar (was: Paul Ferraro)
> Default number of DIST owners is too conservative
> -------------------------------------------------
>
> Key: WFLY-3173
> URL: https://issues.jboss.org/browse/WFLY-3173
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Radoslav Husar
>
> WildFly uses DIST by default using 4 owners, which is too conservative. I think we should lower this default value to 2, which is Infinispan's default value. We'll get a nice performance bump too.
> Don't forget to create transformers to handle the default value change for old model versions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (WFLY-3173) Default number of DIST owners is too conservative
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-3173:
----------------------------------
Summary: Default number of DIST owners is too conservative
Key: WFLY-3173
URL: https://issues.jboss.org/browse/WFLY-3173
Project: WildFly
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: 8.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
WildFly uses DIST by default using 4 owners, which is too conservative. I think we should lower this default value to 2, which is Infinispan's default value. We'll get a nice performance bump too.
Don't forget to create transformers to handle the default value change for old model versions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (WFLY-3087) Websocket NullPointerException on io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3087?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-3087:
-----------------------------------
There ware many changes in work for 8.0.1 coming up soon,
can you test it if it is fixed there? you can grab nightly build at https://community.jboss.org/thread/224262
> Websocket NullPointerException on io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3087
> URL: https://issues.jboss.org/browse/WFLY-3087
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: windows server 2008
> Reporter: Admin FlirtyMob
> Assignee: Stuart Douglas
> Fix For: 8.0.1.Final
>
>
> 2014-03-07 17:10:49,208 ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.access$1100(AnnotatedEndpoint.java:126)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:332)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.BufferedBinaryMessage.read(BufferedBinaryMessage.java:76)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.onBinary(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:24)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:15)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:615)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:601)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:531) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (JGRP-1815) TP: sending a message to a non-existent physical address takes too much time
by Bela Ban (JIRA)
Bela Ban created JGRP-1815:
------------------------------
Summary: TP: sending a message to a non-existent physical address takes too much time
Key: JGRP-1815
URL: https://issues.jboss.org/browse/JGRP-1815
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.5
When sending a message in the transport, e.g. a message batch, and one or more destinations have no physical addresses in {{logical_addr_cache}}, then we loop {{physical_addr_max_fetch_attempts}} (default: 3) times and also sleep a random number of ms (in range [1..500]).
This delays the sending of other messages in the same batch, or of other messages in general. Also, if TransferQueueBundler is used, the transfer queue might get filled, so other sender threads are blocked.
SOLUTION:
* Remove the loop when sending a message: if the physical address for a message is not found, simply send a discovery request and drop the message
* The discovery request needs to be sent on a separate thread, as calling {{up(Event)}} directly could also delay the sending of the message or message batch.
* JGRP-1814 will also help, as connections to left members are closed, and therefore not finding a physical address for a destination should be rare
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (WFLY-3087) Websocket NullPointerException on io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
by Frank Hempel (JIRA)
[ https://issues.jboss.org/browse/WFLY-3087?page=com.atlassian.jira.plugin.... ]
Frank Hempel commented on WFLY-3087:
------------------------------------
It can be reproduced. All you have to do is don't implement the binaryMessage()-handler in the WebSocket endpoint class. Then the binaryMessage attribute of the AnnotatedEndpoint object is null which is not tested in the handleBinaryMessage method. Anyway, the result at clients would always be the same: no handler -> no action ;)
> Websocket NullPointerException on io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3087
> URL: https://issues.jboss.org/browse/WFLY-3087
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: windows server 2008
> Reporter: Admin FlirtyMob
> Assignee: Stuart Douglas
> Fix For: 8.0.1.Final
>
>
> 2014-03-07 17:10:49,208 ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.access$1100(AnnotatedEndpoint.java:126)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:332)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.BufferedBinaryMessage.read(BufferedBinaryMessage.java:76)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.onBinary(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:24)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:15)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:615)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:601)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:531) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months