January 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6317) Uploaded File Replication in cluster

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/AS7-6317?page=com.atlassian.jira.plugin.s... ] Paul Ferraro resolved AS7-6317. ------------------------------- Resolution: Rejected A replicated directory is the wrong solution. File systems do not have ACID characteristics - rather a database or datagrid is the appropriate solution. The whole point of a grid filesystem is to extend the available memory space to the collective heap of an entire cluster. The grid would run on a separate and much larger set of nodes - not the JBoss AS nodes themselves. If you don't need the performance of a data grid, then a database is more appropriate. If storing the large blobs in a replicated database results in too much network traffic - using any kind of replication would seem to be equally bad. Rather, consider storing the blobs in a dedicated database, using something as simple like HA-JDBC for high-availability. > Uploaded File Replication in cluster > ------------------------------------ > > Key: AS7-6317 > URL: https://issues.jboss.org/browse/AS7-6317 > Project: Application Server 7 > Issue Type: Feature Request > Components: Clustering > Affects Versions: 7.0.2.Final > Environment: jboss-as-web-7.0.2.Final , Linux , Postgresql , Mod_cluster as Load balancer > Reporter: hitesh yadav > Assignee: Paul Ferraro > Labels: jboss, synced > > We are using jboss-as-web-7.0.2.Final with Linux , Postgresql , Mod_cluster as Load balancer . > Our goal is to achieve 2 or 3 Node in cluster. > Using jboss-as-web-7.0.2.Final we get HttpSession replication + Cache Replication. > We want same thing for Uploaded file replication. > Meas when we upload image file or some other file in cluster it must have to replicate to all node in cluster . > we d'nt want to store file in database b'coz of large size and we r using database replication so it take lots of Network traffic. > We have look GridFilesystem but it store file in memory which is not acceptable due to size of Heap . > We want some solution from JBOSS side that one or more directory in cluster sync with each other .....so that any file uploaded in this Direcory all Node in Cluster get same File. > In case, Node which handle client request crash then other Node must have knowledge to handle request related with Uploaded File on previous Node. -- 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

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-6328) SingletonService fails with NullPointerException when bound to 0.0.0.0

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/AS7-6328?page=com.atlassian.jira.plugin.s... ] Paul Ferraro resolved AS7-6328. ------------------------------- Resolution: Out of Date Tested against master and could not reproduce. There have been several fixes to SingletonService since 7.1.2.Final. Setting status to out-of-date, since there will be no more releases against the 7.1 branch. > SingletonService fails with NullPointerException when bound to 0.0.0.0 > ----------------------------------------------------------------------- > > Key: AS7-6328 > URL: https://issues.jboss.org/browse/AS7-6328 > Project: Application Server 7 > Issue Type: Bug > Components: Clustering > Affects Versions: 7.1.2.Final (EAP) > Environment: OS independent, reproduces on Ubuntu 12.10 and Windows XP. > Reporter: Patrik Varga > Assignee: Paul Ferraro > Priority: Critical > > Assume that you have working deployment with a custom MSC service wrapped into a SingletonService. When you are trying to access the value of the SingletonService, the SingletonService.getValue() call fails with NullPointerException iff the JBoss instance is listening on all interfaces, i.e. it is bound to 0.0.0.0 by using <inet-address value="0.0.0.0"/> or <any-address/> under <interface name="public"> in standalone-full-ha.xml. > It works when specifying an explicit IP. > Example: try the cluster-ha-singleton jboss-as-quickstart > Top of the stack trace: > java.lang.NullPointerException > at org.jboss.as.clustering.singleton.SingletonService.getValue(SingletonService.java:176) > at org.jboss.as.clustering.singleton.SingletonService.getValue(SingletonService.java:53) > at org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1203) > [...] -- 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

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-6354) Fix java.endorsed.dirs settings in launch scripts

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/AS7-6354?page=com.atlassian.jira.plugin.s... ] David Lloyd commented on AS7-6354: ---------------------------------- I'd say the proper fix is, get rid of this. There's no reason to use endorsed for anything; it just ruins embedding in yet another way. We can/should add the right hooks to JBoss Modules to replace this API if that is the problem (similar to how we replace JAXP). > Fix java.endorsed.dirs settings in launch scripts > ------------------------------------------------- > > Key: AS7-6354 > URL: https://issues.jboss.org/browse/AS7-6354 > Project: Application Server 7 > Issue Type: Sub-task > Components: Scripts > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 7.2.0.Alpha1 > > > A detail of the parent task. The ws***.bat and .sh scripts include this: > "-Djava.endorsed.dirs=%JBOSS_HOME%/modules/com/sun/xml/bind/main;%JBOSS_HOME%/modules/javax/xml/ws/api/main" ^ > Those paths need to be fixed to include layers/base. -- 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

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-4931) configuration history length and the number of days they are kept is hardcoded - this needs to be configurable

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/AS7-4931?page=com.atlassian.jira.plugin.s... ] Ivo Studensky commented on AS7-4931: ------------------------------------ That is exactly why I mentioned the system properties as I am not sure it is worth such a big change. Thanks, Brian! I will look into this. > configuration history length and the number of days they are kept is hardcoded - this needs to be configurable > -------------------------------------------------------------------------------------------------------------- > > Key: AS7-4931 > URL: https://issues.jboss.org/browse/AS7-4931 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management > Affects Versions: 7.1.2.Final (EAP) > Reporter: Tom Fonteyne > Priority: Minor > > Currently 100 configuration settings are kept for 30 days. These settings are hard-coded in > org/ jboss/ as/ controller/ persistence/ ConfigurationFile.java > 057 private static final int CURRENT_HISTORY_LENGTH = 100; > 058 private static final int HISTORY_DAYS = 30; > As per PM: this is a bug/gap in the original requirements -- 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

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-4931) configuration history length and the number of days they are kept is hardcoded - this needs to be configurable

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/AS7-4931?page=com.atlassian.jira.plugin.s... ] Ivo Studensky reassigned AS7-4931: ---------------------------------- Assignee: Ivo Studensky > configuration history length and the number of days they are kept is hardcoded - this needs to be configurable > -------------------------------------------------------------------------------------------------------------- > > Key: AS7-4931 > URL: https://issues.jboss.org/browse/AS7-4931 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management > Affects Versions: 7.1.2.Final (EAP) > Reporter: Tom Fonteyne > Assignee: Ivo Studensky > Priority: Minor > > Currently 100 configuration settings are kept for 30 days. These settings are hard-coded in > org/ jboss/ as/ controller/ persistence/ ConfigurationFile.java > 057 private static final int CURRENT_HISTORY_LENGTH = 100; > 058 private static final int HISTORY_DAYS = 30; > As per PM: this is a bug/gap in the original requirements -- 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

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-4931) configuration history length and the number of days they are kept is hardcoded - this needs to be configurable

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-4931?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on AS7-4931: --------------------------------------- I'm ok with system properties. If there is demand for it we can look into exposing it directly in the xml. It creates something of a new category of config item in the xml though, so I'm not eager to do that unless there's demand. > configuration history length and the number of days they are kept is hardcoded - this needs to be configurable > -------------------------------------------------------------------------------------------------------------- > > Key: AS7-4931 > URL: https://issues.jboss.org/browse/AS7-4931 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management > Affects Versions: 7.1.2.Final (EAP) > Reporter: Tom Fonteyne > Priority: Minor > > Currently 100 configuration settings are kept for 30 days. These settings are hard-coded in > org/ jboss/ as/ controller/ persistence/ ConfigurationFile.java > 057 private static final int CURRENT_HISTORY_LENGTH = 100; > 058 private static final int HISTORY_DAYS = 30; > As per PM: this is a bug/gap in the original requirements -- 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

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-4931) configuration history length and the number of days they are kept is hardcoded - this needs to be configurable

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/AS7-4931?page=com.atlassian.jira.plugin.s... ] Ivo Studensky commented on AS7-4931: ------------------------------------ Which way these should be configurable? I believe that AS7 system properties [1] could be sufficient for it. I've checked that system properties are nicely populated before invoking of createHistoryDirectory() or backup() methods of ConfigurationFile class, at least in the standalone mode. It would only need a slight change in the backup method to remove all out-dated backups instead of the last one only. [1] https://community.jboss.org/wiki/JBossAS7SystemProperties > configuration history length and the number of days they are kept is hardcoded - this needs to be configurable > -------------------------------------------------------------------------------------------------------------- > > Key: AS7-4931 > URL: https://issues.jboss.org/browse/AS7-4931 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management > Affects Versions: 7.1.2.Final (EAP) > Reporter: Tom Fonteyne > Priority: Minor > > Currently 100 configuration settings are kept for 30 days. These settings are hard-coded in > org/ jboss/ as/ controller/ persistence/ ConfigurationFile.java > 057 private static final int CURRENT_HISTORY_LENGTH = 100; > 058 private static final int HISTORY_DAYS = 30; > As per PM: this is a bug/gap in the original requirements -- 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

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-6354) Fix java.endorsed.dirs settings in launch scripts

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-6354: ------------------------------------- Summary: Fix java.endorsed.dirs settings in launch scripts Key: AS7-6354 URL: https://issues.jboss.org/browse/AS7-6354 Project: Application Server 7 Issue Type: Sub-task Components: Scripts Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 7.2.0.Alpha1 A detail of the parent task. The ws***.bat and .sh scripts include this: "-Djava.endorsed.dirs=%JBOSS_HOME%/modules/com/sun/xml/bind/main;%JBOSS_HOME%/modules/javax/xml/ws/api/main" ^ Those paths need to be fixed to include layers/base. -- 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

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBRULES-3718) java.lang.NullPointerException at org.mvel2.ast.IntSub.getReducedValueAccelerated

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/JBRULES-3718?page=com.atlassian.jira.plug... ] Mario Fusco commented on JBRULES-3718: -------------------------------------- OK, you can send it at mfusco[at]redhat.com. Thanks. > java.lang.NullPointerException at org.mvel2.ast.IntSub.getReducedValueAccelerated > --------------------------------------------------------------------------------- > > Key: JBRULES-3718 > URL: https://issues.jboss.org/browse/JBRULES-3718 > Project: JBRULES > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: drools-core > Affects Versions: 5.5.0.Final > Environment: Windows 7 64bit - Java 1.7.0 > Drools-planner 5.5.0.Final > -> Drools-core 5.5.0.Final > -> mvel2 2.1.3.Final > Reporter: Michiel Vermandel > Assignee: Mario Fusco > > When I run my planning I get now and then the stacktrace as mentioned below. > It happens about 1 in 5 times during running a JUnit test on small amount of planning entities and problem facts. > It started after adding my last rule: > rule "tasksInSameCommunityMustBeChained" > when > $lead : Task(this==lead, period!=null, communityId!= null, $communityId : communityId) > not ( Task(this==lead, communityId == $communityId, id != $lead.id, ($lead.startPeriodId-1) <= endPeriodId && ($lead.endPeriodId+1) >= startPeriodId ) ) > then > insertLogical(new IntConstraintOccurrence("tasksInSameCommunityMustBeChained", ConstraintType.NEGATIVE_HARD, Importance.chainedPeriod, $communityId, $lead, $lead.getStartPeriodId())); > end > Stack trace: > Exception in thread "Thread-1" java.lang.NullPointerException > at org.mvel2.ast.IntSub.getReducedValueAccelerated(IntSub.java:17) > at org.mvel2.compiler.ExecutableAccessor.getValue(ExecutableAccessor.java:38) > at org.mvel2.ast.Substatement.getReducedValueAccelerated(Substatement.java:44) > at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:108) > at org.mvel2.ast.And.getReducedValueAccelerated(And.java:34) > at org.mvel2.MVELRuntime.execute(MVELRuntime.java:85) > at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123) > at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119) > at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:113) > at org.mvel2.MVEL.executeExpression(MVEL.java:930) > at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:70) > at org.drools.rule.constraint.MvelConditionEvaluator.ensureBranchEvaluation(MvelConditionEvaluator.java:117) > at org.drools.rule.constraint.MvelConditionEvaluator.ensureCompleteEvaluation(MvelConditionEvaluator.java:102) > at org.drools.rule.constraint.MvelConditionEvaluator.ensureCompleteEvaluation(MvelConditionEvaluator.java:90) > at org.drools.rule.constraint.MvelConditionEvaluator.getAnalyzedCondition(MvelConditionEvaluator.java:82) > at org.drools.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:270) > at org.drools.rule.constraint.MvelConstraint.access$200(MvelConstraint.java:51) > at org.drools.rule.constraint.MvelConstraint$ConditionJitter.run(MvelConstraint.java:250) > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) > at java.lang.Thread.run(Unknown Source) -- 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

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-968) Expose InUse pool statistics

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-968?page=com.atlassian.jira.plugin.... ] Jesper Pedersen resolved JBJCA-968. ----------------------------------- Resolution: Done > Expose InUse pool statistics > ---------------------------- > > Key: JBJCA-968 > URL: https://issues.jboss.org/browse/JBJCA-968 > Project: IronJacamar > Issue Type: Task > Components: Core > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.0.15.Final, 1.1.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

13 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2013