[JBoss JIRA] Created: (JBRULES-2700) Allow setting globals for access by the scoring rules
by Wouter Horré (JIRA)
Allow setting globals for access by the scoring rules
-----------------------------------------------------
Key: JBRULES-2700
URL: https://jira.jboss.org/browse/JBRULES-2700
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-planner
Reporter: Wouter Horré
Assignee: Mark Proctor
Currently, it is not possible to set a global variable in the working memory used by the solver. If a scoring rule needs an external helper for calculating scores (e.g. a dependency injected with OSGi DS), a workaround using a static variable in some class accessible by the scoring rules is needed.
The easiest implementation is probably a new method in the Solver interface:
public WorkingMemory getWorkingMemory();
which provides access to the working memory used by the solver.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (AS7-1371) Domain Management - Support for database connection pool in non AS process.
by Darran Lofthouse (JIRA)
Domain Management - Support for database connection pool in non AS process.
---------------------------------------------------------------------------
Key: AS7-1371
URL: https://issues.jboss.org/browse/AS7-1371
Project: Application Server 7
Issue Type: Task
Components: Domain Management
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 7.1.0.Beta1
We need to support authentication for users stored in database, the domain management is in a non-AS process so we also need a pool of database connections.
These connections will be used to read only from the database, other than the isolation offered by the driver we should not require any advanced transaction support.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] Created: (AS7-1370) Domain Management - Add support for database authentication.
by Darran Lofthouse (JIRA)
Domain Management - Add support for database authentication.
------------------------------------------------------------
Key: AS7-1370
URL: https://issues.jboss.org/browse/AS7-1370
Project: Application Server 7
Issue Type: Task
Components: Domain Management, Security
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 7.1.0.Beta1
It should be possible to define a database authentication element for authentication of incoming connections against a database.
Ideally the password should be obtainable from the database to allow us to use DIGEST authentication but if not a fallback to verify the password should be supported.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] Created: (AS7-1294) Don't inject into static fields/methods
by jaikiran pai (JIRA)
Don't inject into static fields/methods
---------------------------------------
Key: AS7-1294
URL: https://issues.jboss.org/browse/AS7-1294
Project: Application Server 7
Issue Type: Bug
Components: EE
Affects Versions: 7.0.0.Final
Reporter: jaikiran pai
Assignee: David Lloyd
The Java EE6 spec, section EE.5.2.5 says:
{quote}
The field or method may have any access qualifier (public, private, etc.). For all classes except application client
main classes, the fields or methods must not be static.
{quote}
Currently we even inject even into static fields/methods.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] Created: (JGRP-364) When using TCP_NIO, starting two nodes at the same time causes one of the nodes not to join group
by Matthew Todd (JIRA)
When using TCP_NIO, starting two nodes at the same time causes one of the nodes not to join group
-------------------------------------------------------------------------------------------------
Key: JGRP-364
URL: http://jira.jboss.com/jira/browse/JGRP-364
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4
Environment: linux 2.6 kernel x86_64 running java 1.5.0_06
Reporter: Matthew Todd
Assigned To: Bela Ban
I am testing a jgroups tcp_nio configuration using the draw demo.If I start up my 3 nodes one by one then everything works fine. However if I start up node 1, then attempt to start node 2 and 3 in parallel then only node 2 will work. Node 3 will be isolated and not see the other nodes and logs the following message:
org.jgroups.protocols.pbcast.ClientGmsImpl join
WARNING: join(192.158.70.200:7802) sent to 192.158.70.200:7800 timed out, retrying
I am starting the draw demo like this;
java -cp jgroups-all.jar:commons-logging.jar:concurrent.jar:jmxri.jar org.jgroups.demos.Draw -props test.xml
Here is the configuration for one of my nodes:
<config>
<TCP_NIO
bind_addr="192.158.70.200"
recv_buf_size="20000000"
send_buf_size="640000"
loopback="false"
discard_incompatible_packets="true"
max_bundle_size="64000"
max_bundle_timeout="30"
use_incoming_packet_handler="true"
use_outgoing_packet_handler="true"
down_thread="false" up_thread="false"
enable_bundling="true"
start_port="7800"
end_port="7800"
use_send_queues="false"
sock_conn_timeout="300" skip_suspected_members="true"
/>
<MPING timeout="2000" num_initial_members="3" mcast_addr="229.6.7.8"
bind_addr="192.158.70.200" down_thread="false" up_thread="false"/>
<MERGE2 max_interval="100000"
down_thread="false" up_thread="false" min_interval="20000"/>
<FD_SOCK down_thread="false" up_thread="false"/>
<VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false"/>
<pbcast.NAKACK max_xmit_size="60000"
use_mcast_xmit="false" gc_lag="0"
retransmit_timeout="300,600,1200,2400,4800"
down_thread="true" up_thread="true"
discard_delivered_msgs="true"/>
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
down_thread="false" up_thread="false"
max_bytes="400000"/>
<pbcast.GMS print_local_addr="true" join_timeout="3000"
down_thread="true" up_thread="true"
join_retry_timeout="2000" shun="true"
view_bundling="true"/>
<!-- <FC max_credits="2000000" down_thread="false" up_thread="false"
min_threshold="0.10"/>
<FRAG2 frag_size="60000" down_thread="false" up_thread="false"/> -->
<pbcast.STATE_TRANSFER/>
<!-- <pbcast.FLUSH down_thread="false" up_thread="false"/>-->
</config>
Node 2 and 3 have the same configuration except the port they bind to has been changed
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] Created: (JGRP-356) TCP_NIO: failure starting correctly with bundling enabled
by Bela Ban (JIRA)
TCP_NIO: failure starting correctly with bundling enabled
---------------------------------------------------------
Key: JGRP-356
URL: http://jira.jboss.com/jira/browse/JGRP-356
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4
Reporter: Bela Ban
Assigned To: Vladimir Blagojevic
Fix For: 2.5
Stack is (default tcp-nio.xml with bundling enabled), the error is:
$ jg Draw -props ./tcp-nio.xml
-------------------------------------------------------
GMS: address is 127.0.0.1:7800
-------------------------------------------------------
** View=[127.0.0.1:7800|0] [127.0.0.1:7800]
0 [WARN] [TimeScheduler.Thread] TimeScheduler._run(): task org.jgroups.protocols.TP$Bundler$BundlingTimer@1c65216 took 20921ms to execute, please check why it is taking so long. It is delaying other tasks
<config>
<TCP_NIO
recv_buf_size="20000000"
send_buf_size="640000"
loopback="false"
discard_incompatible_packets="true"
max_bundle_size="64000"
max_bundle_timeout="30"
use_incoming_packet_handler="true"
use_outgoing_packet_handler="false"
down_thread="false" up_thread="false"
enable_bundling="true"
start_port="7800"
use_send_queues="false"
sock_conn_timeout="300" skip_suspected_members="true"
reader_threads="8"
writer_threads="8"
processor_threads="8"
processor_minThreads="8"
processor_maxThreads="8"
processor_queueSize="100"
processor_keepAliveTime="-1"/>
<TCPPING timeout="3000"
down_thread="false" up_thread="false"
initial_hosts="${jgroups.tcpping.initial_hosts:localhost[7800],localhost[7801]}"
port_range="1"
num_initial_members="3"/>
<MERGE2 max_interval="100000"
down_thread="false" up_thread="false" min_interval="20000"/>
<FD_SOCK down_thread="false" up_thread="false"/>
<FD timeout="10000" max_tries="5" down_thread="false" up_thread="false" shun="true"/>
<VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false"/>
<pbcast.NAKACK max_xmit_size="60000"
use_mcast_xmit="false" gc_lag="0"
retransmit_timeout="300,600,1200,2400,4800"
down_thread="false" up_thread="false"
discard_delivered_msgs="true"/>
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
down_thread="false" up_thread="false"
max_bytes="400000"/>
<pbcast.GMS print_local_addr="true" join_timeout="3000"
down_thread="false" up_thread="false"
join_retry_timeout="2000" shun="true"
view_bundling="true"/>
<FC max_credits="2000000" down_thread="false" up_thread="false"
min_threshold="0.10"/>
<FRAG2 frag_size="60000" down_thread="false" up_thread="false"/>
<pbcast.STREAMING_STATE_TRANSFER down_thread="false" up_thread="false"
use_flush="true" use_reading_thread="true"/>
<!-- pbcast.STATE_TRANSFER down_thread="false" up_thread="false" use_flush="false"/ -->
<pbcast.FLUSH down_thread="false" up_thread="false"/>
</config>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months