March 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3061) Replace deprecated OPTIONAL dependency to MBean server in WS ServerConfigService

by Alessio Soldano (JIRA)

Alessio Soldano created WFLY-3061: ------------------------------------- Summary: Replace deprecated OPTIONAL dependency to MBean server in WS ServerConfigService Key: WFLY-3061 URL: https://issues.jboss.org/browse/WFLY-3061 Project: WildFly Issue Type: Task Security Level: Public (Everyone can see) Components: Web Services Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: 8.0.1.Final {noformat} builder.addDependency(DependencyType.OPTIONAL, MBEAN_SERVER_NAME, MBeanServer.class, serverConfig.getMBeanServerInjector()); {noformat} in org.jboss.as.webservices.service.ServerConfigService needs to be replaced. -- 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

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1804) UDP: sending of multicasts fails after an ifdown / ifup cycle

by Bela Ban (JIRA)

Bela Ban created JGRP-1804: ------------------------------ Summary: UDP: sending of multicasts fails after an ifdown / ifup cycle Key: JGRP-1804 URL: https://issues.jboss.org/browse/JGRP-1804 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.5 After an ifdown / if up cycle, sending of multicast messages over mcast_sock fails with an IOException (no such device). Sending unicast datagram packets works. SOLUTION: Catch the IOException on the send and set the interface again ({{MulticastSocket.setInterface()}}). This was confirmed to work. -- 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

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1804) UDP: sending of multicasts fails after an ifdown / ifup cycle

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1804?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1804: --------------------------- Forum Reference: https://sourceforge.net/p/javagroups/mailman/message/32034144/ (was: https://sourceforge.net/p/javagroups/mailman/message/32058114/) > UDP: sending of multicasts fails after an ifdown / ifup cycle > ------------------------------------------------------------- > > Key: JGRP-1804 > URL: https://issues.jboss.org/browse/JGRP-1804 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5 > > > After an ifdown / if up cycle, sending of multicast messages over mcast_sock fails with an IOException (no such device). Sending unicast datagram packets works. > SOLUTION: > Catch the IOException on the send and set the interface again ({{MulticastSocket.setInterface()}}). This was confirmed to work. -- 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

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1917) Support socket-binding attribute "client-mapping" in messaging subsystem

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-1917?page=com.atlassian.jira.plugin.... ] Jeff Mesnil resolved WFLY-1917. ------------------------------- Resolution: Rejected Preferred way to configure the messaging remote-connector is using outbound-socket-binding that allows to define the address that the client must use to connect to the server. > Support socket-binding attribute "client-mapping" in messaging subsystem > ------------------------------------------------------------------------ > > Key: WFLY-1917 > URL: https://issues.jboss.org/browse/WFLY-1917 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: JMS > Affects Versions: 8.0.0.Alpha4 > Reporter: Justin Bertram > Assignee: Jeff Mesnil > > The messaging subsystem doesn't take into account the "client-mapping" attribute of the <socket-binding> when creating a <netty-connector>. This forces the user to manually configure a <connector> to support the desired behavior. -- 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

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-441) drools-guvnor 5.5, declarative model, create more than one fact type, BPMN process does not load

by niraj gupta (JIRA)

