[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
14 years
[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
14 years
[JBoss JIRA] Created: (JGRP-346) Connection objects are removed from the ConnectionTable, but remain active on the system and eventually consume available system resources.
by Stuart Jensen (JIRA)
Connection objects are removed from the ConnectionTable, but remain active on the system and eventually consume available system resources.
-------------------------------------------------------------------------------------------------------------------------------------------
Key: JGRP-346
URL: http://jira.jboss.com/jira/browse/JGRP-346
Project: JGroups
Issue Type: Bug
Affects Versions: 2.3 SP1
Environment: SUSE Linux 9
Reporter: Stuart Jensen
Assigned To: Bela Ban
To duplicate the issue:
1) Create a four member cluster using the following configuration: (two member clusters exhibit the problem as well, just not as exaggerated)
TCP(start_port=7801):
TCPPING(initial_hosts=<ip addresses go here>;port_range=3;timeout=3500;num_initial_members=3;up_thread=true;down_thread=true):
MERGE2(min_interval=5000;max_interval=10000):
FD(shun=true;timeout=2500;max_tries=5;up_thread=true;down_thread=true):
VERIFY_SUSPECT(timeout=2000;down_thread=false;up_thread=false):
pbcast.NAKACK(down_thread=true;up_thread=true;gc_lag=100;retransmit_timeout=3000):
pbcast.STABLE(desired_avg_gossip=20000;down_thread=false;up_thread=false):
pbcast.GMS(join_timeout=5000;join_retry_timeout=3500;shun=true;print_local_addr=true;down_thread=true;up_thread=true)
2) I was running JGroups in a Tomcat servlet application. Start up the cluster. To determine the number of threads on Linux I executed the following commands:
ps -ef | grep tomcat
echo "" > catalina.out
kill -QUIT <pid from ps command above>
grep ".Sender \[" catalina.out | wc -l
You get the process id of Tomcat using the ps command. Then clear the content of the catalina.out file. The kill command causes the threads to be printed into the catalina.out file. Then the grep searches for and counts all of the "ConnectionTable.Connnection.Sender" threads that are currently active on the system.
3) Pick one of the cluster member boxes and pull the network cable out of the box such that all communication with the other three members is terminated.
4) After one or two minutes, replace the network cable.
5) Repeat the steps to determine the number of threads currently active on the system.
6) Repeat steps 3 through 5, each time watching the number of threads. Each iteration will cause more and more threads to be orphaned on the system. It seems to grow exponentially, after about 4 iterations we have around 300-400 Sender threads. The Receiver threads will be orphaned also in similar numbers.
After investigating the issue, I came up with the following "fix" which cleared the problem up.
In the file ConnectionTable.java there is a method called retainAll(). It appears that this method is called by the TCP protocol when a view change occurs. This method removes Connnections from the "Connection Pool" (member variable conns) but does not destroy them. We initially thought the reaper thread may clean them up, but since the Connection objects are actually removed from the Connection Pool, the reaper does not help the situation. As we watched our connections we noticed that the Connections orphaned by this routine were the ones filling up the system's set of threads. So, we added code to call destroy() on all of the Connection objects that retainAll() removes from the Connection Pool. The "diff" is provided below. Note that we did our change in the JGroups 2.3 SP1 file ConnectionTable.java. Scott Marlow did this diff for me, the same change, but applied to the BasicConnectionTable from the 2.4 source set.
Index: BasicConnectionTable.java
===================================================================
RCS file: /cvsroot/javagroups/JGroups/src/org/jgroups/blocks/BasicConnectionTable.java,v
retrieving revision 1.8
diff -r1.8 BasicConnectionTable.java
22,26c22
< import java.util.Map;
< import java.util.Iterator;
< import java.util.HashMap;
< import java.util.Vector;
< import java.util.Collection;
---
> import java.util.*;
263c259,289
< conns.keySet().retainAll(c);
---
> // conns.keySet().retainAll(c);
> ArrayList alConnsToDestroy = new ArrayList();
> synchronized(conns)
> {
> HashMap copy=new HashMap(conns);
> conns.keySet().retainAll(c);
> Set ks = copy.keySet();
> Iterator iter = ks.iterator();
> while (iter.hasNext())
> {
> Object oKey = iter.next();
> if (null == conns.get(oKey))
> { // This connection NOT in the resultant connection set
> Connection conn = (Connection)copy.get(oKey);
> if (null != conn)
> { // Destroy this connection
> alConnsToDestroy.add(conn);
> }
> }
> }
> }
> // All of the connections that were not retained must be destroyed
> // so that their resources are cleaned up.
> for (int a=0; a<alConnsToDestroy.size(); a++)
> {
> Connection conn = (Connection)alConnsToDestroy.get(a);
> if(log.isTraceEnabled())
> log.trace("Destroy this orphaned connection: " + conn);
> conn.destroy();
> }
>
--
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
14 years
[JBoss JIRA] Created: (JBCLUSTER-186) Implementations of Invoker should implement equals as an equality check rather than relying on Object.equals, this is important for cluster fail-over support
by Scott Marlow (JIRA)
Implementations of Invoker should implement equals as an equality check rather than relying on Object.equals, this is important for cluster fail-over support
-------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBCLUSTER-186
URL: http://jira.jboss.com/jira/browse/JBCLUSTER-186
Project: JBoss Clustering
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: JBoss as 4.0.4, although this seems to happen in 4.5 + 5.x as well.
Reporter: Scott Marlow
Assigned To: Scott Marlow
Priority: Minor
Part of how JRMPInvokerProxyHA handles fail-over includes removing the reference to the node that left the cluster. However, the dead node is not removed as an equality check is not implemented by certain Invoker implementations.
The relevant code in JRMPInvokerProxyHA is
protected void removeDeadTarget(Object target)
{
if (this.familyClusterInfo != null)
this.familyClusterInfo.removeDeadTarget (target);
}
The code in familyClusterInfo is:
public ArrayList removeDeadTarget(Object target)
{
synchronized (this)
{
ArrayList tmp = (ArrayList) targets.clone();
tmp.remove (target);
this.targets = tmp;
this.isViewMembersInSyncWithViewId = false;
}
return this.targets;
}
Since, we didn't include an equals test in many of the different Invoker implementations, the above "tmp.remove(target)" operation fails. The reason for the failure is due to the "targets" ArrayList changing on every invocation (to reflect the current cluster server membership list), a new "targets" is created (so of course comparing references later will not work.)
A similar problem occurs with the EJB2 load balancers after a cluster membership changes.
I think that these issues will be solved by implementing an equals test in the different invokers that can handle equality testing.
PooledInvokerProxy should implement equals based on ServerAddress.
--
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
14 years
[JBoss JIRA] Created: (JGRP-371) TCP_NIO with SSL
by Bela Ban (JIRA)
TCP_NIO with SSL
----------------
Key: JGRP-371
URL: http://jira.jboss.com/jira/browse/JGRP-371
Project: JGroups
Issue Type: Feature Request
Affects Versions: 2.4
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.5
Attachments: ssl-nio.jar
>From Hal Hildebrand:
Attached are the sources to allow a new protocol stack which uses SSL over
NIO. This protocol stack element provides security and authentication
(using client side authentication) for a JGroups TCP stack using NIO.
This required two minor modifications in the ConnectionTableNIO class.
These modifications allow one to subclass to create a connection table which
uses SSL for the connections. Finally, there is a new protocol stack
element, SSL_NIO, which one can add to a stack to make use of it.
Regardless of whether this makes it into the codeline of JGroups, it would
be nice to have the changes to ConnectionTableNIO make it into the mainline,
as I currently have to overwrite the original class to easily implement this
- the last thing I want to do is fork ConnectionTableNIO ;) I'd rather just
subclass it. The mods are simple and innocuous (marked with "HSH").
Right now, the SSL_NIO needs to be configured with an SSLSocketFactory. I
didn't bother with integrating with the normal JGroups mechanism using
properties from the configuration because I consider it inherently insecure
to ensconce my passwords in configuration files. But the changes to enable
this are straight forward. Currently, to configure the factory for the
protocol layer, do something like the following before connecting your
channel:
// Construct your Jchannel
JChannel jchannel = ...
// Access your protocol stack
ProtocolStack protocolStack = jchannel.getProtocolStack();
// Retrieve the SSL_NIO protocol layer
SSL_NIO protocol = (SSL_NIO) protocolStack.findProtocol("SSL_NIO");
// Create your SSLSocketFactory
SSLSocketFactory socketFactory = ....
// Set up the protocol
protocol. SetSocketFactory(socketFactory);
// Connect your channel
jchannel.connnect("my-group");
Cheers.
--
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
14 years
[JBoss JIRA] Created: (JBAS-5900) jars are not loaded from the lib directory of a sar in JBoss AS 5
by Matt Wringe (JIRA)
jars are not loaded from the lib directory of a sar in JBoss AS 5
-----------------------------------------------------------------
Key: JBAS-5900
URL: https://jira.jboss.org/jira/browse/JBAS-5900
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: ClassLoading
Affects Versions: JBossAS-5.0.0.CR2
Reporter: Matt Wringe
Assignee: Scott M Stark
Attachments: testsar.tar.gz
In JBoss AS 5, any jars placed in the lib directory of a sar are not loaded and results in a class not found exception. The classes are loaded if the jar is placed in the root directory of the sar.
On previous versions of JBoss AS, the classes would be loaded from either location. This prevents sars that would have worked on JBoss AS 4 to fail on JBoss AS 5.
Steps to reproduce:
1) take zip attached to this report.
2) deploy test-in-lib.sar to JBoss AS 5. The sar will not deploy and will fail with a classNotFoundException
3) deploy test-in-lib.sar to JBoss AS 4, the sar will deploy without issue.
test-in-root.sar will work on both versions of JBoss. The only difference between these sars is the location of the jar.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] Created: (JBMESSAGING-1782) on cluster hiccup jbossmessaging dies
by Armin Haaf (JIRA)
on cluster hiccup jbossmessaging dies
-------------------------------------
Key: JBMESSAGING-1782
URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1782
Project: JBoss Messaging
Issue Type: Bug
Affects Versions: 1.4.3.GA
Environment: jboss 5.1
jboss groups 2.6.13 GA
Reporter: Armin Haaf
Priority: Blocker
sometimes we have a problem with our cluster loosing a socket connection. Groups come up again, but messaging dies and is no longer usable on this node.
Node 1 gots suspected by node 2 (i'm not sure why). Node 1 gets removed from the cluster and trys to reconnect. Reconnect seems to work, but messaging is now dead
output from node1:
2010-01-11 04:24:17,070 ERROR [org.jgroups.blocks.ConnectionTable] [T:169] failed sending data to 10.199.12.135:7900: java.net.SocketException: Broken pipe
2010-01-11 04:24:17,072 WARN [org.jgroups.protocols.FD] [T:48734] I was suspected by 10.199.12.135:32792; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK
2010-01-11 04:24:17,072 WARN [org.jgroups.protocols.FD] [T:48717] I was suspected by 10.199.12.135:32792; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK
2010-01-11 04:24:17,073 WARN [org.jgroups.protocols.FD] [T:48720] I was suspected by 10.199.12.135:32792; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK
2010-01-11 04:24:17,073 WARN [org.jgroups.protocols.pbcast.GMS] [T:67] I (10.199.12.134:32797) am not a member of view [10.199.12.135:32792|12] [10.199.12.135:32792], shunning myself
and leaving the group (prev_members are [10.199.12.135:32792, 10.199.12.134:32797], current view is [10.199.12.135:32792|11] [10.199.12.135:32792, 10.199.12.134:32797])
2010-01-11 04:24:17,073 WARN [org.jgroups.protocols.pbcast.GMS] [T:48721] I (10.199.12.134:32797) am not a member of view [10.199.12.135:32792|10] [10.199.12.135:32792], shunning myse
lf and leaving the group (prev_members are [10.199.12.135:32792, 10.199.12.134:32797], current view is [10.199.12.135:32792|9] [10.199.12.135:32792, 10.199.12.134:32797])
2010-01-11 04:24:17,074 WARN [org.jgroups.protocols.pbcast.GMS] [T:48719] I (10.199.12.134:32797) am not a member of view [10.199.12.135:32792|12] [10.199.12.135:32792], shunning myse
lf and leaving the group (prev_members are [10.199.12.135:32792, 10.199.12.134:32797], current view is [10.199.12.135:32792|11] [10.199.12.135:32792, 10.199.12.134:32797])
2010-01-11 04:24:17,075 ERROR [org.jgroups.protocols.UNICAST] [T:48718] 10.199.12.134:32797: sender window for 10.199.12.135:32792 not found
2010-01-11 04:24:17,585 INFO [STDOUT] [T:48741]
---------------------------------------------------------
GMS: address is 10.199.12.134:32799 (cluster=lisa2000)
---------------------------------------------------------
2010-01-11 04:24:17,591 INFO [org.jboss.ha.framework.interfaces.HAPartition.lisa2000] [T:48741] New cluster view for partition lisa2000: 11 ([10.199.12.135:1099, 10.199.12.134:1099] d
elta: 0)
2010-01-11 04:24:17,593 INFO [STDOUT] [T:48742]
---------------------------------------------------------
GMS: address is 10.199.12.134:32799 (cluster=MessagingPostOffice-CTRL)
---------------------------------------------------------
2010-01-11 04:24:17,594 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:101] I am (10.199.12.134:1099) received membershipChanged event:
2010-01-11 04:24:17,594 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:101] Dead members: 0 ([])
2010-01-11 04:24:17,594 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:101] New Members : 0 ([])
2010-01-11 04:24:17,594 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:101] All Members : 2 ([10.199.12.135:1099, 10.199.12.134:1099])
2010-01-11 04:24:17,601 INFO [STDOUT] [T:48740]
---------------------------------------------------------
GMS: address is 10.199.12.134:32799 (cluster=lisa2000-HAPartitionCache)
---------------------------------------------------------
2010-01-11 04:24:17,601 INFO [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:48742] org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener@429c429c g
ot new view [10.199.12.135:32792|13] [10.199.12.135:32792, 10.199.12.134:32799], old view is [10.199.12.135:32792|11] [10.199.12.135:32792, 10.199.12.134:32797]
2010-01-11 04:24:17,601 INFO [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:48742] I am (10.199.12.134:32799)
2010-01-11 04:24:17,609 INFO [org.jboss.cache.RPCManagerImpl] [T:48740] Received new cluster view: [10.199.12.135:32792|13] [10.199.12.135:32792, 10.199.12.134:32799]
2010-01-11 04:24:17,617 INFO [org.jboss.cache.statetransfer.LegacyStateTransferIntegrator] [T:48753] Using version 4096
2010-01-11 04:24:19,686 INFO [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:48742] Dead members: 1 ([10.199.12.134:32797])
2010-01-11 04:24:19,686 INFO [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:48742] New Members : 1 ([10.199.12.134:32799])
2010-01-11 04:24:19,686 INFO [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:48742] All Members : 2 ([10.199.12.135:32792, 10.199.12.134:32799])
2010-01-11 04:24:25,437 INFO [lisa.logistics.core.ejb.CommandExecutionBean] [T:782] Execute of ping takes 10 ms.
2010-01-11 04:24:28,705 ERROR [org.jboss.messaging.util.ExceptionUtil] [T:194] ConnectionEndpoint[l26-sy0xoa4g-1-qtygu64g-qp6dlm-q3cj5a] createSessionDelegate [t26-d91xoa4g-1-qtygu64g-
qp6dlm-q3cj5a]
java.lang.IllegalStateException: Cannot find binding for queue DLQ
at org.jboss.jms.server.ServerPeer.getDefaultDLQInstance(ServerPeer.java:1254)
at org.jboss.jms.server.endpoint.ServerSessionEndpoint.<init>(ServerSessionEndpoint.java:228)
at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:249)
at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$ConnectionAdvised$createSessionDelegate$aop(ConnectionAdvised.java:75)
at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$createSessionDelegate_6052335267724906805.invokeTarget(ConnectionAdvised$createSessionDelegate_6052335267724906805.ja
va)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.createSessionDelegate(ConnectionAdvised.java)
at org.jboss.jms.wireformat.ConnectionCreateSessionDelegateRequest.serverInvoke(ConnectionCreateSessionDelegateRequest.java:87)
at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:143)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
output from node 2:
2010-01-11 04:24:15,618 INFO [org.jboss.ha.framework.interfaces.HAPartition.lifecycle.lisa2000] [T:46047] Suspected member: 10.199.12.134:32797
2010-01-11 04:24:15,680 INFO [org.jboss.ha.framework.interfaces.HAPartition.lifecycle.lisa2000] [T:89] New cluster view for partition lisa2000 (id: 10, delta: -1) : [10.199.1
2.135:1099]
2010-01-11 04:24:15,681 INFO [org.jboss.cache.RPCManagerImpl] [T:89] Received new cluster view: [10.199.12.135:32792|12] [10.199.12.135:32792]
2010-01-11 04:24:15,682 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:106] I am (10.199.12.135:1099) received membershipChanged event:
2010-01-11 04:24:15,682 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:106] Dead members: 1 ([10.199.12.134:1099])
2010-01-11 04:24:15,682 INFO [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:108] org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener@443
24432 got new view [10.199.12.135:32792|12] [10.199.12.135:32792], old view is [10.199.12.135:32792|11] [10.199.12.135:32792, 10.199.12.134:32797]
2010-01-11 04:24:15,682 INFO [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:108] I am (10.199.12.135:32792)
2010-01-11 04:24:15,683 ERROR [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:108] Caught Exception in MembershipListener
java.lang.IllegalStateException: org.jboss.messaging.core.impl.postoffice.MessagingPostOffice@2b4e2b4e cannot find node ID for address 10.199.12.134:32797
at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.nodesLeft(MessagingPostOffice.java:942)
at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener.viewAccepted(GroupMember.java:508)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUpEvent(MessageDispatcher.java:733)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:776)
at org.jgroups.JChannel.up(JChannel.java:1336)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:454)
at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:435)
at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:153)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:188)
at org.jgroups.protocols.FC.up(FC.java:493)
at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:543)
at org.jgroups.protocols.pbcast.CoordGmsImpl.handleViewChange(CoordGmsImpl.java:463)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:749)
at org.jgroups.protocols.VIEW_SYNC.up(VIEW_SYNC.java:192)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:233)
at org.jgroups.protocols.UNICAST.up(UNICAST.java:328)
at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:895)
at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:708)
at org.jgroups.protocols.BARRIER.up(BARRIER.java:136)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:167)
at org.jgroups.protocols.FD.up(FD.java:284)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:307)
at org.jgroups.protocols.MERGE2.up(MERGE2.java:144)
at org.jgroups.protocols.Discovery.up(Discovery.java:262)
at org.jgroups.protocols.PING.up(PING.java:273)
at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2315)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1249)
at org.jgroups.protocols.TP.access$100(TP.java:49)
at org.jgroups.protocols.TP$1.run(TP.java:1176)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:736)
2010-01-11 04:24:15,682 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:106] New Members : 0 ([])
2010-01-11 04:24:15,683 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:106] All Members : 1 ([10.199.12.135:1099])
2010-01-11 04:24:17,033 WARN [org.jgroups.protocols.pbcast.NAKACK] [T:46042] 10.199.12.135:32792] discarded message from non-member 10.199.12.134:32797, my view is [10.199.12
.135:32792|12] [10.199.12.135:32792]
2010-01-11 04:24:17,033 WARN [org.jgroups.protocols.pbcast.NAKACK] [T:46041] 10.199.12.135:32792] discarded message from non-member 10.199.12.134:32797, my view is [10.199.12
.135:32792|10] [10.199.12.135:32792]
2010-01-11 04:24:17,069 WARN [org.jgroups.protocols.pbcast.NAKACK] [T:46041] 10.199.12.135:32792] discarded message from non-member 10.199.12.134:32797, my view is [10.199.12
.135:32792|10] [10.199.12.135:32792]
2010-01-11 04:24:17,072 WARN [org.jgroups.protocols.pbcast.NAKACK] [T:45905] 10.199.12.135:7900] discarded message from non-member 10.199.12.134:7900, my view is [10.199.12.1
35:7900|10] [10.199.12.135:7900]
2010-01-11 04:24:17,589 INFO [org.jboss.ha.framework.interfaces.HAPartition.lifecycle.lisa2000] [T:103] New cluster view for partition lisa2000 (id: 11, delta: 1) : [10.199.1
2.135:1099, 10.199.12.134:1099]
2010-01-11 04:24:17,589 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:106] I am (10.199.12.135:1099) received membershipChanged event:
2010-01-11 04:24:17,589 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:106] Dead members: 0 ([])
2010-01-11 04:24:17,589 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:106] New Members : 1 ([10.199.12.134:1099])
2010-01-11 04:24:17,589 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:106] All Members : 2 ([10.199.12.135:1099, 10.199.12.134:1099])
2010-01-11 04:24:17,597 INFO [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:113] org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener@443
24432 got new view [10.199.12.135:32792|13] [10.199.12.135:32792, 10.199.12.134:32799], old view is [10.199.12.135:32792|12] [10.199.12.135:32792]
2010-01-11 04:24:17,597 INFO [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:113] I am (10.199.12.135:32792)
2010-01-11 04:24:17,597 INFO [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:113] New Members : 1 ([10.199.12.134:32799])
2010-01-11 04:24:17,597 INFO [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:113] All Members : 2 ([10.199.12.135:32792, 10.199.12.134:32799])
2010-01-11 04:24:17,607 INFO [org.jboss.cache.RPCManagerImpl] [T:99] Received new cluster view: [10.199.12.135:32792|13] [10.199.12.135:32792, 10.199.12.134:32799]
2010-01-11 04:24:19,609 WARN [org.jgroups.protocols.pbcast.GMS] [T:46052] 10.199.12.135:32792 failed to collect all ACKs (1) for unicasted view [10.199.12.135:32792|13] [10.1
99.12.135:32792, 10.199.12.134:32799] after 2000ms, missing ACKs from [10.199.12.134:32799], local_addr=10.199.12.135:32792
2010-01-11 04:24:19,611 ERROR [org.jboss.messaging.core.impl.postoffice.UnbindRequest] [T:875] Failed to remove binding
java.lang.IllegalStateException: Don't know about node id: 1
at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.removeBindingFromCluster(MessagingPostOffice.java:1079)
at org.jboss.messaging.core.impl.postoffice.UnbindRequest.execute(UnbindRequest.java:61)
at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlRequestHandler.handle(GroupMember.java:622)
at org.jgroups.blocks.MessageDispatcher.handle(MessageDispatcher.java:616)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:637)
at org.jgroups.blocks.RequestCorrelator$Request.run(RequestCorrelator.java:944)
at org.jgroups.util.ReusableThread.run(ReusableThread.java:220)
at java.lang.Thread.run(Thread.java:736)
2010-01-11 04:24:19,611 ERROR [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:875] Caught Exception in RequestHandler
java.lang.Exception: Failed to remove binding
at org.jboss.messaging.core.impl.postoffice.UnbindRequest.execute(UnbindRequest.java:67)
at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlRequestHandler.handle(GroupMember.java:622)
at org.jgroups.blocks.MessageDispatcher.handle(MessageDispatcher.java:616)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:637)
at org.jgroups.blocks.RequestCorrelator$Request.run(RequestCorrelator.java:944)
at org.jgroups.util.ReusableThread.run(ReusableThread.java:220)
at java.lang.Thread.run(Thread.java:736)
Caused by:
java.lang.IllegalStateException: Don't know about node id: 1
at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.removeBindingFromCluster(MessagingPostOffice.java:1079)
at org.jboss.messaging.core.impl.postoffice.UnbindRequest.execute(UnbindRequest.java:61)
... 6 more
2010-01-11 04:24:19,611 ERROR [org.jgroups.blocks.RequestCorrelator] [T:875] error invoking method
java.lang.IllegalStateException: Failed to remove binding
at org.jboss.messaging.core.impl.postoffice.UnbindRequest.execute(UnbindRequest.java:67)
at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlRequestHandler.handle(GroupMember.java:622)
at org.jgroups.blocks.MessageDispatcher.handle(MessageDispatcher.java:616)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:637)
at org.jgroups.blocks.RequestCorrelator$Request.run(RequestCorrelator.java:944)
at org.jgroups.util.ReusableThread.run(ReusableThread.java:220)
at java.lang.Thread.run(Thread.java:736)
2010-01-11 04:24:19,622 ERROR [org.jboss.messaging.core.impl.postoffice.UnbindRequest] [T:875] Failed to remove binding
java.lang.IllegalStateException: Don't know about node id: 1
at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.removeBindingFromCluster(MessagingPostOffice.java:1079)
at org.jboss.messaging.core.impl.postoffice.UnbindRequest.execute(UnbindRequest.java:61)
at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlRequestHandler.handle(GroupMember.java:622)
at org.jgroups.blocks.MessageDispatcher.handle(MessageDispatcher.java:616)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:637)
at org.jgroups.blocks.RequestCorrelator$Request.run(RequestCorrelator.java:944)
at org.jgroups.util.ReusableThread.run(ReusableThread.java:220)
at java.lang.Thread.run(Thread.java:736)
2010-01-11 04:24:19,623 ERROR [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:875] Caught Exception in RequestHandler
java.lang.Exception: Failed to remove binding
at org.jboss.messaging.core.impl.postoffice.UnbindRequest.execute(UnbindRequest.java:67)
at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlRequestHandler.handle(GroupMember.java:622)
at org.jgroups.blocks.MessageDispatcher.handle(MessageDispatcher.java:616)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:637)
at org.jgroups.blocks.RequestCorrelator$Request.run(RequestCorrelator.java:944)
at org.jgroups.util.ReusableThread.run(ReusableThread.java:220)
at java.lang.Thread.run(Thread.java:736)
Caused by:
java.lang.IllegalStateException: Don't know about node id: 1
at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.removeBindingFromCluster(MessagingPostOffice.java:1079)
at org.jboss.messaging.core.impl.postoffice.UnbindRequest.execute(UnbindRequest.java:61)
... 6 more
2010-01-11 04:24:19,623 ERROR [org.jgroups.blocks.RequestCorrelator] [T:875] error invoking method
java.lang.IllegalStateException: Failed to remove binding
at org.jboss.messaging.core.impl.postoffice.UnbindRequest.execute(UnbindRequest.java:67)
at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlRequestHandler.handle(GroupMember.java:622)
at org.jgroups.blocks.MessageDispatcher.handle(MessageDispatcher.java:616)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:637)
at org.jgroups.blocks.RequestCorrelator$Request.run(RequestCorrelator.java:944)
at org.jgroups.util.ReusableThread.run(ReusableThread.java:220)
at java.lang.Thread.run(Thread.java:736)
2010-01-11 04:24:23,881 WARN [org.jgroups.protocols.pbcast.NAKACK] [T:46065] 10.199.12.135:7900] discarded message from non-member 10.199.12.134:7900, my view is [10.199.12.1
35:7900|10] [10.199.12.135:7900]
2010-01-11 04:24:32,813 WARN [org.jgroups.protocols.pbcast.NAKACK] [T:46065] 10.199.12.135:7900] discarded message from non-member 10.199.12.134:7900, my view is [10.199.12.1
35:7900|10] [10.199.12.135:7900]
2010-01-11 04:24:33,501 WARN [org.jgroups.protocols.pbcast.NAKACK] [T:46065] 10.199.12.135:7900] discarded message from non-member 10.199.12.134:7900, my view is [10.199.12.1
35:7900|10] [10.199.12.135:7900]
2010-01-11 04:24:45,201 WARN [org.jgroups.protocols.pbcast.NAKACK] [T:46069] 10.199.12.135:7900] discarded message from non-member 10.199.12.134:7900, my view is [10.199.12.1
35:7900|10] [10.199.12.135:7900]
2010-01-11 04:24:53,645 ERROR [org.jgroups.blocks.ConnectionTable] [T:171] failed sending data to 10.199.12.134:7900: java.net.SocketException: Socket closed
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] Created: (HIBERNATE-100) All versions of hibernate-tools packages are broken on eclipse-3.4
by solid Iduncare (JIRA)
All versions of hibernate-tools packages are broken on eclipse-3.4
------------------------------------------------------------------
Key: HIBERNATE-100
URL: http://jira.jboss.com/jira/browse/HIBERNATE-100
Project: Hibernate
Issue Type: Bug
Environment: Reproducable on Linux, Windows and Mac OSX
Reporter: solid Iduncare
Assigned To: Steve Ebersole
All versions of the Jboss hibernate-tools eclipse plugin fail in various ways on eclipse-3.4 (Ganymede). I have obtained various versions of the plugin via the eclipse update sites (both stable and dev) and all have various problems. I first attempted to download the latest from the stable update link (http://download.jboss.org/jbosstools/updates/stable/) . I selected the hibernate tools package for install only. It installs but is unusable. It seems to have no ill effects otherwise. When you attempt to add a hibernate configuration in the hibernate console, you get an exception similar to the followng:
java.lang.NoClassDefFoundError: org/eclipse/ui/internal/util/SWTResourceUtil
at org.hibernate.eclipse.console.workbench.xpl.AnyAdaptableLabelProvider.getImage(AnyAdaptableLabelProvider.java:166)
at org.eclipse.jface.viewers.WrappedViewerLabelProvider.getImage(WrappedViewerLabelProvider.java:117)
at org.eclipse.jface.viewers.WrappedViewerLabelProvider.update(WrappedViewerLabelProvider.java:165)
at org.eclipse.jface.viewers.ViewerColumn.refresh(ViewerColumn.java:145)
at org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:932)
at org.eclipse.jface.viewers.AbstractTreeViewer$UpdateItemSafeRunnable.run(AbstractTreeViewer.java:102)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.core.runtime.Platform.run(Platform.java:880)
at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:48)
at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
at org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:1012)
at org.eclipse.jface.viewers.StructuredViewer$UpdateItemSafeRunnable.run(StructuredViewer.java:466)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.core.runtime.Platform.run(Platform.java:880)
at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:48)
at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
at org.eclipse.jface.viewers.StructuredViewer.updateItem(StructuredViewer.java:2041)
at org.eclipse.jface.viewers.AbstractTreeViewer.createTreeItem(AbstractTreeViewer.java:827)
at org.eclipse.jface.viewers.AbstractTreeViewer.createAddedElements(AbstractTreeViewer.java:340)
at org.eclipse.jface.viewers.AbstractTreeViewer.internalAdd(AbstractTreeViewer.java:270)
at org.eclipse.jface.viewers.TreeViewer.internalAdd(TreeViewer.java:652)
at org.hibernate.eclipse.console.viewers.xpl.MTreeViewer.add(MTreeViewer.java:106)
at org.eclipse.ui.progress.DeferredTreeContentManager$3.runInUIThread(DeferredTreeContentManager.java:353)
at org.eclipse.ui.progress.UIJob$1.run(UIJob.java:94)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:133)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3800)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3425)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2382)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2346)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2198)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:493)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:288)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:488)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:382)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
I googled this error and it brought me to a hibernate jira page hosted by atlasian. That Jira page recommended using the latest hibernate tools plugin from the dev update site(http://download.jboss.org/jbosside/hibernatetools/updates/development/) so I did. Now this is where all hell brakes loose. After installing the latest version from this site and restarting eclipse, the JEE perspective is completely disabled. JSP files open in a regular text editor and all attempts to update eclipse fail with this exception:
Cannot complete the request. See the details.
Cannot find a solution where both Match[requiredCompatibility:
org.eclipse.equinox.p2.iu/org.eclipse.emf.ecore.xml/[2.1.0,2.1.0]] and Match[requiredCompatability:
....
In short there is no usable version of hibernate tools for eclipse-3.4.
--
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
14 years, 2 months
[JBoss JIRA] Created: (JBLOGGING-6) DatasourceAppender
by Luca Stancapiano (JIRA)
DatasourceAppender
------------------
Key: JBLOGGING-6
URL: https://jira.jboss.org/jira/browse/JBLOGGING-6
Project: JBoss Logging
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: jboss-logging-log4j
Affects Versions: 1.0.0.GA-slf4j-jboss-logging, 2.0.6.GA-spi
Reporter: Luca Stancapiano
Assignee: Dimitris Andreadis
Fix For: 2.0.6.GA-spi, 1.0.0.GA-slf4j-jboss-logging
hi.... what do you think about a DatasourceAppender? This is very simple. It overrides getConnection and closeConnection methods of org.apache.log4j.jdbc.JDBCAppender class and it is configurable by a *-log4j.xml file. Here there is an example of xml file:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="false">
<appender name="DATABASE" class="org.jboss.logging.appender.DatasourceAppender">
<param name="Threshold" value="INFO"/>
<param name="datasource" value="java:/PortalDS"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value=
"INSERT INTO JBP_LOGGING_SAMPLES_USERS (log_date, log_type, log_user, operation) VALUES ( '%d{yyyy-MM-dd HH:mm:ss.SSS}','%p', '%C;%L', '%C;%L')"/>
</layout>
</appender>
<category name="org.jboss.portal.core.identity.UsersActivityStatsServiceImpl">
<appender-ref ref="DATABASE"/>
</category>
</log4j:configuration>
it is the same configuration for JDBCAppender but there is a 'datasource' parameter so you can specify the datasource location. Below there is the whole class:
/*
* JBoss, Home of Professional Open Source
* Copyright 2005, JBoss Inc., and individual contributors as indicated
* by the @authors tag. See the copyright.txt in the distribution for a
* full listing of individual contributors.
*
* This is free software; you can redistribute it and/or modify it
* under the terms of the GNU Lesser General Public License as
* published by the Free Software Foundation; either version 2.1 of
* the License, or (at your option) any later version.
*
* This software is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this software; if not, write to the Free
* Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
* 02110-1301 USA, or see the FSF site: http://www.fsf.org.
*/
package org.jboss.logging.appender;
import java.sql.Connection;
import java.sql.SQLException;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.sql.DataSource;
/**
* An extension of the default Log4j JDBCAppender which will use a datasource to
* handle datas into database.
*
* @version <tt>$Revision: 1958 $</tt>
* @author <a href="mailto:jedim@vige.it">Luca Stancapiano</a>
*/
public class DatasourceAppender extends org.apache.log4j.jdbc.JDBCAppender {
/**
* URL of the DB for default connection handling
*/
protected String datasource = "java:/DefaultDS";
protected DataSource ds;
public void setDatasource(final String datasource) {
this.datasource = datasource;
}
/**
* I override this method to get a connection from datasource.
*/
protected Connection getConnection() throws SQLException {
if (connection == null || connection.isClosed()) {
if (ds == null)
try {
InitialContext ic = new InitialContext();
ds = (DataSource) ic.lookup(datasource);
} catch (NamingException e) {
e.printStackTrace();
}
connection = ds.getConnection();
}
return connection;
}
protected void closeConnection(Connection con) {
try {
connection.close();
} catch (SQLException ex) {
ex.printStackTrace();
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] Created: (HIBERNATE-54) problems w/ column names beginning with '_' (underscore) w/ apache derby database
by bugra uytun (JIRA)
problems w/ column names beginning with '_' (underscore) w/ apache derby database
---------------------------------------------------------------------------------
Key: HIBERNATE-54
URL: http://jira.jboss.com/jira/browse/HIBERNATE-54
Project: Hibernate
Issue Type: Bug
Environment: windows xp, java 1.5.0_09, eclispe 3.2.1, hibernate 3.2.1, derby 10.2.2.0, hibernate tools 3.2 beta8
Reporter: bugra uytun
Assigned To: Steve Ebersole
derby has problems with column names beginning with underscore, see also http://db.apache.org/derby/docs/10.1/ref/crefsqlj1003454.html
therefore such column names should be between double quotation marks (notice that double quotation marks also sets the case sensitivity on column names.)
but hibernate translates a HQL statement like this "from table1 t where t.id = '1'" to something like:
select table1_.id as id4, table1_._colname1 as column27_4_ schema1.table1 table1_ where table1_.id = '1'
but because of the columns that are beginning with an underscore the translation should be:
select table1_."id" as id4, table1_."_colname1" as column27_4_ schema1."table1" table1_ where table1_."id" = '1'
the errors i got are:
DEBUG [JDBCExceptionReporter]: could not execute query [<translated sql statement>]
ERROR 42X01: Syntax error: Encountered "_" at line 1, column 987.
at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
at org.apache.derby.impl.sql.compile.ParserImpl.parseStatement(Unknown Source)
at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.<init>(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.<init>(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.<init>(Unknown Source)
at org.apache.derby.jdbc.Driver30.newEmbedPreparedStatement(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source)
at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:497)
at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:415)
at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:139)
at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1538)
at org.hibernate.loader.Loader.doQuery(Loader.java:661)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
at org.hibernate.loader.Loader.doList(Loader.java:2211)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2095)
at org.hibernate.loader.Loader.list(Loader.java:2090)
at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:388)
at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:338)
at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:172)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1121)
at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
at <mypackage>.MyHibernate.main(MyHibernate.java:13)
WARN main org.hibernate.util.JDBCExceptionReporter - SQL Error: 20000, SQLState: 42X01
ERROR main org.hibernate.util.JDBCExceptionReporter - Syntax error: Encountered "_" at line 1, column 987.
--
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
14 years, 2 months
[JBoss JIRA] Created: (JBRULES-2372) Task - User ReceivedTime whenever Claim operation happens
by vijpan (JIRA)
Task - User ReceivedTime whenever Claim operation happens
---------------------------------------------------------
Key: JBRULES-2372
URL: https://jira.jboss.org/jira/browse/JBRULES-2372
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-process-task
Affects Versions: 5.1.0.M1
Reporter: vijpan
Assignee: Mark Proctor
Hi,
Is there a way possible where "Received Time" can be stored at Task level. This datetime value should get updated with the current timestamp whenever "Claim" operation happens on the Task. The use case is that most of the time if its a 1 potential owner of the task - the task goes through "created/ready/reserved" status whenever a new Task gets created, in this case creation time would be same as received time --- but whenever the task is assigned to group or multiple potential owner or even when it is in reserved status it can be forwarded/delegated to other user/group - then in that case whenever user receives as task or in WSHT tem claim operation happens can we store the timestamp at the task level.
Currently at task level we have creation time/activation time/expiration time ---- may be activation time can be used but i guess its use is very specific as detailed in WSHT/BPEL4People spec. In real world scenario it becomes quite important that when the user actually claimed the task or was assigned the task.
Vijay
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] Created: (EJBTHREE-1500) Discrepancies between removing a bean in cache vs bean passivated
by Galder Zamarreno (JIRA)
Discrepancies between removing a bean in cache vs bean passivated
-----------------------------------------------------------------
Key: EJBTHREE-1500
URL: https://jira.jboss.org/jira/browse/EJBTHREE-1500
Project: EJB 3.0
Issue Type: Sub-task
Affects Versions: AS 4.2.3.GA, AS 5.0.0.CR1
Reporter: Galder Zamarreno
Assignee: Galder Zamarreno
There's a discrepancy between removing a bean from the cache
after a timeout when bean is in cache compared to when bean is
passivated:
Example, when bean is in cache and has to be removed, this is called:
if (now - centry.lastUsed >= removalTimeout * 1000)
{
synchronized (centry)
{
it.remove();
}
}
Now, when bean is passivated, this is called:
if (now - centry.lastUsed >= removalTimeout * 1000)
{
get(centry.getId(), false);
remove(centry.getId());
}
And remove() method calls:
if(log.isTraceEnabled())
{
log.trace("Removing context " + key);
}
StatefulBeanContext ctx = null;
synchronized (cacheMap)
{
ctx = (StatefulBeanContext) cacheMap.get(key);
}
if(ctx == null)
throw new NoSuchEJBException("Could not find Stateful bean: " + key);
if (!ctx.isRemoved())
container.destroy(ctx);
++removeCount;
if (ctx.getCanRemoveFromCache())
{
synchronized (cacheMap)
{
cacheMap.remove(key);
}
}
What this means is that when a bean in cache is removed:
1.- removeCount is not updated
2.- container.destroy(ctx); is not executed and hence the @Remove
method is not executed either.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] Created: (JBWEB-72) html page and jsp are not display with in a Context defined in server.xml.
by Jean-Frederic Clere (JIRA)
html page and jsp are not display with in a Context defined in server.xml.
--------------------------------------------------------------------------
Key: JBWEB-72
URL: http://jira.jboss.com/jira/browse/JBWEB-72
Project: JBoss Web
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Core
Affects Versions: JBoss Web Server 1.0.1 GA
Environment: any
Reporter: Jean-Frederic Clere
Assigned To: Jean-Frederic Clere
Priority: Minor
When using a Context definition in server.xml like:
<Context path="/test" docBase="/home/jfclere/TMP/MYAPP" />
The jsp and html pages of /home/jfclere/TMP/MYAPP are not displayed (404 is returned).
That is because the conf/web.xml is not used to set the defaults when the <Context/> is processed.
DefaultWebXml is set in TomcatDeployer and that is after the <Context/> needs it. The default value is used but it is set to "web.xml".
--
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
14 years, 3 months
[JBoss JIRA] Created: (JBRULES-1917) JBRMS does not support business rules with non ascii characters
by Gregory Chazalon (JIRA)
JBRMS does not support business rules with non ascii characters
---------------------------------------------------------------
Key: JBRULES-1917
URL: https://jira.jboss.org/jira/browse/JBRULES-1917
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.0.7
Reporter: Gregory Chazalon
Assignee: Mark Proctor
A very simple rule containing some Latin1 characters (e.g. 'é', 'à'..), is not compiled correctly when using the JBRMS web app.
The exact same rule defined in a DRL file, and compiled with the drools compiler API is well handled (no characters mismatch).
Actually, the rule defined both ways is :
{code}
rule "latin_message"
when
Let information message
then
information message containing latin characters léger problème à résoudre hôpital
end
{/code}
I strongly suspect a poor character encoding scheme inside the JBRMS code, but I haven't been able to identify it.
The problem is illustrated by the LatinMessageTest test case, bundled inside the small eclipse project provided.
It has two test methods, one building the rule using the drools compiler API, and the other using a binary package built with JBRMS.
The second one fails as of the poor character encoding suspected inside JBRMS web app.
Any help is appreciated.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] Created: (JBRULES-1602) The order of RHS statements shouldn't affect behavior (insertLogical)
by Patrick Gras (JIRA)
The order of RHS statements shouldn't affect behavior (insertLogical)
---------------------------------------------------------------------
Key: JBRULES-1602
URL: http://jira.jboss.com/jira/browse/JBRULES-1602
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: Drools 4.0.7 & 4.0.4, Java5, eclipse compiler, windows XP.
Reporter: Patrick Gras
Assigned To: Mark Proctor
I have a class 'Cat' that is dynamic (JavaBean with PropertyChangeSupport ) with only a 'name' attribute.
Then I have the following rule:
rule "test"
when
$cat:Cat( name == "tom" )
then
$cat.setName("cat");
insertLogical(new String("test"));
end
When I test the rule against a Cat named tom, the logical inserted fact is not retracted. (So the fact is inserted because the rule matches, but is not retracted even if the rule is no more matching at the end.)
If I change the order of the RHS, it works fine. The fact is inserted and then retracted.
rule "test"
when
$cat:Cat( name == "tom" )
then
insertLogical(new String("test"));
$cat.setName("cat");
end
So the behavior depends on the ordering of the RHS statements.
Here is a complete example to show the problem:
public class Cat {
private String name;
protected PropertyChangeSupport changes = new PropertyChangeSupport(this);
public Cat(String name) {
super();
this.name = name;
}
public String getName() {
return this.name;
}
public void setName(String name) {
final String oldName = this.name;
this.name = name;
this.changes.firePropertyChange("name", oldName, name);
}
public void addPropertyChangeListener(final PropertyChangeListener listener) {
this.changes.addPropertyChangeListener(listener);
}
public void removePropertyChangeListener(
final PropertyChangeListener listener) {
this.changes.removePropertyChangeListener(listener);
}
}
public class RHSOrderingTest {
private static final String PACKAGE = "package ch.generali.pgr.rule ";
private static final String IMPORT = "import ch.generali.pgr.rules.Cat ";
private static final String WHEN = "rule \"test ok\" when $cat:Cat( name == \"tom\" ) ";
private static final String THEN_OK = "then insertLogical(Integer.valueOf(1)); $cat.setName(\"cat\"); end";
private static final String THEN_KO = "then $cat.setName(\"cat\"); insertLogical(Integer.valueOf(1)); end";
private static final String RULE_OK = PACKAGE + IMPORT + WHEN + THEN_OK;
private static final String RULE_KO = PACKAGE + IMPORT + WHEN + THEN_KO;
private static final String QUERY = "query \"My test Integer\" integer : Integer( intValue == 1 ) end";
public static void main(String[] args) {
boolean ok_1 = testWithRule(RULE_OK);
boolean ok_2 = testWithRule(RULE_KO);
System.out.println((ok_1 ? "SUCCESS: " : "FAILED: ") + THEN_OK);
System.out.println((ok_2 ? "SUCCESS: " : "FAILED: ") + THEN_KO);
}
private static boolean testWithRule(String rule) {
Cat tom = new Cat("tom");
RuleBase rb = createRuleBase(rule + "\n" + QUERY);
WorkingMemory wm = rb.newStatefulSession();
wm.insert(tom, true);
wm.fireAllRules();
QueryResults results = wm.getQueryResults("My test Integer");
return results.size() == 0;
}
private static RuleBase createRuleBase(String rules) {
try {
RuleBase ruleBase = RuleBaseFactory.newRuleBase();
PackageBuilderConfiguration conf = new PackageBuilderConfiguration();
PackageBuilder packageBuilder = new PackageBuilder(conf);
Reader source = new StringReader(rules);
packageBuilder.addPackageFromDrl(source);
Package pkg = packageBuilder.getPackage();
ruleBase.addPackage(pkg);
return ruleBase;
} catch (Exception e) {
throw new RuntimeException(e);
}
}
}
--
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
14 years, 4 months
[JBoss JIRA] Created: (JBRULES-2298) Can't use functions when MVEL dialect is set at package level
by Michael Neale (JIRA)
Can't use functions when MVEL dialect is set at package level
-------------------------------------------------------------
Key: JBRULES-2298
URL: https://jira.jboss.org/jira/browse/JBRULES-2298
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-compiler
Affects Versions: 5.0.1.FINAL
Reporter: Michael Neale
Assignee: Edson Tirelli
Priority: Critical
package jboss.cloud
dialect "mvel"
#trying to get functions working...
rule "something"
when
s: SimpleFact(id == 42, name == "michael")
then
System.out.println("hello");
end
function String doSomething() {
return "hey";
}
And I get:
java.lang.NullPointerException
at org.drools.rule.builder.dialect.mvel.MVELDialect.compile(MVELDialect.java:510)
at org.drools.rule.builder.dialect.mvel.MVELDialect.addFunction(MVELDialect.java:338)
at org.drools.compiler.PackageBuilder.addFunction(PackageBuilder.java:1104)
at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:626)
at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:290)
at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:488)
at org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:25)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] Created: (JBRULES-1665) put offending rule name in exception messages
by Alex McCarrier (JIRA)
put offending rule name in exception messages
---------------------------------------------
Key: JBRULES-1665
URL: http://jira.jboss.com/jira/browse/JBRULES-1665
Project: JBoss Drools
Issue Type: Feature Request
Components: Drl Parser/Builder
Affects Versions: FUTURE
Environment: all
Reporter: Alex McCarrier
Assigned To: Mark Proctor
Priority: Minor
It would be nice if drools compiler error messages would include the rule that caused the error. For instance, predicate eval errors, or "unable to resolve property" errors would state which rule was being evaluated when it encountered an error. Currently the developer has to go through the rules file looking for lines similar to the one reported in the error. Also, when it's this much work for a developer to find the offending rule, it is pretty much impossible for business users to figure out which rule they messed up.
If it's at all possible to add the rule name to these error messages, please do so. It would make our lives a lot easier. :)
--
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
14 years, 4 months
[JBoss JIRA] Created: (JBRULES-680) Support real-time problem modification during solving with utils for the single thread subsystem
by Geoffrey De Smet (JIRA)
Support real-time problem modification during solving with utils for the single thread subsystem
------------------------------------------------------------------------------------------------
Key: JBRULES-680
URL: http://jira.jboss.com/jira/browse/JBRULES-680
Project: JBoss Rules
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Solver
Reporter: Geoffrey De Smet
Assigned To: Geoffrey De Smet
Rete/Drools is single threaded, and so is the current implementation of the localsearchsolver,
but this single thread subsystem should be documented
and utils should be provided to allow for real-time problem modification
A simple way would be to use a producer-consumer pattern with a non blocking queue which holds "problem moves".
Each step the problem moves could be used.
Problems:
- bestsolutionrecalled also needs it's score adjusted. so we'll need a 2th working memory:
-- EITHER temporary, just for the problem move (or set of problem moves)
-- EITHER all the time, but then we'd have to hold a chain of moves, some of which might not be doable at the end
- cached selectors must be notified of refreshing their cache
- solution cloning normally doesn't clone the problem facts, just the proposed solution references. Do we need a full clone now?
--
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
14 years, 4 months
[JBoss JIRA] Created: (JBRULES-2244) MVEL raising errors for declared types when there is a package import (import x.y.x.*)
by Edson Tirelli (JIRA)
MVEL raising errors for declared types when there is a package import (import x.y.x.*)
--------------------------------------------------------------------------------------
Key: JBRULES-2244
URL: https://jira.jboss.org/jira/browse/JBRULES-2244
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-compiler, drools-core
Affects Versions: 5.0.1.FINAL, 5.0.0.FINAL
Reporter: Edson Tirelli
Assignee: Edson Tirelli
Fix For: 5.1.0.M1
The following DRL:
===================================================
package org.drools.examples.broker
import org.drools.examples.broker.model.*;
declare Statistics
symbol : String @key()
average : double
end
rule "Setup statistics"
when
$c : Company( $s : symbol )
not( Statistics( symbol == $s ) )
then
Statistics s = new Statistics();
s.symbol = $s;
insert( s );
end
===================================================
Generates the error:
-----------------------------
BuildError: Unable to build expression for 'consequence': Failed to compile: 1 compilation error(s):
- (1,10) unqualified type in strict mode for: Statistics ' Statistics s = new Statistics();
s.symbol = $s;
insert( s );
' broker.drl drools-examples-fusion/src/main/rules line 42 Drools Error
-----------------------------
But if we change the import to:
===================================================
import org.drools.examples.broker.model.Company
import org.drools.examples.broker.model.StockTick
import org.drools.examples.broker.model.SuddenDropEvent
===================================================
Everything works just fine.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] Created: (JBRULES-1801) drools-ant-4.0.7, DroolsCompilerAntTask, classloader mixup leads to ClassCastException if drools-compiler.jar part of classpathref
by Juergen none (JIRA)
drools-ant-4.0.7, DroolsCompilerAntTask, classloader mixup leads to ClassCastException if drools-compiler.jar part of classpathref
----------------------------------------------------------------------------------------------------------------------------------
Key: JBRULES-1801
URL: https://jira.jboss.org/jira/browse/JBRULES-1801
Project: JBoss Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-ant
Affects Versions: 4.0.7
Reporter: Juergen none
Assignee: Mark Proctor
drools-4.0.7:
Original error in build.xml:
/home/juergen/workspace/eclipse/kusss-dev/build.xml:777: RuleBaseTask failed: Unable to load dialect 'org.drools.rule.builder.dialect.java.JavaDialectConfiguration:java'
Traceback to:
org.drools.compiler.PackageBuilderConfiguration, line 154+:
Class cls = classLoader.loadClass( dialectClass );
DialectConfiguration dialectConf = (DialectConfiguration) cls.newInstance();
cls is org.drools.rule.builder.dialect.java.JavaDialectConfiguration, but loaded via classloader given in drools compile ant task property classpathref, while DialectConfiguration is loaded via ant tool classpath used for taskdef
-->
java.lang.ClassCastException: org.drools.rule.builder.dialect.java.JavaDialectConfiguration
interim fix:
make sure drools-compiler.jar is not in classpath of classloaderref
suggested fix:
Class cls = DialectConfiguration.class.getClassLoader().loadClass( dialectClass );
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] Created: (JBRULES-2384) Unable to process deployment descriptor for context'/drools-server'
by Megha Shetty (JIRA)
Unable to process deployment descriptor for context'/drools-server'
-------------------------------------------------------------------
Key: JBRULES-2384
URL: https://jira.jboss.org/jira/browse/JBRULES-2384
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: All
Environment: windows
Reporter: Megha Shetty
Assignee: Mark Proctor
I am getting the following error when i am trying to deploy drools-server.war through jboss.
Unable to process deployment descriptor for context'/drools-server'
Following is the complete log when i am starting the jboss server
JAVA_HOME is not set. Unexpected results may occur.
Set JAVA_HOME to the directory of your local JDK to avoid this message.
===============================================================================
JBoss Bootstrap Environment
JBOSS_HOME: E:\Eclipse Europa\jboss-4.2.3.GA
JAVA: java
JAVA_OPTS: -Dprogram.name=run.bat -Xms128m -Xmx512m -Dsun.rmi.dgc.client.gcIn
terval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000
CLASSPATH: E:\Eclipse Europa\jboss-4.2.3.GA\bin\run.jar
===============================================================================
14:35:43,295 INFO [Server] Starting JBoss (MX MicroKernel)...
14:35:43,295 INFO [Server] Release ID: JBoss [Trinity] 4.2.3.GA (build: SVNTag=
JBoss_4_2_3_GA date=200807181417)
14:35:43,295 INFO [Server] Home Dir: E:\Eclipse Europa\jboss-4.2.3.GA
14:35:43,295 INFO [Server] Home URL: file:/E:/Eclipse Europa/jboss-4.2.3.GA/
14:35:43,295 INFO [Server] Patch URL: null
14:35:43,295 INFO [Server] Server Name: default
14:35:43,295 INFO [Server] Server Home Dir: E:\Eclipse Europa\jboss-4.2.3.GA\se
rver\default
14:35:43,311 INFO [Server] Server Home URL: file:/E:/Eclipse Europa/jboss-4.2.3
.GA/server/default/
14:35:43,311 INFO [Server] Server Log Dir: E:\Eclipse Europa\jboss-4.2.3.GA\ser
ver\default\log
14:35:43,311 INFO [Server] Server Temp Dir: E:\Eclipse Europa\jboss-4.2.3.GA\se
rver\default\tmp
14:35:43,311 INFO [Server] Root Deployment Filename: jboss-service.xml
14:35:43,482 INFO [ServerInfo] Java version: 1.6.0,Sun Microsystems Inc.
14:35:43,482 INFO [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.6.0-b105,S
un Microsystems Inc.
14:35:43,498 INFO [ServerInfo] OS-System: Windows XP 5.1,x86
14:35:43,857 INFO [Server] Core system initialized
14:35:45,670 INFO [WebService] Using RMI server codebase: http://127.0.0.1:8083
/
14:35:45,670 INFO [Log4jService$URLWatchTimerTask] Configuring from URL: resour
ce:jboss-log4j.xml
14:35:46,513 INFO [TransactionManagerService] JBossTS Transaction Service (JTA
version) - JBoss Inc.
14:35:46,513 INFO [TransactionManagerService] Setting up property manager MBean
and JMX layer
14:35:46,701 INFO [TransactionManagerService] Starting recovery manager
14:35:46,748 INFO [TransactionManagerService] Recovery manager started
14:35:46,748 INFO [TransactionManagerService] Binding TransactionManager JNDI R
eference
14:35:50,263 INFO [EJB3Deployer] Starting java:comp multiplexer
14:35:51,607 INFO [NativeServerConfig] JBoss Web Services - Native
14:35:51,622 INFO [NativeServerConfig] jbossws-3.0.1-native-2.0.4.GA (build=200
803312044)
14:35:52,466 INFO [Embedded] Catalina naming disabled
14:35:52,575 INFO [AprLifecycleListener] The Apache Tomcat Native library which
allows optimal performance in production environments was not found on the java
.library.path: C:\WINDOWS\system32;.;C:\WINDOWS\Sun\Java\bin;C:\WINDOWS\system32
;C:\WINDOWS;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
14:35:52,607 INFO [Http11Protocol] Initializing Coyote HTTP/1.1 on http-127.0.0
.1-8080
14:35:52,607 INFO [AjpProtocol] Initializing Coyote AJP/1.3 on ajp-127.0.0.1-80
09
14:35:52,607 INFO [Catalina] Initialization processed in 147 ms
14:35:52,607 INFO [StandardService] Starting service jboss.web
14:35:52,607 INFO [StandardEngine] Starting Servlet Engine: JBossWeb/2.0.1.GA
14:35:52,638 INFO [Catalina] Server startup in 24 ms
14:35:52,794 INFO [TomcatDeployer] deploy, ctxPath=/, warUrl=.../deploy/jboss-w
eb.deployer/ROOT.war/
14:35:53,560 INFO [TomcatDeployer] deploy, ctxPath=/invoker, warUrl=.../deploy/
http-invoker.sar/invoker.war/
14:35:53,669 INFO [TomcatDeployer] deploy, ctxPath=/jbossws, warUrl=.../deploy/
jbossws.sar/jbossws-context.war/
14:35:53,732 INFO [TomcatDeployer] deploy, ctxPath=/jbossmq-httpil, warUrl=.../
deploy/jms/jbossmq-httpil.sar/jbossmq-httpil.war/
14:35:54,153 INFO [TomcatDeployer] deploy, ctxPath=/web-console, warUrl=.../dep
loy/management/console-mgr.sar/web-console.war/
14:35:54,513 INFO [MailService] Mail Service bound to java:/Mail
14:35:54,669 INFO [RARDeployment] Required license terms exist, view META-INF/r
a.xml in .../deploy/jboss-ha-local-jdbc.rar
14:35:54,763 INFO [RARDeployment] Required license terms exist, view META-INF/r
a.xml in .../deploy/jboss-ha-xa-jdbc.rar
14:35:54,856 INFO [RARDeployment] Required license terms exist, view META-INF/r
a.xml in .../deploy/jboss-local-jdbc.rar
14:35:54,935 INFO [RARDeployment] Required license terms exist, view META-INF/r
a.xml in .../deploy/jboss-xa-jdbc.rar
14:35:55,544 INFO [RARDeployment] Required license terms exist, view META-INF/r
a.xml in .../deploy/jms/jms-ra.rar
14:35:55,716 INFO [RARDeployment] Required license terms exist, view META-INF/r
a.xml in .../deploy/mail-ra.rar
14:35:55,903 INFO [RARDeployment] Required license terms exist, view META-INF/r
a.xml in .../deploy/quartz-ra.rar
14:35:55,903 INFO [QuartzResourceAdapter] start quartz!!!
14:35:55,950 INFO [SimpleThreadPool] Job execution threads will use class loade
r of thread: main
14:35:55,950 INFO [QuartzScheduler] Quartz Scheduler v.1.5.2 created.
14:35:55,966 INFO [RAMJobStore] RAMJobStore initialized.
14:35:55,966 INFO [StdSchedulerFactory] Quartz scheduler 'DefaultQuartzSchedule
r' initialized from default resource file in Quartz package: 'quartz.properties'
14:35:55,966 INFO [StdSchedulerFactory] Quartz scheduler version: 1.5.2
14:35:55,966 INFO [QuartzScheduler] Scheduler DefaultQuartzScheduler_$_NON_CLUS
TERED started.
14:35:56,966 INFO [ConnectionFactoryBindingService] Bound ConnectionManager 'jb
oss.jca:service=DataSourceBinding,name=DefaultDS' to JNDI name 'java:DefaultDS'
14:35:57,200 INFO [A] Bound to JNDI name: queue/A
14:35:57,200 INFO [B] Bound to JNDI name: queue/B
14:35:57,200 INFO [C] Bound to JNDI name: queue/C
14:35:57,200 INFO [D] Bound to JNDI name: queue/D
14:35:57,200 INFO [ex] Bound to JNDI name: queue/ex
14:35:57,216 INFO [testTopic] Bound to JNDI name: topic/testTopic
14:35:57,216 INFO [securedTopic] Bound to JNDI name: topic/securedTopic
14:35:57,216 INFO [testDurableTopic] Bound to JNDI name: topic/testDurableTopic
14:35:57,216 INFO [testQueue] Bound to JNDI name: queue/testQueue
14:35:57,231 INFO [UILServerILService] JBossMQ UIL service available at : /127.
0.0.1:8093
14:35:57,263 INFO [DLQ] Bound to JNDI name: queue/DLQ
14:35:57,341 INFO [ConnectionFactoryBindingService] Bound ConnectionManager 'jb
oss.jca:service=ConnectionFactoryBinding,name=JmsXA' to JNDI name 'java:JmsXA'
14:35:57,794 INFO [TomcatDeployer] deploy, ctxPath=/drools-guvnor, warUrl=.../d
eploy/drools-guvnor.war/
14:36:08,965 INFO [TomcatDeployer] deploy, ctxPath=/drools-server, warUrl=.../d
eploy/drools-server.war/
14:36:09,012 WARN [config] Unable to process deployment descriptor for context
'/drools-server'
14:36:09,371 INFO [TomcatDeployer] deploy, ctxPath=/jmx-console, warUrl=.../dep
loy/jmx-console.war/
14:36:09,496 INFO [Http11Protocol] Starting Coyote HTTP/1.1 on http-127.0.0.1-8
080
14:36:09,512 INFO [AjpProtocol] Starting Coyote AJP/1.3 on ajp-127.0.0.1-8009
14:36:09,512 INFO [Server] JBoss (MX MicroKernel) [4.2.3.GA (build: SVNTag=JBos
s_4_2_3_GA date=200807181417)] Started in 26s:201ms
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] Created: (JBRULES-2313) Tomcat memery leak with drools 4.0.7 or 5.0.1
by GREFFET Emmanuel (JIRA)
Tomcat memery leak with drools 4.0.7 or 5.0.1
----------------------------------------------
Key: JBRULES-2313
URL: https://jira.jboss.org/jira/browse/JBRULES-2313
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core (expert)
Affects Versions: 5.0.1.FINAL, 4.0.7
Environment: XP tomcat 5.5.9
Reporter: GREFFET Emmanuel
Assignee: Mark Proctor
Priority: Critical
The memory is never released !!! (never ever ) when à Stop and Start or restart Tomcat.
A made this test with a simple Drools call with a simple webapp and i tried with 4.0.7 and 5.0.1 drools version. The problem is the same.
We need to stop tomcat process to release memory. Until this stop each Tomcat "Restart" with a drools call, will never release the memory.
I made graphic with VisualWM, and we can see this problem !
I made a zip of my simple Eclipse project (webapp + drools) and word file for more information and screen copy of VisualVM.
Thanks for help.
Emmanuel GREFFET ( FRANCE)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months