[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)
11 years, 4 months
[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)
11 years, 4 months
[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)
11 years, 4 months
[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)
11 years, 4 months
[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)
11 years, 4 months
[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)
11 years, 4 months
[JBoss JIRA] (JGRP-1910) MERGE3: Do not lose any members from view during a series of merges
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1910?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1910:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1189839|https://bugzilla.redhat.com/show_bug.cgi?id=1189839] from NEW to POST
> MERGE3: Do not lose any members from view during a series of merges
> -------------------------------------------------------------------
>
> Key: JGRP-1910
> URL: https://issues.jboss.org/browse/JGRP-1910
> Project: JGroups
> Issue Type: Bug
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.6.3
>
> Attachments: SplitMergeTest.java
>
>
> When connection between nodes is re-established, MERGE3 should merge the cluster together. This often does not involve a single MergeView but a series of such events. The problematic property of this protocol is that some of those views can lack certain members, though these are reachable.
> This causes problem in Infinispan since the cache cannot be fully rebalanced before another merge arrives, and all owners of certain segment can be gradually removed (and added again) to the view, while this is not detected as partition but crashed nodes -> losing all owners means data loss.
> Removing members from view should be the role of FDx protocols, not MERGEx.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4385) Authentication is not propagated to EJB in the login request
by Paulo Cesar Silva Reis (JIRA)
[ https://issues.jboss.org/browse/WFLY-4385?page=com.atlassian.jira.plugin.... ]
Paulo Cesar Silva Reis commented on WFLY-4385:
----------------------------------------------
Hi Darran,
Did you have time to check it out?
Thanks.
> Authentication is not propagated to EJB in the login request
> ------------------------------------------------------------
>
> Key: WFLY-4385
> URL: https://issues.jboss.org/browse/WFLY-4385
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.2.0.Final
> Environment: MAC OSX YOSEMITE
> JAVA ORACLE 1.8
> WILDFLY 8.2.0.FINAL STANDALONE
> Reporter: Paulo Cesar Silva Reis
> Assignee: Darran Lofthouse
> Labels: authentication, ejb, http, login, roles, web
> Attachments: wildfly-4385.zip
>
>
> I'm migrating from glassfish to wildfly and noticed few weird things.
> When you perform login through web container (request.login(user, pwd)), the principal is not propagated to EJB Container, only for web container.
> To test that, this is what I did:
> . BASIC AUTH
> . EJB receives HttpServletRequest with user data and perform login
> . Print request.getUserPrincipal() => ok, logged in
> . Print EJBContext.getCallerPrincipal() => anonymous
> This happens in the same request that user logged in. In the subsequent requests (using Set-Cookie response and cookie with JSESSIONID in request), the EJB is aware of the authentication.
> Is that the right behavior? 'Cause in glassfish is different, the principal is propagated immediately to EJB.
> Thanks in advance.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFCORE-563) Upgrade to Xerces 2.11.0.SP3
by Carlo de Wolf (JIRA)
[ https://issues.jboss.org/browse/WFCORE-563?page=com.atlassian.jira.plugin... ]
Carlo de Wolf updated WFCORE-563:
---------------------------------
Summary: Upgrade to Xerces 2.11.0.SP3 (was: Upgrade to Xerces 2.11.0.SP1)
> Upgrade to Xerces 2.11.0.SP3
> ----------------------------
>
> Key: WFCORE-563
> URL: https://issues.jboss.org/browse/WFCORE-563
> Project: WildFly Core
> Issue Type: Component Upgrade
> Affects Versions: 1.0.0.Alpha19
> Environment: WildFly 8.1.0.Final, JDK 7, Ubuntu, Windows, Mac OS
> Reporter: Carlos Barragan
> Assignee: Carlo de Wolf
> Priority: Critical
> Fix For: 1.0.0.Beta1
>
> Attachments: stacktrace.txt
>
>
> Xerces 2.9.1 has a bug when parsing Times with "24" hrs.
> {code}
> DatatypeFactory.newInstance().newXMLGregorianCalendar("24:00:00Z");
> {code}
> We have this problem in one of our web services because we get request with the above time format.
> Xerces 2.11.0 does not contain that bug.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4397) WildFly.8.1.0.Final's Asynchronous servlets cause connection leak
by Wind Wild (JIRA)
[ https://issues.jboss.org/browse/WFLY-4397?page=com.atlassian.jira.plugin.... ]
Wind Wild commented on WFLY-4397:
---------------------------------
Hi,Tomaz Cerar
I test it on wildfly.8.2,the same problem.
> WildFly.8.1.0.Final's Asynchronous servlets cause connection leak
> -----------------------------------------------------------------
>
> Key: WFLY-4397
> URL: https://issues.jboss.org/browse/WFLY-4397
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final, 8.2.0.Final, 9.0.0.Alpha1
> Environment: Java(TM) SE Runtime Environment (build 1.7.0_25)
> Reporter: Wind Wild
> Assignee: Stuart Douglas
>
> Recently, I used Asynchronous servlets and AsyncListeners on my project.But when it runs on WildFly.8.1.0.Final,a problem appeared as following:
>
> 2015-01-10 10:08:40,936 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 2) JBAS015004: Caught exception writing deployment marker file /opt/jboss/standalone/deployments/OpenESBHttp_full_prd.war.isundeploying: java.io.FileNotFoundException: /opt/jboss/standalone/deployments/OpenESBHttp_full_prd.war.isundeploying (Too many open files)
> at java.io.FileOutputStream.open(Native Method) [rt.jar:1.7.0_25]
> at java.io.FileOutputStream.<init>(FileOutputStream.java:212) [rt.jar:1.7.0_25]
> at java.io.FileOutputStream.<init>(FileOutputStream.java:165) [rt.jar:1.7.0_25]
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.createMarkerFile(FileSystemDeploymentService.java:984) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.access$2800(FileSystemDeploymentService.java:83) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScannerTask.recordInProgress(FileSystemDeploymentService.java:1044) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:431) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$DeploymentScanRunnable.run(FileSystemDeploymentService.java:147) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25]
> at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) [rt.jar:1.7.0_25]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) [rt.jar:1.7.0_25]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_25]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
>
> 2015-01-10 10:08:41,329 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) JBAS017535: Unregistered web context: /ServiceWeb
> 2015-01-10 10:08:41,481 INFO [net.sf.json.xml.XMLSerializer] (HttpServiceHandler-50543) Using default type string
> 2015-01-10 10:08:42,225 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-3)
> 2015-01-10 10:08:43,504 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment OpenESBHttp_full_prd.war (runtime-name: OpenESBHttp_full_prd.war) in 2373ms
>
> From this server log,we can see that there is "Too open many files" problem.and on the WildFly‘s manager console,we can see that my project was undeployed.When i used command "lsof -p pid | wc -l" to find the count of open file-hander, 50000 open file,because there were a lot of "can't identify protocol" as following:
> java 25625 jbossuser 460u sock 0,6 0t0 62184686 can't identify protocol
> java 25625 jbossuser 461u sock 0,6 0t0 62170175 can't identify protocol
> java 25625 jbossuser 462u sock 0,6 0t0 62159509 can't identify protocol
> java 25625 jbossuser 463u sock 0,6 0t0 62193366 can't identify protocol
> java 25625 jbossuser 464u sock 0,6 0t0 62181816 can't identify protocol
> java 25625 jbossuser 465u sock 0,6 0t0 62159028 can't identify protocol
> java 25625 jbossuser 466u sock 0,6 0t0 62181150 can't identify protocol
> java 25625 jbossuser 467u sock 0,6 0t0 62165298 can't identify protocol
> java 25625 jbossuser 468u sock 0,6 0t0 62181859 can't identify protocol
> java 25625 jbossuser 469u sock 0,6 0t0 62155350 can't identify protocol
> java 25625 jbossuser 470u sock 0,6 0t0 62184687 can't identify protocol
> java 25625 jbossuser 471u sock 0,6 0t0 62150063 can't identify protocol
> java 25625 jbossuser 472u IPv4 70228479 0t0 TCP lesbprdapp16:webcache->192.168.53.177:23420 (ESTABLISHED)
>
> So i know there maybe occur connection leak on WildFly, and i made a test as follow:
> I use apache's jmeter to test this project,i use 50 users to request it,then use "lsof -p pid | can't identify protocol | wc -l" to find is there have “can't identify protocol”,the number is 0.But when i stop the request,there appeared lots of "can't identify protocol",the same phenomenon appeared on wildfly-9.0.0.Alpha1 and wildfly-8.2.0.Final but not appeared on tomcat.So i'm doubt that this is wildfly's bug,Is there anyony encounter this problem and tell me how to solve it.
>
> Moreover, i found a issue is like above problem:
> [WFLY-3652] Network connection leak - JBoss Issue Tracker
>
> but don't think they are the same probem,because it say the problem alrendy was fixed in wildfly-9.0.0.Alpha1,but above problem wasn't fixed when i test my project on wildfly-9.0.0.Alpha1.
>
> Who can help me solve this problem? thanks!
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months