[ https://issues.jboss.org/browse/DROOLS-441?page=com.atlassian.jira.plugin... ] niraj gupta commented on DROOLS-441: ------------------------------------ Thanks for update and appreciate your suggestions. I also have the same doubt that rebuilding/reloading of the package having some problem. But i am not getting exact location of the code for the fix. I tried the steps you suggested. I created 1st package like pkg1, then only one process proc1 and then build deploy. Now i created another 2nd package like pkg2, then only one declarative model like 1. | declare Mod1 2. | mid: Integer 3. | mname: String 4. | end 5. | 6. | declare Mod2 7. | bid: Integer 8. | end and save this model. but not build. now running the process execute perfectly, even modify multiple time the same process. But as soon as build the pkg2, and then update the process, it doesn't reflect new changes in the console. I am not seeing any exception, as you are telling 2nd build failure case. Also if you could help me to which build is having this fix, it would be great. Actually this fix is very important to us. Regards, Niraj > drools-guvnor 5.5, declarative model, create more than one fact type, BPMN process does not load > ------------------------------------------------------------------------------------------------ > > Key: DROOLS-441 > URL: https://issues.jboss.org/browse/DROOLS-441 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final > Environment: Tomcat 6.0.35, jBPM 5.5.Final > Reporter: niraj gupta > Assignee: Mark Proctor > Labels: drools-guvnor > > I am using ‘drools-guvnor 5.5.0.Final’ open source tool for designing the business process (BPMN2). I end up in an issue and looking for help. Following is the scenario > I created a package then process then after build, deploy execute successfully. Now I came back to guvnor and made few changes in the process. Then after same build, deploy execute successfully. But now this time I am creating a declarative model having 2 facts, also modifying business process. Then after same build, deploy execute successfully. This time modified/latest business process doesn’t load into console. This is my problem. However I trouble shoot and google following are my observations: > • I am running this application in tomcat 6.0.35 > • It works perfectly with POJO Model Jar approach. > • It works perfectly with declarative model but having single fact. > • I am not seeing any exceptions either in UI or console logs -- 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

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1156) add ability to configure local address and port on messaging subsystems connectors

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-1156?page=com.atlassian.jira.plugin.... ] Jeff Mesnil updated WFLY-1156: ------------------------------ Affects Version/s: 8.0.0.Final > add ability to configure local address and port on messaging subsystems connectors > ---------------------------------------------------------------------------------- > > Key: WFLY-1156 > URL: https://issues.jboss.org/browse/WFLY-1156 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JMS > Affects Versions: 8.0.0.Final > Reporter: Andy Taylor > Assignee: Jeff Mesnil > -- 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

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1156) add ability to configure local address and port on messaging subsystems connectors

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-1156?page=com.atlassian.jira.plugin.... ] Jeff Mesnil updated WFLY-1156: ------------------------------ Fix Version/s: 8.0.1.Final > add ability to configure local address and port on messaging subsystems connectors > ---------------------------------------------------------------------------------- > > Key: WFLY-1156 > URL: https://issues.jboss.org/browse/WFLY-1156 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JMS > Affects Versions: 8.0.0.Final > Reporter: Andy Taylor > Assignee: Jeff Mesnil > Fix For: 8.0.1.Final > > -- 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

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1722) Improve performance of ENCRYPT protocol

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1722?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1722: -------------------------------- I tried the following: # Decryption of the messages of a batch in parallel, using a thread pool. If the decryption cost of a message (assuming similar-sized messages) is 2ms, then decrypting a batch of 10 messages would take 20ms if done sequentially, while it would take ~2ms if done in parallel. Of course, we're assuming here that we have 10 threads available and the cost of context switching is negligible # Use of the asynchronous invocation API to dispatch requests. Every request is handled by a thread from a thread pool (in UPerf) and sending the response as well. The response sending includes encryption of the response, so this cost is amortized by doing this in parallel I tested performance on my local box, my (fast) mac and the lab cluster (8 UPerf instances), and it wasn't better than the sequential algorithm. Possible causes: only half of the messages are actually message batches, the average batch size is small (I verified that they avg is ~ 3.5), and the additional thread context switching caused by the pools diminishes the returns gained by parallelization > Improve performance of ENCRYPT protocol > --------------------------------------- > > Key: JGRP-1722 > URL: https://issues.jboss.org/browse/JGRP-1722 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.4 > Reporter: Martin Gencur > Assignee: Bela Ban > Fix For: 3.5 > > > A stress tests with the following setup showed that performance (reads and writes/sec) is halved when ENCRYPT protocol is enabled: > Infinispan had distributed sync cache with 2 owners on 4 nodes, no transactions. The stress test used 10 threads on each node accessing 1024 byte entries, no conflicts on keys, 20 % writes, 80 % reads. > It would be great if we could improve the performance of ENCRYPT protocol. -- 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

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-797) Authentication attempts will fail if the DatabaseRolesMappingProvider's rolesQuery returns an empty set

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-797?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-797: -------------------------------------------------- Ondrej Lukas <olukas(a)redhat.com> changed the Status of [bug 1067612|https://bugzilla.redhat.com/show_bug.cgi?id=1067612] from ON_QA to VERIFIED > Authentication attempts will fail if the DatabaseRolesMappingProvider's rolesQuery returns an empty set > ------------------------------------------------------------------------------------------------------- > > Key: SECURITY-797 > URL: https://issues.jboss.org/browse/SECURITY-797 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JBossSX > Affects Versions: PicketBox_4_0_19.Final > Reporter: Derek Horton > Assignee: Stefan Guilhen > Attachments: SECURITY-797.patch > > > If the DatabaseRolesMappingProvider's rolesQuery returns an empty set, then the authentication attempts will fail. Seems like it should not cause the authentication attempt to fail, since this is about mapping/adding roles. > It looks like the code detects that the result set is empty, but then it tries to get the role from the empty set. This causes an exception which in turn causes the authentication attempt to fail. -- 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

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1722) Improve performance of ENCRYPT protocol

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1722?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1722 at 3/4/14 9:23 AM: -------------------------------------------------------- Cipher pooling doesn't help: all messages of a batch are decrypted sequentially (using the same cipher though), replaced with the decrypted message, and then the batch is passed up. Parallel decryption of the messages in a batch would probably help here, e.g. using the fork-join framework. was (Author: belaban): Parallelization doesn't help with message batches: all messages of a batch are decrypted sequentially (using the same cipher though), replaced with the decrypted message, and then the batch is passed up. Parallel decryption of the messages in a batch would probably help here, e.g. using the fork-join framework. > Improve performance of ENCRYPT protocol > --------------------------------------- > > Key: JGRP-1722 > URL: https://issues.jboss.org/browse/JGRP-1722 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.4 > Reporter: Martin Gencur > Assignee: Bela Ban > Fix For: 3.5 > > > A stress tests with the following setup showed that performance (reads and writes/sec) is halved when ENCRYPT protocol is enabled: > Infinispan had distributed sync cache with 2 owners on 4 nodes, no transactions. The stress test used 10 threads on each node accessing 1024 byte entries, no conflicts on keys, 20 % writes, 80 % reads. > It would be great if we could improve the performance of ENCRYPT protocol. -- 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

11 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2014