[JBoss JIRA] Created: (JBESB-131) Mixing directory separator fails on Windows
by Mark Little (JIRA)
Mixing directory separator fails on Windows
-------------------------------------------
Key: JBESB-131
URL: http://jira.jboss.com/jira/browse/JBESB-131
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: ESB Core
Affects Versions: 4.0 Beta 1
Reporter: Mark Little
Assigned To: Tom Fennelly
Fix For: 4.0
Ant runFileBank fails due to the following line in the properties file:
file.monitored.directory=C:\Tools\JBossESB4.0_Beta1\docs\samples\trailblazer\bankloanbrokerdemo/./TrailBlazer-rtfiles/BankInput
Which was generated during the ant configure step.
It should read
file.monitored.directory=C:/Tools/JBossESB4.0_Beta1/docs/samples/trailblazer/bankloanbrokerdemo/TrailBlazer-rtfiles/BankInput
Apparently the mixing of the path separators throws it off.
The error message is
[java] Treying to create the directory.
Where does "Treying" come from?
--
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
19 years, 11 months
[JBoss JIRA] Updated: (JGRP-130) Problems with reincarnation
by Bela Ban (JIRA)
[ http://jira.jboss.com/jira/browse/JGRP-130?page=all ]
Bela Ban updated JGRP-130:
--------------------------
Fix Version/s: 2.6
(was: 2.5)
> Problems with reincarnation
> ---------------------------
>
> Key: JGRP-130
> URL: http://jira.jboss.com/jira/browse/JGRP-130
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 2.2.9
> Reporter: Bela Ban
> Assigned To: Bela Ban
> Fix For: 2.6
>
>
> Problems with reincarnation
> ===========================
> Author: Bela Ban
> Version: $Id$
> The identity of a JGroups member is always the IP address and a port. The port is usually chosen by the OS, unless
> bind_port is set (not set by default).
> Let's say a member's address is hostA:5000. When that member dies and is restarted, the OS will likely assign a
> higher port, say 5002. This depends on how many other processes requested a port in between the start and restart
> of the member.
> JGroups relies on the fact that the assignment of ports by the OS is always (not necessarily monotonically)
> *increasing* across a single machine. If this is not the case, then the following problems can occur:
> 1. Restart:
> When a member P crashes and then is restarted, if FD is used and P is restarted *before* it is excluded,
> then we have a new member *under the same old address* ! Since it lost all of its state (e.g. retransmission table),
> retransmission requests sent to the new P will fail.
> 2. Shunning:
> Regarding shunning: a member keeps its last N (default is 100) ports used, and makes sure it doesn't reuse one of
> those already-used ports when it is shunned. However, this is process-wide and *not* machine-wide, e.g. when we have
> processes P1 on A:5000 and P2 on A:5002 (on machine A), and both of them are shunned at the same time,
> when they rejoin, P1 does not use port 5000, but might use port 5002, and P2 doesn't use 5002, but might use 5000, so
> they could assume each other's identity !
> Both problems cannot be solved by remembering the last 100 ports: in case #1, this list is lost because we start a
> new process and in case #2, the list is process-wide, but not machine-wide.
> Again, these problems occur *only* when the OS reuses previously assigned ports.
> SOLUTION:
> A: Use temporary storage (per host) to store the last N addresses assigned on a given host. This makes sure we
> don't reuse previous addresses
> B: Use logical addresses, such as java.rmi.VMID or java.rmi.server.UID, which are unique over time for a given host.
> Then, it doesn't matter what ports we use because the ports are not used to determine a member's identity.
> The JIRA task for logical addresses is http://jira.jboss.com/jira/browse/JGRP-129.
--
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
19 years, 11 months
[JBoss JIRA] Updated: (JGRP-129) Logical addresses
by Bela Ban (JIRA)
[ http://jira.jboss.com/jira/browse/JGRP-129?page=all ]
Bela Ban updated JGRP-129:
--------------------------
Fix Version/s: 2.6
(was: 2.5)
> Logical addresses
> -----------------
>
> Key: JGRP-129
> URL: http://jira.jboss.com/jira/browse/JGRP-129
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 2.2.9
> Reporter: Bela Ban
> Assigned To: Bela Ban
> Fix For: 2.6
>
>
> The address chosen by each node is essentially the IP address and port of the receiver socket. However, for the following reasons, this is not good enough:
> - The node is shunned (excluded) and re-joins after leaving. We'd like to have the same logical address, although the physical address changed. This is already done in JBoss code, should be available in JGroups proper
> - NIC failover: a NIC goes down, we want to continue sending/receiving on a different NIC
> - The sender sends on all available NICs (send_on_all_interfaces="true"). This means that -if we take the receiver's datagram packet's address to be the identity of the sender - we get N different identities; 1 for each interface the message is sent on
> - Network Address Translation: the sender's address might get changed by the NAT
> DESIGN:
> - A logical address is picked, either by JGroups, or set by a user on channel creation. The lifetime of this address is the lifetime of the process in which the channel is created, or until channel.close() or disconnect() is called.
> - Each member as a small cache, in which it associates the logical addresses for messages received with the sender's address. When a message is to be sent to a logical address (unicast message), the corresponding physical address is looked up from the cache. Note that there maybe multiple physical addresses if the same message was sent on different interfaces (send_on_all_interfaces="true").
> - The logical addresses must be picked such that they cannot be reused after disconnect()/close().
--
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
19 years, 11 months
[JBoss JIRA] Updated: (JGRP-236) Combine join and state transfer
by Bela Ban (JIRA)
[ http://jira.jboss.com/jira/browse/JGRP-236?page=all ]
Bela Ban updated JGRP-236:
--------------------------
Fix Version/s: 2.6
(was: 2.5)
> Combine join and state transfer
> -------------------------------
>
> Key: JGRP-236
> URL: http://jira.jboss.com/jira/browse/JGRP-236
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 2.2.9.2, 2.2.9.1, 2.2.8, 2.2.9, 2.3
> Reporter: Bela Ban
> Assigned To: Vladimir Blagojevic
> Fix For: 2.6
>
>
> Add an additional connect(String group_name, boolean fetch_state, String state_id) method to Channel, so that we can combine joining and state transfer into 1 operation. This also requires only 1 FLUSH phase.
> The state would be returned either via pulling with Channel.receive() or pushing the setState() method in a registered Receiver/MessageListener.
> - The JOIN_REQ contains the boolean
> - The algorithm in GMS is the same as the two described above, except that before multicasting the new view and sending
> the JOIN_RSPs and LEAVE_RSPs, we ask the application for its state (GET_APPLSTATE) and when received (GET_APPLSTATE_OK),
> we send it back to the joining member(s), and the RESUME sending messages
--
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
19 years, 11 months
[JBoss JIRA] Updated: (JGRP-20) Address translation in transport (NAT support)
by Bela Ban (JIRA)
[ http://jira.jboss.com/jira/browse/JGRP-20?page=all ]
Bela Ban updated JGRP-20:
-------------------------
Fix Version/s: 2.6
(was: 2.5)
> Address translation in transport (NAT support)
> ----------------------------------------------
>
> Key: JGRP-20
> URL: http://jira.jboss.com/jira/browse/JGRP-20
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 2.2.8
> Reporter: Bela Ban
> Assigned To: Bela Ban
> Fix For: 2.6
>
> Original Estimate: 2 weeks
> Remaining Estimate: 2 weeks
>
> On multi-homed systems, the identity of a member is bound to a NIC (either chosen by the OS, or by the
> user through bind_addr): Address. When a message is sent, the msg contains this address as the sender's
> address. Responses go to the same address.
> However, if that NIC breaks, and the sender's OS chooses a different NIC for the datagram packets, the
> receiver will still send the response back to the old address (the identity of the sender cannot
> change).
> If we set the sender's address in any Message on *reception* of the message, we would be able to send
> the response back to a valid NIC in the above case. However, this means the *identity* of the sender
> changes, which JGroups cannot handle.
> SOLUTION I: we could introduce a logical address, which contains the physical address of the NIC
> through which it was sent. Problem: a lot of code would have to change.
> SOLUTION II: we maintain, in each transport, a table of sender's address as defined in the Message, and
> physical address of the {Datagram,Multicast}Packet received. Whenever we send a unicast message, we get
> the destination address from this table through a lookup in which dest_msg.dest_addr is the key.
> We need to reap the table every now and then to purge old addresses, we could use view changes to do
> so.
> Example for SOLUTION II:
> - Member P: address=1.2.3.4:5555
> - P's box has 2 NICs: 1.2.3.4 and 5.6.7.8
> - Receiver R receives a message from P: P.src_addr=1.2.3.4:5555, datagram's address is 1234:5555
> - R doesn't add an entry to the translation table, because the addresses are the same
> - R sends a response: it looks up 1.2.3.4:5555 (dst) in the translation table
> - There is no entry, therefore R sends the response to 1.2.3.4:5555
> - P's NIC 1.2.3.4 is unplugged
> - P sends a message through NIC 5.6.7.8
> - R receives a message M.src_addr=1.2.3.4:5555, datagram's address is 5.6.7.8:5555
> - R adds an entry to its translation table: 1.2.3.4:5555 --> 5.6.7.8:5555
> - R sends a response to 1.2.3.4:5555, since there is an entry for 1.2.3.4:5555, it uses 5.6.7.8:5555
> as the destination address of the datagram packet
> SOLUTION II allows us to reuse the existing code, but provides for changing underlying IP addresses.
--
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
19 years, 11 months
[JBoss JIRA] Created: (JGRP-272) System property resolution in Configurator
by Brian Stansberry (JIRA)
System property resolution in Configurator
------------------------------------------
Key: JGRP-272
URL: http://jira.jboss.com/jira/browse/JGRP-272
Project: JGroups
Issue Type: Feature Request
Reporter: Brian Stansberry
Assigned To: Bela Ban
Fix For: 2.4
It would be nice if JGroups supported JBoss-style system property resolution ( e.g. mcast_addr="${jboss.partition.udpGroup:230.1.2.7}"). This would be useful in standalone JGroups, and in JBoss AS when the JChannelFactory itself parses the "stacks.xml" file, bypassing the JBoss code.
I'll attach the JBoss utility class that does the substitution. Probably a simple fix is to duplicate this in JGroups and call it from the Configurator.
--
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
19 years, 11 months
[JBoss JIRA] Resolved: (JGRP-248) Channel.down() hangs under some circumstances using multiplexer
by Bela Ban (JIRA)
[ http://jira.jboss.com/jira/browse/JGRP-248?page=all ]
Bela Ban resolved JGRP-248.
---------------------------
Resolution: Cannot Reproduce Bug
Brian and Vladimir have been testing this part for a few weeks, and have not seen this problem again
> Channel.down() hangs under some circumstances using multiplexer
> ---------------------------------------------------------------
>
> Key: JGRP-248
> URL: http://jira.jboss.com/jira/browse/JGRP-248
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.3
> Reporter: Jerry Gauthier
> Assigned To: Bela Ban
> Fix For: 2.4
>
>
> If I enable the ClusterPartition and TomcatClusterService mbeans for use with JGroups 2.3 multiplexer, the server startup process will hang when ClusterPartition invokes channel.down(). This is true even if the two services instantiate the multiplexer channel using createMultiplexerChannel(String, String) instead of the state transfer constructor.
> To replicate this problem, the following steps are required.
> 1) Modify cluster-service.xml to enable ClusterPartition for multiplexer use (e.g., remove the comments from the Multiplexer attribute).
> 2) Modify tc5-cluster.sar\META-INF\jboss-service.xml to enable TomcatClusteringCache for multiplexer use (e.g., remove the comments from the Multiplexer attributes).
> 3) JBossCache is currently inhibited from using the multiplexer in TreeCache.setMultiplexer(). The method's setter is commented out and a warning is issued if you attempt to use the multiplexer with JBossCache. If this is still true when you attempt to replicate this issue, you'll need to modify TreeCache.setMultiplexer() to allow the multiplexer to be used.
> Note: I've only been able to replicate this issue when ClusterPartition and TomcatClusteringCache both have the multiplexer enabled. Using other cache services with ClusterPartition doesn't seem to trigger the problem.
--
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
19 years, 11 months
[JBoss JIRA] Resolved: (JBCLUSTER-93) Clustered MBean disappears from cluster when stopping one cluster node
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBCLUSTER-93?page=all ]
Brian Stansberry resolved JBCLUSTER-93.
---------------------------------------
Resolution: Duplicate Issue
It's not the same as JBAS-3023, but I've created JBAS-3194 to track it in the AS project. Am closing this issue; the bug should be tracked via JBAS-3194.
> Clustered MBean disappears from cluster when stopping one cluster node
> ----------------------------------------------------------------------
>
> Key: JBCLUSTER-93
> URL: http://jira.jboss.com/jira/browse/JBCLUSTER-93
> Project: JBoss Clustering
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: JBoss 4.0.3 , Cluster nodes run Kubuntu Linux 2.6.12-10-686, 192.168.0.X IP addresses
> Reporter: Hannes Koller
> Assigned To: Brian Stansberry
> Fix For: Bugs
>
>
> Setup:
> --------
> * Clustered MBean (extends HAServiceMbeanSupport)
> * ProxyFactoryHA is used to create the proxies
> (see refrenced forum thread - second page for detailed description of the MBean and associated jboss-service.xml)
> * Clustered MBean is deployed on several nodes (deployed manually, farming disabled)
> Behavior:
> -------------
> Initially everything works ( Load Balancing works - invocations are distributed among the nodes ). Bug occurs when one node undeploys it's replicant of the clustered MBean. All Instances of the MBean disappear from the DistributedReplicantManager, when one node shuts down the MBean.
> Core Reason:
> ----------------------
> An MBean.STOPPING event is created when the MBean is undeployed. This event is propagated to EVERY replicant of the MBean (not just the instance on the node which is actually shut down) --> the containerIsAboutToStop() method of the ProxyFactoryHA is called on every node, thus wrongly unregistering all MBean replicants at the DistributedReplicantManager.
--
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
19 years, 11 months
[JBoss JIRA] Updated: (JBCLUSTER-86) Web container lacks cluster replication of application scope
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBCLUSTER-86?page=all ]
Brian Stansberry updated JBCLUSTER-86:
--------------------------------------
Fix Version/s: Q2Y7
> Web container lacks cluster replication of application scope
> ------------------------------------------------------------
>
> Key: JBCLUSTER-86
> URL: http://jira.jboss.com/jira/browse/JBCLUSTER-86
> Project: JBoss Clustering
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: Q2Y5
> Reporter: treespace
> Assigned To: Ben Wang
> Fix For: Q2Y7
>
>
> Replication of servlet contexts (a.k.a. appliction scope) are not supported by the servlet specification. That is an important fact that needs to be emphased in cluster related documentation. Applications need to be cluster-aware at some level so this is just another design issue that needs to be accomodated.
> An extra-specification feature to cluster the servlet context would be peachy. Generalizing a shared object that hides the underlying cache implementation could provide a more portable alternative:
> getServletContext().getAttribute(MAGIC_BEAN).setAttribute("myBroadcastMessage", "All your servlet contexts are belong to us!");
> To port the application you would need a port of the MAGIC_BEAN class to use whatever clustering facilities are available on the target platform.
--
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
19 years, 11 months