March 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (LOGMGR-120) Thread local log level overriding

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-120?page=com.atlassian.jira.plugin... ] David Lloyd commented on LOGMGR-120: ------------------------------------ The only reason we need the system property is because thread local access is very slow compared to our existing volatile int read. So this functionality would have to be enabled by a boolean constant field that we initialize from a system property so that C2 can eliminate the extra code completely when it isn't enabled, something like this: {code} final int effectiveLevel = loggerNode.getEffectiveLevel(); if ((level.intValue() < effectiveLevel || effectiveLevel == OFF_INT) && !(PER_THREAD_ENABLED && level.intValue() < threadLocal.get().intValue())) { return; } {code} If C2 compiles this code and PER_THREAD_ENABLED is false, it reduces like this: {code} if ((level.intValue() < effectiveLevel || effectiveLevel == OFF_INT) && !(PER_THREAD_ENABLED && level.intValue() < threadLocal.get().intValue())) { // becomes: if ((level.intValue() < effectiveLevel || effectiveLevel == OFF_INT) && !(false && level.intValue() < threadLocal.get().intValue())) { // becomes: if ((level.intValue() < effectiveLevel || effectiveLevel == OFF_INT) && !(false)) { // becomes: if ((level.intValue() < effectiveLevel || effectiveLevel == OFF_INT) && true) { // becomes: if (level.intValue() < effectiveLevel || effectiveLevel == OFF_INT) { // ...which is the original code == just as fast. {code} > Thread local log level overriding > --------------------------------- > > Key: LOGMGR-120 > URL: https://issues.jboss.org/browse/LOGMGR-120 > Project: JBoss Log Manager > Issue Type: Feature Request > Components: core > Affects Versions: 1.5.2.Final > Reporter: Matthew Robson > Assignee: James Perkins > > Having the ability to force logs down to a filter no matter what the log level is set to. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-120) Thread local log level overriding

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-120?page=com.atlassian.jira.plugin... ] James Perkins commented on LOGMGR-120: -------------------------------------- Yeah it was the way the description was worded that threw me off a bit. If we're just trying to bypass the level check on the logger to get further down the chain it might be simpler than checking a log level system property. On the other hand if what we're really after is to tell a specific thread to log at a `DEBUG` level then we need a different approach. I suppose the later is more versatile though. > Thread local log level overriding > --------------------------------- > > Key: LOGMGR-120 > URL: https://issues.jboss.org/browse/LOGMGR-120 > Project: JBoss Log Manager > Issue Type: Feature Request > Components: core > Affects Versions: 1.5.2.Final > Reporter: Matthew Robson > Assignee: James Perkins > > Having the ability to force logs down to a filter no matter what the log level is set to. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-120) Thread local log level overriding

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-120?page=com.atlassian.jira.plugin... ] David Lloyd commented on LOGMGR-120: ------------------------------------ I think it relates to the closed PR which was about adding a thread-local log level which can be set up to override the logger's log level. This would be a special logmanager API that would only be enabled if some system property were set which configured it. > Thread local log level overriding > --------------------------------- > > Key: LOGMGR-120 > URL: https://issues.jboss.org/browse/LOGMGR-120 > Project: JBoss Log Manager > Issue Type: Feature Request > Components: core > Affects Versions: 1.5.2.Final > Reporter: Matthew Robson > Assignee: James Perkins > > Having the ability to force logs down to a filter no matter what the log level is set to. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-120) Thread local log level overriding

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-120?page=com.atlassian.jira.plugin... ] James Perkins commented on LOGMGR-120: -------------------------------------- Is the goal here to pass messages through a filter regardless of the log level? > Thread local log level overriding > --------------------------------- > > Key: LOGMGR-120 > URL: https://issues.jboss.org/browse/LOGMGR-120 > Project: JBoss Log Manager > Issue Type: Feature Request > Components: core > Affects Versions: 1.5.2.Final > Reporter: Matthew Robson > Assignee: James Perkins > > Having the ability to force logs down to a filter no matter what the log level is set to. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1914) S3_PING doesn't work with S3 buckets created in Frankfurt region

by Gleb Leonov (JIRA)

[ https://issues.jboss.org/browse/JGRP-1914?page=com.atlassian.jira.plugin.... ] Gleb Leonov commented on JGRP-1914: ----------------------------------- Bela, no, I use buckets in US-Standart region, it's enough for me just now. As for IAMProfileAuth, it is separate but useful feature. > S3_PING doesn't work with S3 buckets created in Frankfurt region > ----------------------------------------------------------------- > > Key: JGRP-1914 > URL: https://issues.jboss.org/browse/JGRP-1914 > Project: JGroups > Issue Type: Bug > Reporter: Gleb Leonov > Assignee: Bela Ban > Fix For: 3.6.3 > > > I tried to use S3_PING with access and secret key pair. However, I got 400 (Bad Request) error. After some investigation, I found that modern S3 buckets created in Frankfurt needs amazon v4 authentication, which needs hmac-sha256. But now S3_PING supports only hmac-sha1, so I see no way to use S3_PING with buckets in Frankfurt region. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-478) log4j ConsoleAppender won't display messages with per-deployment logging

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-478?page=com.atlassian.jira.plugin... ] James Perkins commented on WFCORE-478: -------------------------------------- Don't use a {{ConsoleAppender}} :D Seriously though I'm not sure as I haven't dug into it yet. If you could explain your use case though maybe we could figure out a workaround. > log4j ConsoleAppender won't display messages with per-deployment logging > ------------------------------------------------------------------------ > > Key: WFCORE-478 > URL: https://issues.jboss.org/browse/WFCORE-478 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > > Add the following log4j.properties file to a deployment and try to log. > {code} > # Root logger option > log4j.rootLogger=INFO, stdout > # Direct log messages to stdout > log4j.appender.stdout=org.apache.log4j.ConsoleAppender > log4j.appender.stdout.Target=System.out > log4j.appender.stdout.layout=org.apache.log4j.PatternLayout > log4j.appender.stdout.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4384) ContextService (JSR236): transactional context always suspended

by Maxim Frolov (JIRA)

[ https://issues.jboss.org/browse/WFLY-4384?page=com.atlassian.jira.plugin.... ] Maxim Frolov commented on WFLY-4384: ------------------------------------ I'm wondering whether it is possible at all in an EJB method to create JSR-236 threads which use the same transaction as creating EJB thread? How can I start/execute "ManagedExecutorService internal thread" within the same EJB transaction? > ContextService (JSR236): transactional context always suspended > --------------------------------------------------------------- > > Key: WFLY-4384 > URL: https://issues.jboss.org/browse/WFLY-4384 > Project: WildFly > Issue Type: Bug > Components: EE > Affects Versions: 8.2.0.Final, 9.0.0.Alpha1 > Reporter: Maxim Frolov > Assignee: Eduardo Martins > Priority: Critical > > According to §3.3.5 of JSR-236 specification: > ??By using an execution property when creating the contextual proxy object, application components can choose to not suspend the transactional context on the thread ...?? > Given the following EJB and Task: > {code:java} > @WebService(serviceName = "Jsr236WebService") > @Stateless > public class Jsr236WebService { > @Inject Jsr236ManagedTask jsr236ManagedTask; > @Resource ManagedExecutorService executor; > @Resource ContextService contextService; > > @WebMethod(operationName = "hello") > public String hello(@WebParam(name = "name") String txt) { > Map<String, String> execProps = new HashMap<>(); > execProps.put(ManagedTask.TRANSACTION, ManagedTask.USE_TRANSACTION_OF_EXECUTION_THREAD); > Future<String> future = executor.submit( > contextService.createContextualProxy(jsr236ManagedTask, execProps, Callable.class)); > try { > return future.get(); > } catch (InterruptedException | ExecutionException e) { > throw new RuntimeException(e); > } > } > } > {code} > {code:java} > @Dependent > @Transactional(Transactional.TxType.MANDATORY) > public class Jsr236ManagedTask implements Callable<String>, ManagedTask { > @Override > public String call() { > return "called"; > } > @Override > public Map<String, String> getExecutionProperties() { > Map<String, String> execProps = new HashMap<>(); > execProps.put(ManagedTask.TRANSACTION, ManagedTask.USE_TRANSACTION_OF_EXECUTION_THREAD); > return execProps; > } > } > {code} > When the {{call()}} Method of the task is called the following exception occurs: > {noformat} > javax.transaction.TransactionalException: ARJUNA016110: Transaction is required for invocation > {noformat} > See maven test project [https://github.com/wrungel/bugs/tree/master/jsr236-test] on GitHub. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4173) Server side EJB Handler not compression response

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4173?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4173: ----------------------------------------------- Jan Martiska <jmartisk(a)redhat.com> changed the Status of [bug 1172856|https://bugzilla.redhat.com/show_bug.cgi?id=1172856] from ON_QA to VERIFIED > Server side EJB Handler not compression response > ------------------------------------------------ > > Key: WFLY-4173 > URL: https://issues.jboss.org/browse/WFLY-4173 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.0.Alpha1 > Reporter: Brad Maxwell > Assignee: Tomas Hofman > > When compression is enabled for request/response, the jboss-ejb-client is sending a compressed request, but the application server is responding with an uncompressed response. > On the server enabling TRACE on org.jboss.as.ejb3, we can see the server receives a compressed request > TRACE [org.jboss.as.ejb3] (default task-5) Got message with header 0x1b on channel Channel ID 56b01772 (inbound) of Remoting connection TRACE [org.jboss.as.ejb3.invocation] (default task-5) Received a compressed message stream > Client side, Enabling TRACE on the client side for org.jboss.ejb.client we see it is 0x5 where it should be 0x1b > TRACE org.jboss.ejb.client.remoting.ChannelAssociation - Received message with header 0x5 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-120) Thread local log level overriding

by Matthew Robson (JIRA)

Matthew Robson created LOGMGR-120: ------------------------------------- Summary: Thread local log level overriding Key: LOGMGR-120 URL: https://issues.jboss.org/browse/LOGMGR-120 Project: JBoss Log Manager Issue Type: Feature Request Components: core Affects Versions: 1.5.2.Final Reporter: Matthew Robson Assignee: James Perkins Having the ability to force logs down to a filter no matter what the log level is set to. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1914) S3_PING doesn't work with S3 buckets created in Frankfurt region

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1914?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1914: -------------------------------- [~hoegertn] Can't say, Gleb wdyt ? Have you checked jgroups-aws (link in my first comment): does it have this feature ? Unfortunately, I'm not an expert in AWS security/auth, so if you want to get this feature in, it is best to write it yourself and submit it via a PR... Note though that we cannot introduce any 3rd party dependencies... > S3_PING doesn't work with S3 buckets created in Frankfurt region > ----------------------------------------------------------------- > > Key: JGRP-1914 > URL: https://issues.jboss.org/browse/JGRP-1914 > Project: JGroups > Issue Type: Bug > Reporter: Gleb Leonov > Assignee: Bela Ban > Fix For: 3.6.3 > > > I tried to use S3_PING with access and secret key pair. However, I got 400 (Bad Request) error. After some investigation, I found that modern S3 buckets created in Frankfurt needs amazon v4 authentication, which needs hmac-sha256. But now S3_PING supports only hmac-sha1, so I see no way to use S3_PING with buckets in Frankfurt region. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2015